BCP0001 BCP0002 BCP0003 RFC1915 BCP0004 RFC1917 BCP0005 RFC1918 BCP0006 RFC1930 RFC6996 RFC7300 BCP0007 RFC2008 BCP0008 RFC2014 BCP0009 RFC2026 RFC5657 RFC6410 RFC7100 RFC7127 RFC7475 BCP0010 RFC7437 BCP0011 RFC2028 BCP0012 BCP0013 RFC4289 RFC6838 BCP0014 RFC2119 BCP0015 RFC2148 BCP0016 RFC2182 BCP0017 RFC2219 BCP0018 RFC2277 BCP0019 RFC2978 BCP0020 RFC2317 BCP0021 RFC2350 BCP0022 RFC2360 BCP0023 RFC2365 BCP0024 RFC2379 BCP0025 RFC2418 RFC3934 BCP0026 RFC5226 BCP0027 RFC2438 BCP0028 RFC2488 BCP0029 RFC2489 BCP0030 RFC2505 BCP0031 RFC2506 BCP0032 RFC2606 BCP0033 RFC2611 BCP0034 RFC2644 BCP0035 RFC7595 BCP0036 RFC2736 BCP0037 RFC2780 RFC5237 BCP0038 RFC2827 BCP0039 RFC2850 BCP0040 RFC2870 BCP0041 RFC2914 RFC7141 BCP0042 RFC6895 BCP0043 RFC2939 BCP0044 RFC2964 BCP0045 RFC3005 BCP0046 RFC3013 BCP0047 RFC4647 RFC5646 BCP0048 RFC3150 BCP0049 RFC3152 BCP0050 RFC3155 BCP0051 RFC5771 BCP0052 RFC3172 BCP0053 RFC3180 BCP0054 RFC7154 BCP0055 RFC3227 BCP0056 RFC3205 BCP0057 RFC3228 BCP0058 RFC3233 BCP0059 RFC3349 BCP0060 RFC3360 BCP0061 RFC3365 BCP0062 RFC3366 BCP0063 RFC3372 BCP0064 RFC4520 BCP0065 RFC3405 BCP0066 RFC3406 BCP0067 RFC5727 BCP0068 RFC3438 BCP0069 RFC3449 BCP0070 RFC3470 BCP0071 RFC3481 BCP0072 RFC3552 BCP0073 RFC3553 BCP0074 RFC3584 BCP0075 RFC3665 BCP0076 RFC3666 BCP0077 RFC3677 BCP0078 RFC5378 BCP0079 RFC3979 RFC4879 BCP0080 RFC3681 BCP0081 RFC3688 BCP0082 RFC3692 BCP0083 RFC3683 BCP0084 RFC3704 BCP0085 RFC3725 BCP0086 RFC3766 BCP0087 RFC3785 BCP0088 RFC3818 BCP0089 RFC3819 BCP0090 RFC3864 BCP0091 RFC3901 BCP0092 RFC5742 BCP0093 RFC3933 BCP0094 BCP0095 RFC3935 BCP0096 RFC3936 BCP0097 RFC3967 RFC4897 BCP0098 RFC3968 BCP0099 RFC3969 BCP0100 RFC7120 BCP0101 RFC4071 RFC4371 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 BCP0128 RFC4928 BCP0129 RFC4929 BCP0130 RFC4940 BCP0131 RFC4961 BCP0132 RFC4962 BCP0133 RFC5033 BCP0134 RFC5068 BCP0135 RFC5135 BCP0136 RFC5266 BCP0137 RFC5137 BCP0138 RFC5248 BCP0139 RFC5249 BCP0140 RFC5358 BCP0141 RFC7042 BCP0142 RFC5382 BCP0143 RFC5383 BCP0144 RFC5359 BCP0145 RFC5405 BCP0146 RFC5406 BCP0147 RFC5407 BCP0148 RFC5508 BCP0149 RFC5589 BCP0150 RFC5597 BCP0151 RFC5615 BCP0152 RFC5625 BCP0153 RFC6598 RFC6890 BCP0154 RFC5774 BCP0155 RFC5855 BCP0156 RFC6056 BCP0157 RFC6177 BCP0158 RFC6158 BCP0159 RFC6191 BCP0160 RFC6280 BCP0161 RFC6291 BCP0162 RFC6302 BCP0163 RFC6303 BCP0164 RFC6328 BCP0165 RFC6335 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 FYI0002 RFC1470 FYI0003 RFC1175 FYI0004 RFC2664 FYI0005 RFC1178 FYI0006 RFC1198 FYI0007 RFC1207 FYI0008 RFC2196 FYI0009 RFC1336 FYI0010 RFC1402 FYI0011 RFC2116 FYI0012 RFC1302 FYI0013 RFC1308 FYI0014 RFC1309 FYI0015 RFC1355 FYI0016 RFC1359 FYI0018 RFC1983 FYI0019 RFC1463 FYI0020 RFC1462 FYI0021 RFC1491 FYI0022 RFC1941 FYI0023 RFC1580 FYI0024 RFC1635 FYI0025 RFC1689 FYI0026 RFC1709 FYI0027 RFC1713 FYI0028 RFC1855 FYI0029 RFC2007 FYI0030 RFC2151 FYI0031 RFC2150 FYI0032 RFC2235 FYI0033 RFC2398 FYI0034 RFC2504 FYI0035 RFC2635 FYI0036 RFC4949 FYI0037 RFC2901 FYI0038 RFC3098 RFC0001 Host Software S. Crocker April 1969 ASCII 21088 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0001 RFC0002 Host software B. Duvall April 1969 ASCII 17145 10 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=2 10.17487/RFC0002 RFC0003 Documentation conventions S.D. Crocker April 1969 ASCII 2323 2 RFC0010 UNKNOWN UNKNOWN Legacy 10.17487/RFC0003 RFC0004 Network timetable E.B. Shapiro March 1969 ASCII 5933 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0004 RFC0005 Decode Encode Language (DEL) J. Rulifson June 1969 ASCII 26408 17 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=5 10.17487/RFC0005 RFC0006 Conversation with Bob Kahn S.D. Crocker April 1969 ASCII 1568 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0006 RFC0007 Host-IMP interface G. Deloche May 1969 ASCII 13408 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0007 RFC0008 ARPA Network Functional Specifications G. Deloche May 1969 PDF 750612 UNKNOWN UNKNOWN Legacy 10.17487/RFC0008 RFC0009 Host Software G. Deloche May 1969 PDF 722638 UNKNOWN UNKNOWN Legacy 10.17487/RFC0009 RFC0010 Documentation conventions S.D. Crocker July 1969 ASCII 3348 3 RFC0003 RFC0016 RFC0024 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0010 RFC0011 Implementation of the Host - Host Software Procedures in GORDO G. Deloche August 1969 ASCII 46971 23 PDF 2186431 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0011 RFC0012 IMP-Host interface flow diagrams M. Wingfield August 1969 ASCII 177 1 PS 1489750 PDF 1163721 UNKNOWN UNKNOWN Legacy 10.17487/RFC0012 RFC0013 Zero Text Length EOF Message V. Cerf August 1969 ASCII 1070 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0013 RFC0014 RFC0015 Network subsystem for time sharing hosts C.S. Carr September 1969 ASCII 10695 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0015 RFC0016 M.I.T S. Crocker August 1969 ASCII 682 1 RFC0010 RFC0024 RFC0024 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0016 RFC0017 Some questions re: Host-IMP Protocol J.E. Kreznar August 1969 ASCII 6065 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0017 RFC0018 IMP-IMP and HOST-HOST Control Links V. Cerf September 1969 ASCII 634 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0018 RFC0019 Two protocol suggestions to reduce congestion at swap bound nodes J.E. Kreznar October 1969 ASCII 3392 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0019 RFC0020 ASCII format for network interchange V.G. Cerf October 1969 ASCII 18504 9 PDF 197096 STD0080 INTERNET STANDARD UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=20 10.17487/RFC0020 RFC0021 Network meeting V.G. Cerf October 1969 ASCII 2143 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0021 RFC0022 Host-host control message formats V.G. Cerf October 1969 ASCII 4606 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0022 RFC0023 Transmission of Multiple Control Messages G. Gregg October 1969 ASCII 690 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0023 RFC0024 Documentation Conventions S.D. Crocker November 1969 ASCII 3460 3 RFC0016 RFC0010 RFC0016 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0024 RFC0025 No High Link Numbers S.D. Crocker October 1969 ASCII 479 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0025 RFC0026 RFC0027 Documentation Conventions S.D. Crocker December 1969 ASCII 3661 3 RFC0010 RFC0016 RFC0024 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0027 RFC0028 Time Standards W.K. English January 1970 ASCII 557 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0028 RFC0029 Response to RFC 28 R.E. Kahn January 1970 ASCII 790 1 RFC0028 UNKNOWN UNKNOWN Legacy 10.17487/RFC0029 RFC0030 Documentation Conventions S.D. Crocker February 1970 ASCII 4041 3 RFC0010 RFC0016 RFC0024 RFC0027 UNKNOWN UNKNOWN Legacy 10.17487/RFC0030 RFC0031 Binary Message Forms in Computer D. Bobrow W.R. Sutherland February 1968 ASCII 11191 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=31 10.17487/RFC0031 RFC0032 Some Thoughts on SRI's Proposed Real Time Clock J. Cole February 1970 ASCII 2216 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0032 RFC0033 New Host-Host Protocol S.D. Crocker February 1970 ASCII 44167 19 RFC0011 RFC0036 RFC0047 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=33 10.17487/RFC0033 RFC0034 Some Brief Preliminary Notes on the Augmentation Research Center Clock W.K. English February 1970 ASCII 2534 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0034 RFC0035 Network Meeting S.D. Crocker March 1970 ASCII 1282 1 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0035 RFC0036 Protocol Notes S.D. Crocker March 1970 ASCII 13893 8 RFC0033 RFC0039 RFC0044 UNKNOWN UNKNOWN Legacy 10.17487/RFC0036 RFC0037 Network Meeting Epilogue, etc S.D. Crocker March 1970 ASCII 9107 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0037 RFC0038 Comments on Network Protocol from NWG/RFC #36 S.M. Wolfe March 1970 ASCII 2536 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0038 RFC0039 Comments on Protocol Re: NWG/RFC #36 E. Harslem J.F. Heafner March 1970 ASCII 4779 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0039 RFC0040 More Comments on the Forthcoming Protocol E. Harslem J.F. Heafner March 1970 ASCII 3825 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0040 RFC0041 IMP-IMP Teletype Communication J.T. Melvin March 1970 ASCII 1038 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0041 RFC0042 Message Data Types E. Ancona March 1970 ASCII 5247 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0042 RFC0043 Proposed Meeting A.G. Nemeth April 1970 ASCII 1600 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0043 RFC0044 Comments on NWG/RFC 33 and 36 A. Shoshani R. Long A. Landsberg April 1970 ASCII 7381 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0044 RFC0045 New Protocol is Coming J. Postel S.D. Crocker April 1970 ASCII 1130 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0045 RFC0046 ARPA Network protocol notes E. Meyer April 1970 ASCII 41338 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0046 RFC0047 BBN's Comments on NWG/RFC #33 J. Postel S. Crocker April 1970 ASCII 5343 4 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0047 RFC0048 Possible protocol plateau J. Postel S.D. Crocker April 1970 ASCII 41696 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0048 RFC0049 Conversations with S. Crocker (UCLA) E. Meyer April 1970 ASCII 12384 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0049 RFC0050 Comments on the Meyer Proposal E. Harslen J. Heafner April 1970 ASCII 4070 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0050 RFC0051 Proposal for a Network Interchange Language M. Elie May 1970 PDF 967411 UNKNOWN UNKNOWN Legacy 10.17487/RFC0051 RFC0052 Updated distribution list J. Postel S.D. Crocker July 1970 ASCII 5088 3 RFC0069 UNKNOWN UNKNOWN Legacy 10.17487/RFC0052 RFC0053 Official protocol mechanism S.D. Crocker June 1970 ASCII 2330 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0053 RFC0054 Official Protocol Proffering S.D. Crocker J. Postel J. Newkirk M. Kraley June 1970 ASCII 20131 9 RFC0057 UNKNOWN UNKNOWN Legacy 10.17487/RFC0054 RFC0055 Prototypical implementation of the NCP J. Newkirk M. Kraley J. Postel S.D. Crocker June 1970 ASCII 48070 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0055 RFC0056 Third Level Protocol: Logger Protocol E. Belove D. Black R. Flegal L.G. Farquar June 1970 ASCII 13066 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0056 RFC0057 Thoughts and Reflections on NWG/RFC 54 M. Kraley J. Newkirk June 1970 ASCII 8360 5 RFC0054 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=57 10.17487/RFC0057 RFC0058 Logical Message Synchronization T.P. Skinner June 1970 ASCII 3767 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0058 RFC0059 Flow Control - Fixed Versus Demand Allocation E. Meyer June 1970 ASCII 17691 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=59 10.17487/RFC0059 RFC0060 A Simplified NCP Protocol R. Kalin July 1970 ASCII 18694 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0060 RFC0061 Note on Interprocess Communication in a Resource Sharing Computer Network D.C. Walden July 1970 ASCII 43946 18 RFC0062 UNKNOWN UNKNOWN Legacy 10.17487/RFC0061 RFC0062 Systems for Interprocess Communication in a Resource Sharing Computer Network D.C. Walden August 1970 ASCII 55784 20 RFC0061 UNKNOWN UNKNOWN Legacy 10.17487/RFC0062 RFC0063 Belated Network Meeting Report V.G. Cerf July 1970 ASCII 2961 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0063 RFC0064 Getting rid of marking M. Elie July 1970 ASCII 7556 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0064 RFC0065 Comments on Host/Host Protocol document #1 D.C. Walden August 1970 ASCII 5628 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0065 RFC0066 NIC - third level ideas and other noise S.D. Crocker August 1970 ASCII 4575 3 RFC0123 RFC0080 RFC0093 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=66 10.17487/RFC0066 RFC0067 Proposed Change to Host/IMP Spec to Eliminate Marking W.R. Crowther January 1970 ASCII 1534 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0067 RFC0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM M. Elie August 1970 ASCII 5041 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0068 RFC0069 Distribution List Change for MIT A.K. Bhushan September 1970 ASCII 841 1 RFC0052 UNKNOWN UNKNOWN Legacy 10.17487/RFC0069 RFC0070 Note on Padding S.D. Crocker October 1970 ASCII 12790 9 RFC0228 UNKNOWN UNKNOWN Legacy 10.17487/RFC0070 RFC0071 Reallocation in Case of Input Error T. Schipper September 1970 ASCII 1265 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0071 RFC0072 Proposed Moratorium on Changes to Network Protocol R.D. Bressler September 1970 ASCII 4047 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0072 RFC0073 Response to NWG/RFC 67 S.D. Crocker September 1970 ASCII 1268 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0073 RFC0074 Specifications for Network Use of the UCSB On-Line System J.E. White October 1970 ASCII 21368 9 PDF 521403 RFC0217 RFC0225 UNKNOWN UNKNOWN Legacy 10.17487/RFC0074 RFC0075 Network Meeting S.D. Crocker October 1970 ASCII 1318 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0075 RFC0076 Connection by name: User oriented protocol J. Bouknight J. Madden G.R. Grossman October 1970 ASCII 26504 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0076 RFC0077 Network meeting report J. Postel November 1970 ASCII 19196 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0077 RFC0078 NCP Status Report: UCSB/Rand E. Harslem J.F. Heafner J.E. White October 1970 ASCII 1303 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0078 RFC0079 Logger Protocol error E. Meyer November 1970 ASCII 1515 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0079 RFC0080 Protocols and Data Formats E. Harslem J.F. Heafner December 1970 ASCII 17620 9 RFC0123 RFC0066 RFC0093 UNKNOWN UNKNOWN Legacy 10.17487/RFC0080 RFC0081 Request for Reference Information J. Bouknight December 1970 ASCII 956 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0081 RFC0082 Network Meeting Notes E. Meyer December 1970 ASCII 38023 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0082 RFC0083 Language-machine for data reconfiguration R.H. Anderson E. Harslem J.F. Heafner December 1970 ASCII 22253 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0083 RFC0084 List of NWG/RFC's 1-80 J.B. North December 1970 ASCII 12613 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0084 RFC0085 Network Working Group meeting S.D. Crocker December 1970 ASCII 1547 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0085 RFC0086 Proposal for a Network Standard Format for a Data Stream to Control Graphics Display S.D. Crocker January 1971 ASCII 7103 6 RFC0125 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=86 10.17487/RFC0086 RFC0087 Topic for Discussion at the Next Network Working Group Meeting A. Vezza January 1971 ASCII 3593 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0087 RFC0088 NETRJS: A third level protocol for Remote Job Entry R.T. Braden S.M. Wolfe January 1971 ASCII 19691 9 RFC0189 UNKNOWN UNKNOWN Legacy 10.17487/RFC0088 RFC0089 Some historic moments in networking R.M. Metcalfe January 1971 ASCII 16832 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=89 10.17487/RFC0089 RFC0090 CCN as a Network Service Center R.T. Braden January 1971 ASCII 11929 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0090 RFC0091 Proposed User-User Protocol G.H. Mealy December 1970 ASCII 27005 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0091 RFC0092 RFC0093 Initial Connection Protocol A.M. McKenzie January 1971 ASCII 1746 1 RFC0066 RFC0080 UNKNOWN UNKNOWN Legacy 10.17487/RFC0093 RFC0094 Some thoughts on Network Graphics E. Harslem J.F. Heafner February 1971 ASCII 13516 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0094 RFC0095 Distribution of NWG/RFC's through the NIC S. Crocker February 1971 ASCII 8692 5 RFC0155 UNKNOWN UNKNOWN Legacy 10.17487/RFC0095 RFC0096 An Interactive Network Experiment to Study Modes of Access the Network Information Center R.W. Watson February 1971 ASCII 11334 5 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0096 RFC0097 First Cut at a Proposed Telnet Protocol J.T. Melvin R.W. Watson February 1971 ASCII 24034 11 PDF 403375 UNKNOWN UNKNOWN Legacy 10.17487/RFC0097 RFC0098 Logger Protocol Proposal E. Meyer T. Skinner February 1971 ASCII 24536 10 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0098 RFC0099 Network Meeting P.M. Karp February 1971 ASCII 1010 1 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0099 RFC0100 Categorization and guide to NWG/RFCs P.M. Karp February 1971 ASCII 62473 37 UNKNOWN UNKNOWN Legacy 10.17487/RFC0100 RFC0101 Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971 R.W. Watson February 1971 ASCII 30343 14 RFC0108 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0101 RFC0102 Output of the Host-Host Protocol glitch cleaning committee S.D. Crocker February 1971 ASCII 8511 4 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0102 RFC0103 Implementation of Interrupt Keys R.B. Kalin February 1971 ASCII 7592 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0103 RFC0104 Link 191 J.B. Postel S.D. Crocker February 1971 ASCII 1017 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0104 RFC0105 Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB J.E. White March 1971 ASCII 21938 9 RFC0217 UNKNOWN UNKNOWN Legacy 10.17487/RFC0105 RFC0106 User/Server Site Protocol Network Host Questionnaire T.C. O'Sullivan March 1971 ASCII 6946 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0106 RFC0107 Output of the Host-Host Protocol Glitch Cleaning Committee R.D. Bressler S.D. Crocker W.R. Crowther G.R. Grossman R.S. Tomlinson J.E. White March 1971 ASCII 18109 12 RFC0102 RFC0111 RFC0124 RFC0132 RFC0154 RFC0179 UNKNOWN UNKNOWN Legacy 10.17487/RFC0107 RFC0108 Attendance list at the Urbana NWG meeting, February 17-19, 1971 R.W. Watson March 1971 ASCII 1597 2 RFC0101 UNKNOWN UNKNOWN Legacy 10.17487/RFC0108 RFC0109 Level III Server Protocol for the Lincoln Laboratory 360/67 Host J. Winett March 1971 ASCII 27716 12 PDF 645921 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0109 RFC0110 Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts J. Winett March 1971 ASCII 8586 4 PDF 738470 RFC0135 UNKNOWN UNKNOWN Legacy 10.17487/RFC0110 RFC0111 Pressure from the Chairman S.D. Crocker March 1971 ASCII 2098 2 RFC0107 RFC0130 UNKNOWN UNKNOWN Legacy 10.17487/RFC0111 RFC0112 User/Server Site Protocol: Network Host Questionnaire T.C. O'Sullivan April 1971 ASCII 1465 1 PDF 347370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0112 RFC0113 Network activity report: UCSB Rand E. Harslem J.F. Heafner J.E. White April 1971 ASCII 3442 2 RFC0227 UNKNOWN UNKNOWN Legacy 10.17487/RFC0113 RFC0114 File Transfer Protocol A.K. Bhushan April 1971 ASCII 38981 17 FTP RFC0133 RFC0141 RFC0171 RFC0172 UNKNOWN UNKNOWN Legacy 10.17487/RFC0114 RFC0115 Some Network Information Center policies on handling documents R.W. Watson J.B. North April 1971 ASCII 16775 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0115 RFC0116 Structure of the May NWG Meeting S.D. Crocker April 1971 ASCII 2395 1 RFC0099 RFC0131 RFC0156 UNKNOWN UNKNOWN Legacy 10.17487/RFC0116 RFC0117 Some comments on the official protocol J. Wong April 1971 ASCII 7128 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0117 RFC0118 Recommendations for facility documentation R.W. Watson April 1971 ASCII 4573 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0118 RFC0119 Network Fortran Subprograms M. Krilanovich April 1971 ASCII 39140 19 PDF 760848 UNKNOWN UNKNOWN Legacy 10.17487/RFC0119 RFC0120 Network PL1 subprograms M. Krilanovich April 1971 ASCII 37192 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0120 RFC0121 Network on-line operators M. Krilanovich April 1971 ASCII 29419 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0121 RFC0122 Network specifications for UCSB's Simple-Minded File System J.E. White April 1971 ASCII 47638 21 RFC0217 RFC0269 RFC0399 RFC0431 UNKNOWN UNKNOWN Legacy 10.17487/RFC0122 RFC0123 Proffered Official ICP S.D. Crocker April 1971 ASCII 4812 3 RFC0066 RFC0080 RFC0165 RFC0098 RFC0101 RFC0127 RFC0143 RFC0148 UNKNOWN UNKNOWN Legacy 10.17487/RFC0123 RFC0124 Typographical error in RFC 107 J.T. Melvin April 1971 ASCII 659 1 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0124 RFC0125 Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream J. McConnell April 1971 ASCII 8133 4 RFC0086 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0125 RFC0126 Graphics Facilities at Ames Research Center J. McConnell April 1971 ASCII 1974 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0126 RFC0127 Comments on RFC 123 J. Postel April 1971 ASCII 2305 2 RFC0145 RFC0123 RFC0151 UNKNOWN UNKNOWN Legacy 10.17487/RFC0127 RFC0128 Bytes J. Postel April 1971 ASCII 2745 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0128 RFC0129 Request for comments on socket name structure E. Harslem J. Heafner E. Meyer April 1971 ASCII 11175 6 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0129 RFC0130 Response to RFC 111: Pressure from the chairman J.F. Heafner April 1971 ASCII 2580 1 RFC0111 UNKNOWN UNKNOWN Legacy 10.17487/RFC0130 RFC0131 Response to RFC 116: May NWG meeting E. Harslem J.F. Heafner April 1971 ASCII 5375 3 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0131 RFC0132 Typographical Error in RFC 107 J.E. White April 1971 ASCII 1058 1 RFC0154 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0132 RFC0133 File Transfer and Error Recovery R.L. Sunberg April 1971 ASCII 8322 4 FTP RFC0114 UNKNOWN UNKNOWN Legacy 10.17487/RFC0133 RFC0134 Network Graphics meeting A. Vezza April 1971 ASCII 2684 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0134 RFC0135 Response to NWG/RFC 110 W. Hathaway April 1971 ASCII 5282 3 RFC0110 UNKNOWN UNKNOWN Legacy 10.17487/RFC0135 RFC0136 Host accounting and administrative procedures R.E. Kahn April 1971 ASCII 8016 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0136 RFC0137 Telnet Protocol - a proposed document T.C. O'Sullivan April 1971 ASCII 17606 11 RFC0139 UNKNOWN UNKNOWN Legacy 10.17487/RFC0137 RFC0138 Status report on proposed Data Reconfiguration Service R.H. Anderson V.G. Cerf E. Harslem J.F. Heafner J. Madden R.M. Metcalfe A. Shoshani J.E. White D.C.M. Wood April 1971 ASCII 46641 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0138 RFC0139 Discussion of Telnet Protocol T.C. O'Sullivan May 1971 ASCII 26085 11 RFC0137 RFC0158 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0139 RFC0140 Agenda for the May NWG meeting S.D. Crocker May 1971 ASCII 6934 4 RFC0149 UNKNOWN UNKNOWN Legacy 10.17487/RFC0140 RFC0141 Comments on RFC 114: A File Transfer Protocol E. Harslem J.F. Heafner April 1971 ASCII 3781 2 FTP RFC0114 UNKNOWN UNKNOWN Legacy 10.17487/RFC0141 RFC0142 Time-Out Mechanism in the Host-Host Protocol C. Kline J. Wong May 1971 ASCII 4372 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0142 RFC0143 Regarding proffered official ICP W. Naylor J. Wong C. Kline J. Postel May 1971 ASCII 6963 4 RFC0165 RFC0123 RFC0145 UNKNOWN UNKNOWN Legacy 10.17487/RFC0143 RFC0144 Data sharing on computer networks A. Shoshani April 1971 ASCII 13744 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0144 RFC0145 Initial Connection Protocol Control Commands J. Postel May 1971 ASCII 2490 2 PS 552114 PDF 15869 RFC0127 RFC0165 RFC0143 UNKNOWN UNKNOWN Legacy 10.17487/RFC0145 RFC0146 Views on issues relevant to data sharing on computer networks P.M. Karp D.B. McKay D.C.M. Wood May 1971 ASCII 9828 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0146 RFC0147 Definition of a socket J.M. Winett May 1971 ASCII 6438 3 RFC0129 UNKNOWN UNKNOWN Legacy 10.17487/RFC0147 RFC0148 Comments on RFC 123 A.K. Bhushan May 1971 ASCII 1149 1 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0148 RFC0149 Best Laid Plans S.D. Crocker May 1971 ASCII 1057 1 RFC0140 UNKNOWN UNKNOWN Legacy 10.17487/RFC0149 RFC0150 Use of IPC Facilities: A Working Paper R.B. Kalin May 1971 ASCII 28163 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0150 RFC0151 Comments on a proffered official ICP: RFCs 123, 127 A. Shoshani May 1971 ASCII 3623 2 RFC0127 UNKNOWN UNKNOWN Legacy 10.17487/RFC0151 RFC0152 SRI Artificial Intelligence status report M. Wilber May 1971 ASCII 2726 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0152 RFC0153 SRI ARC-NIC status J.T. Melvin R.W. Watson May 1971 ASCII 8573 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0153 RFC0154 Exposition Style S.D. Crocker May 1971 ASCII 1293 1 RFC0132 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0154 RFC0155 ARPA Network mailing lists J.B. North May 1971 ASCII 11054 13 RFC0095 RFC0168 UNKNOWN UNKNOWN Legacy 10.17487/RFC0155 RFC0156 Status of the Illinois site: Response to RFC 116 J. Bouknight April 1971 ASCII 1171 1 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0156 RFC0157 Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems V.G. Cerf May 1971 ASCII 3159 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0157 RFC0158 Telnet Protocol: A Proposed Document T.C. O'Sullivan May 1971 ASCII 21025 11 PDF 429985 RFC0495 RFC0139 RFC0318 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0158 RFC0159 RFC0160 RFC brief list Network Information Center. Stanford Research Institute May 1971 ASCII 12173 4 RFC0200 RFC0999 NIC6716 UNKNOWN UNKNOWN Legacy 10.17487/RFC0160 RFC0161 Solution to the race condition in the ICP A. Shoshani May 1971 ASCII 2026 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0161 RFC0162 NETBUGGER3 M. Kampe May 1971 ASCII 3153 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0162 RFC0163 Data transfer protocols V.G. Cerf May 1971 ASCII 5465 3 FTP DTP data manager UNKNOWN UNKNOWN Legacy 10.17487/RFC0163 RFC0164 Minutes of Network Working Group meeting, 5/16 through 5/19/71 J.F. Heafner May 1971 ASCII 58597 32 UNKNOWN UNKNOWN Legacy 10.17487/RFC0164 RFC0165 Proffered Official Initial Connection Protocol J. Postel May 1971 ASCII 8488 5 PDF 248876 RFC0145 RFC0143 RFC0123 NIC7101 UNKNOWN UNKNOWN Legacy 10.17487/RFC0165 RFC0166 Data Reconfiguration Service: An implementation specification R.H. Anderson V.G. Cerf E. Harslem J.F. Heafner J. Madden R.M. Metcalfe A. Shoshani J.E. White D.C.M. Wood May 1971 ASCII 42094 20 UNKNOWN UNKNOWN Legacy 10.17487/RFC0166 RFC0167 Socket conventions reconsidered A.K. Bhushan R.M. Metcalfe J.M. Winett May 1971 ASCII 7643 4 RFC0129 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0167 RFC0168 ARPA Network mailing lists J.B. North May 1971 ASCII 13294 7 RFC0155 RFC0211 UNKNOWN UNKNOWN Legacy 10.17487/RFC0168 RFC0169 COMPUTER NETWORKS S.D. Crocker May 1971 ASCII 7061 4 PDF 178823 UNKNOWN UNKNOWN Legacy 10.17487/RFC0169 RFC0170 RFC List by Number Network Information Center. Stanford Research Institute June 1971 ASCII 17670 6 RFC0200 UNKNOWN UNKNOWN Legacy 10.17487/RFC0170 RFC0171 The Data Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenize J. Melvin B. Sundberg D. Watson J. White June 1971 ASCII 20616 9 FTP DTP RFC0264 RFC0114 RFC0238 UNKNOWN UNKNOWN Legacy 10.17487/RFC0171 RFC0172 The File Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenzie J. Melvin B. Sundberg D. Watson J. White June 1971 ASCII 21328 12 FTP RFC0265 RFC0114 RFC0238 UNKNOWN UNKNOWN Legacy 10.17487/RFC0172 RFC0173 Network Data Management Committee Meeting Announcement P.M. Karp D.B. McKay June 1971 ASCII 4239 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0173 RFC0174 UCLA - Computer Science Graphics Overview J. Postel V.G. Cerf June 1971 ASCII 5037 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0174 RFC0175 Comments on "Socket Conventions Reconsidered" E. Harslem J.F. Heafner June 1971 ASCII 2225 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0175 RFC0176 Comments on "Byte size for connections" A.K. Bhushan R. Kanodia R.M. Metcalfe J. Postel June 1971 ASCII 7269 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0176 RFC0177 Device independent graphical display description J. McConnell June 1971 ASCII 20474 9 RFC0125 RFC0181 UNKNOWN UNKNOWN Legacy 10.17487/RFC0177 RFC0178 Network graphic attention handling I.W. Cotton June 1971 ASCII 24522 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0178 RFC0179 Link Number Assignments A.M. McKenzie June 1971 ASCII 1221 1 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0179 RFC0180 File system questionnaire A.M. McKenzie June 1971 ASCII 8154 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0180 RFC0181 Modifications to RFC 177 J. McConnell July 1971 ASCII 4892 3 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0181 RFC0182 Compilation of list of relevant site reports J.B. North June 1971 ASCII 2565 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0182 RFC0183 EBCDIC Codes and Their Mapping to ASCII J.M. Winett July 1971 ASCII 22256 12 PDF 577092 UNKNOWN UNKNOWN Legacy 10.17487/RFC0183 RFC0184 Proposed graphic display modes K.C. Kelley July 1971 ASCII 18678 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0184 RFC0185 NIC distribution of manuals and handbooks J.B. North July 1971 ASCII 1406 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0185 RFC0186 Network graphics loader J.C. Michener July 1971 ASCII 30557 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0186 RFC0187 Network/440 Protocol Concept D.B. McKay D.P. Karp July 1971 ASCII 25042 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0187 RFC0188 Data management meeting announcement P.M. Karp D.B. McKay January 1971 ASCII 3383 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0188 RFC0189 Interim NETRJS specifications R.T. Braden July 1971 ASCII 41383 19 RFC0088 RFC0599 RFC0283 UNKNOWN UNKNOWN Legacy 10.17487/RFC0189 RFC0190 DEC PDP-10-IMLAC communications system L.P. Deutsch July 1971 ASCII 18752 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0190 RFC0191 Graphics implementation and conceptualization at Augmentation Research Center C.H. Irby July 1971 ASCII 8179 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0191 RFC0192 Some factors which a Network Graphics Protocol must consider R.W. Watson July 1971 ASCII 48540 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0192 RFC0193 NETWORK CHECKOUT E. Harslem J.F. Heafner July 1971 ASCII 3622 2 RFC0198 RFC0198 UNKNOWN UNKNOWN Legacy 10.17487/RFC0193 RFC0194 The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes V. Cerf E. Harslem J. Heafner B. Metcalfe J. White July 1971 ASCII 32716 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0194 RFC0195 Data computers-data descriptions and access language G.H. Mealy July 1971 ASCII 8704 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0195 RFC0196 Mail Box Protocol R.W. Watson July 1971 ASCII 7016 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0196 RFC0197 Initial Connection Protocol - Reviewed A. Shoshani E. Harslem July 1971 ASCII 7094 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0197 RFC0198 Site Certification - Lincoln Labs 360/67 J.F. Heafner July 1971 ASCII 855 1 RFC0193 RFC0214 RFC0193 UNKNOWN UNKNOWN Legacy 10.17487/RFC0198 RFC0199 Suggestions for a Network Data-Tablet Graphics Protocol T. Williams July 1971 ASCII 18660 10 PDF 542961 UNKNOWN UNKNOWN Legacy 10.17487/RFC0199 RFC0200 RFC list by number J.B. North August 1971 ASCII 19256 7 RFC0170 RFC0160 NIC7724 UNKNOWN UNKNOWN Legacy 10.17487/RFC0200 RFC0201 RFC0202 Possible Deadlock in ICP S.M. Wolfe J. Postel July 1971 ASCII 2796 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0202 RFC0203 Achieving reliable communication R.B. Kalin August 1971 ASCII 9253 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0203 RFC0204 Sockets in use J. Postel August 1971 ASCII 1379 1 RFC0234 UNKNOWN UNKNOWN Legacy 10.17487/RFC0204 RFC0205 NETCRT - a character display protocol R.T. Braden August 1971 ASCII 28272 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0205 RFC0206 A User TELNET Description of an Initial Implementation J. White August 1971 ASCII 33152 14 PDF 617017 UNKNOWN UNKNOWN Legacy 10.17487/RFC0206 RFC0207 September Network Working Group meeting A. Vezza August 1971 ASCII 3356 2 RFC0212 UNKNOWN UNKNOWN Legacy 10.17487/RFC0207 RFC0208 Address tables A.M. McKenzie August 1971 ASCII 5858 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0208 RFC0209 Host/IMP interface documentation B. Cosell August 1971 ASCII 2566 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0209 RFC0210 Improvement of Flow Control W. Conrad August 1971 ASCII 3329 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0210 RFC0211 ARPA Network Mailing Lists J.B. North August 1971 ASCII 13205 13 PDF 210300 RFC0168 RFC0300 UNKNOWN UNKNOWN Legacy 10.17487/RFC0211 RFC0212 NWG meeting on network usage Information Sciences Institute University of Southern California August 1971 ASCII 4356 2 RFC0207 RFC0222 UNKNOWN UNKNOWN Legacy 10.17487/RFC0212 RFC0213 IMP System change notification B. Cosell August 1971 ASCII 1589 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0213 RFC0214 Network checkpoint E. Harslem August 1971 ASCII 3047 2 RFC0198 UNKNOWN UNKNOWN Legacy 10.17487/RFC0214 RFC0215 NCP, ICP, and Telnet: The Terminal IMP implementation A.M. McKenzie August 1971 ASCII 16645 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0215 RFC0216 Telnet Access to UCSB's On-Line System J.E. White September 1971 ASCII 37570 16 PDF 908675 UNKNOWN UNKNOWN Legacy 10.17487/RFC0216 RFC0217 Specifications changes for OLS, RJE/RJOR, and SMFS J.E. White September 1971 ASCII 2956 2 RFC0074 RFC0105 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0217 RFC0218 Changing the IMP status reporting facility B. Cosell September 1971 ASCII 1131 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0218 RFC0219 User's View of the Datacomputer R. Winter September 1971 ASCII 16631 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0219 RFC0220 RFC0221 Mail Box Protocol: Version 2 R.W. Watson August 1971 ASCII 9805 5 RFC0196 RFC0278 UNKNOWN UNKNOWN Legacy 10.17487/RFC0221 RFC0222 Subject: System programmer's workshop R.M. Metcalfe September 1971 ASCII 4023 2 RFC0212 RFC0234 UNKNOWN UNKNOWN Legacy 10.17487/RFC0222 RFC0223 Network Information Center schedule for network users J.T. Melvin R.W. Watson September 1971 ASCII 5369 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0223 RFC0224 Comments on Mailbox Protocol A.M. McKenzie September 1971 ASCII 3583 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0224 RFC0225 Rand/UCSB network graphics experiment E. Harslem R. Stoughton September 1971 ASCII 13573 5 RFC0074 UNKNOWN UNKNOWN Legacy 10.17487/RFC0225 RFC0226 Standardization of host mnemonics P.M. Karp September 1971 ASCII 2012 1 RFC0247 UNKNOWN UNKNOWN Legacy 10.17487/RFC0226 RFC0227 Data transfer rates (Rand/UCLA) J.F. Heafner E. Harslem September 1971 ASCII 2451 2 RFC0113 UNKNOWN UNKNOWN Legacy 10.17487/RFC0227 RFC0228 Clarification D.C. Walden September 1971 ASCII 715 1 RFC0070 UNKNOWN UNKNOWN Legacy 10.17487/RFC0228 RFC0229 Standard host names J. Postel September 1971 ASCII 3388 3 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0229 RFC0230 Toward reliable operation of minicomputer-based terminals on a TIP T. Pyke September 1971 ASCII 7040 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0230 RFC0231 Service center standards for remote usage: A user's view J.F. Heafner E. Harslem September 1971 ASCII 9692 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0231 RFC0232 Postponement of network graphics meeting A. Vezza September 1971 ASCII 899 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0232 RFC0233 Standardization of host call letters A. Bhushan R. Metcalfe September 1971 ASCII 3206 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0233 RFC0234 Network Working Group meeting schedule A. Vezza October 1971 ASCII 1634 1 RFC0222 RFC0204 UNKNOWN UNKNOWN Legacy 10.17487/RFC0234 RFC0235 Site status E. Westheimer September 1971 ASCII 7994 5 RFC0240 UNKNOWN UNKNOWN Legacy 10.17487/RFC0235 RFC0236 Standard host names J. Postel September 1971 ASCII 5112 2 RFC0229 UNKNOWN UNKNOWN Legacy 10.17487/RFC0236 RFC0237 NIC view of standard host names R.W. Watson October 1971 ASCII 2212 1 RFC0273 UNKNOWN UNKNOWN Legacy 10.17487/RFC0237 RFC0238 Comments on DTP and FTP proposals R.T. Braden September 1971 ASCII 2735 2 FTP RFC0171 RFC0172 UNKNOWN UNKNOWN Legacy 10.17487/RFC0238 RFC0239 Host mnemonics proposed in RFC 226 (NIC 7625) R.T. Braden September 1971 ASCII 2236 1 RFC0226 RFC0229 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0239 RFC0240 Site Status A.M. McKenzie September 1971 ASCII 7948 4 RFC0235 RFC0252 UNKNOWN UNKNOWN Legacy 10.17487/RFC0240 RFC0241 Connecting computers to MLC ports A.M. McKenzie September 1971 ASCII 3739 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0241 RFC0242 Data Descriptive Language for Shared Data L. Haibt A.P. Mullery July 1971 ASCII 18151 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0242 RFC0243 Network and data sharing bibliography A.P. Mullery October 1971 ASCII 12432 7 RFC0290 UNKNOWN UNKNOWN Legacy 10.17487/RFC0243 RFC0244 RFC0245 Reservations for Network Group meeting C. Falls October 1971 ASCII 1142 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0245 RFC0246 Network Graphics meeting A. Vezza October 1971 ASCII 856 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0246 RFC0247 Proffered set of standard host names P.M. Karp October 1971 ASCII 7122 4 RFC0226 UNKNOWN UNKNOWN Legacy 10.17487/RFC0247 RFC0248 RFC0249 Coordination of equipment and supplies purchase R.F. Borelli October 1971 ASCII 4561 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0249 RFC0250 Some thoughts on file transfer H. Brodie October 1971 ASCII 2446 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0250 RFC0251 Weather data D. Stern October 1971 ASCII 1907 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0251 RFC0252 Network host status E. Westheimer October 1971 ASCII 5531 3 RFC0240 RFC0255 UNKNOWN UNKNOWN Legacy 10.17487/RFC0252 RFC0253 Second Network Graphics meeting details J.A. Moorer October 1971 ASCII 1981 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0253 RFC0254 Scenarios for using ARPANET computers A. Bhushan October 1971 ASCII 40998 PDF 4903124 UNKNOWN UNKNOWN Legacy 10.17487/RFC0254 RFC0255 Status of network hosts E. Westheimer October 1971 ASCII 4002 2 RFC0252 RFC0266 UNKNOWN UNKNOWN Legacy 10.17487/RFC0255 RFC0256 IMPSYS change notification B. Cosell November 1971 ASCII 1240 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0256 RFC0257 RFC0258 RFC0259 RFC0260 RFC0261 RFC0262 RFC0263 "Very Distant" Host interface A.M. McKenzie December 1971 ASCII 3914 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0263 RFC0264 The Data Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenize B. Sundberg D. Watson J. White January 1972 ASCII 20907 9 FTP DTP RFC0171 RFC0354 RFC0310 RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0264 RFC0265 The File Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenzie J. Melvin B. Sundberg D. Watson J. White November 1971 ASCII 3914 12 FTP RFC0172 RFC0354 RFC0281 RFC0294 RFC0310 RFC0264 UNKNOWN UNKNOWN Legacy 10.17487/RFC0265 RFC0266 Network host status E. Westheimer November 1971 ASCII 3174 2 RFC0255 RFC0267 UNKNOWN UNKNOWN Legacy 10.17487/RFC0266 RFC0267 Network Host Status E. Westheimer November 1971 ASCII 7862 4 RFC0266 RFC0287 UNKNOWN UNKNOWN Legacy 10.17487/RFC0267 RFC0268 Graphics facilities information J. Postel November 1971 ASCII 1298 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0268 RFC0269 Some Experience with File Transfer H. Brodie December 1971 ASCII 5961 3 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0269 RFC0270 Correction to BBN Report No. 1822 (NIC NO 7958) A.M. McKenzie January 1972 ASCII 1371 1 NIC7959 UNKNOWN UNKNOWN Legacy 10.17487/RFC0270 RFC0271 IMP System change notifications B. Cosell January 1972 ASCII 4022 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0271 RFC0272 RFC0273 More on standard host names R.W. Watson October 1971 ASCII 4589 3 RFC0237 UNKNOWN UNKNOWN Legacy 10.17487/RFC0273 RFC0274 Establishing a local guide for network usage E. Forman November 1971 ASCII 7114 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0274 RFC0275 RFC0276 NIC course R.W. Watson November 1971 ASCII 1183 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0276 RFC0277 RFC0278 Revision of the Mail Box Protocol A.K. Bhushan R.T. Braden E. Harslem J.F. Heafner A.M. McKenzie J.T. Melvin R.L. Sundberg R.W. Watson J.E. White November 1971 ASCII 7526 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0278 RFC0279 RFC0280 A Draft of Host Names R.W. Watson November 1971 ASCII 3629 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0280 RFC0281 Suggested addition to File Transfer Protocol A.M. McKenzie December 1971 ASCII 12006 8 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0281 RFC0282 Graphics meeting report M.A. Padlipsky December 1971 ASCII 18100 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0282 RFC0283 NETRJT: Remote Job Service Protocol for TIPS R.T. Braden December 1971 ASCII 18771 9 RFC0189 UNKNOWN UNKNOWN Legacy 10.17487/RFC0283 RFC0284 RFC0285 Network graphics D. Huff December 1971 ASCII 18076 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0285 RFC0286 Network Library Information System E. Forman December 1971 ASCII 2079 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0286 RFC0287 Status of Network Hosts E. Westheimer December 1971 ASCII 9217 5 RFC0267 RFC0288 UNKNOWN UNKNOWN Legacy 10.17487/RFC0287 RFC0288 Network host status E. Westheimer January 1972 ASCII 8501 4 RFC0287 RFC0293 RFC0293 UNKNOWN UNKNOWN Legacy 10.17487/RFC0288 RFC0289 What we hope is an official list of host names R.W. Watson December 1971 ASCII 5069 3 RFC0384 UNKNOWN UNKNOWN Legacy 10.17487/RFC0289 RFC0290 Computer networks and data sharing: A bibliography A.P. Mullery January 1972 ASCII 34329 15 RFC0243 UNKNOWN UNKNOWN Legacy 10.17487/RFC0290 RFC0291 Data Management Meeting Announcement D.B. McKay January 1972 ASCII 3375 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0291 RFC0292 Graphics Protocol: Level 0 only J.C. Michener I.W. Cotton K.C. Kelley D.E. Liddle E. Meyer January 1972 ASCII 22342 10 RFC0493 UNKNOWN UNKNOWN Legacy 10.17487/RFC0292 RFC0293 Network Host Status E. Westheimer January 1972 ASCII 7639 4 RFC0288 RFC0298 RFC0288 UNKNOWN UNKNOWN Legacy 10.17487/RFC0293 RFC0294 The Use of "Set Data Type" Transaction in File Transfer Protocol A.K. Bhushan January 1972 ASCII 3924 2 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0294 RFC0295 Report of the Protocol Workshop, 12 October 1971 J. Postel January 1972 ASCII 5432 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0295 RFC0296 DS-1 Display System D.E. Liddle January 1972 ASCII 37921 17 PDF 1560765 UNKNOWN UNKNOWN Legacy 10.17487/RFC0296 RFC0297 TIP Message Buffers D.C. Walden January 1972 ASCII 3517 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0297 RFC0298 Network host status E. Westheimer February 1972 ASCII 8770 4 RFC0293 RFC0306 UNKNOWN UNKNOWN Legacy 10.17487/RFC0298 RFC0299 Information Management System D. Hopkin February 1972 ASCII 1825 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0299 RFC0300 ARPA Network mailing lists J.B. North January 1972 ASCII 16357 9 RFC0211 RFC0303 UNKNOWN UNKNOWN Legacy 10.17487/RFC0300 RFC0301 BBN IMP (#5) and NCC Schedule March 4, 1971 R. Alter February 1972 ASCII 1487 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0301 RFC0302 Exercising The ARPANET R.F. Bryan February 1972 ASCII 5452 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0302 RFC0303 ARPA Network mailing lists Network Information Center. Stanford Research Institute March 1972 ASCII 18193 11 RFC0300 RFC0329 UNKNOWN UNKNOWN Legacy 10.17487/RFC0303 RFC0304 Data Management System Proposal for the ARPA Network D.B. McKay February 1972 ASCII 20446 8 PDF 465564 UNKNOWN UNKNOWN Legacy 10.17487/RFC0304 RFC0305 Unknown Host Numbers R. Alter February 1972 ASCII 1998 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0305 RFC0306 Network host status E. Westheimer February 1972 ASCII 7485 4 RFC0298 RFC0315 UNKNOWN UNKNOWN Legacy 10.17487/RFC0306 RFC0307 Using network Remote Job Entry E. Harslem February 1972 ASCII 12032 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0307 RFC0308 ARPANET host availability data M. Seriff March 1972 ASCII 5948 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0308 RFC0309 Data and File Transfer Workshop Announcement A.K. Bhushan March 1972 ASCII 9404 6 FTP DTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0309 RFC0310 Another Look at Data and File Transfer Protocols A.K. Bhushan April 1972 ASCII 18593 7 FTP RFC0264 RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0310 RFC0311 New Console Attachments to the USCB Host R.F. Bryan February 1972 ASCII 3141 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0311 RFC0312 Proposed Change in IMP-to-Host Protocol A.M. McKenzie March 1972 ASCII 3562 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0312 RFC0313 Computer based instruction T.C. O'Sullivan March 1972 ASCII 19880 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0313 RFC0314 Network Graphics Working Group Meeting I.W. Cotton March 1972 ASCII 1836 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0314 RFC0315 Network Host Status E. Westheimer March 1972 ASCII 7818 4 RFC0306 RFC0319 UNKNOWN UNKNOWN Legacy 10.17487/RFC0315 RFC0316 ARPA Network Data Management Working Group D.B. McKay A.P. Mullery February 1972 ASCII 15494 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0316 RFC0317 Official Host-Host Protocol Modification: Assigned Link Numbers J. Postel March 1972 ASCII 1593 1 RFC0604 UNKNOWN UNKNOWN Legacy 10.17487/RFC0317 RFC0318 Telnet Protocols J. Postel April 1972 ASCII 34928 16 RFC0158 RFC0435 RFC0139 RFC0158 UNKNOWN UNKNOWN Legacy 10.17487/RFC0318 RFC0319 Network Host Status E. Westheimer March 1972 ASCII 8955 4 RFC0315 RFC0326 UNKNOWN UNKNOWN Legacy 10.17487/RFC0319 RFC0320 Workshop on Hard Copy Line Graphics R. Reddy March 1972 ASCII 5600 3 PDF 14422 UNKNOWN UNKNOWN Legacy 10.17487/RFC0320 RFC0321 CBI Networking Activity at MITRE P.M. Karp March 1972 ASCII 20500 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0321 RFC0322 Well known socket numbers V. Cerf J. Postel March 1972 ASCII 1735 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0322 RFC0323 Formation of Network Measurement Group (NMG) V. Cerf March 1972 ASCII 15777 9 RFC0388 UNKNOWN UNKNOWN Legacy 10.17487/RFC0323 RFC0324 RJE Protocol meeting J. Postel April 1972 ASCII 1176 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0324 RFC0325 Network Remote Job Entry program - NETRJS G. Hicks April 1972 ASCII 17499 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0325 RFC0326 Network Host Status E. Westheimer April 1972 ASCII 7944 4 RFC0330 RFC0319 UNKNOWN UNKNOWN Legacy 10.17487/RFC0326 RFC0327 Data and File Transfer workshop notes A.K. Bhushan April 1972 ASCII 11792 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0327 RFC0328 Suggested Telnet Protocol Changes J. Postel April 1972 ASCII 2685 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0328 RFC0329 ARPA Network Mailing Lists Network Information Center. Stanford Research Institute May 1972 ASCII 23861 13 RFC0303 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0329 RFC0330 Network Host Status E. Westheimer April 1972 ASCII 8085 3 RFC0326 RFC0332 UNKNOWN UNKNOWN Legacy 10.17487/RFC0330 RFC0331 IMP System Change Notification J.M. McQuillan April 1972 ASCII 2339 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0331 RFC0332 Network Host Status E. Westheimer April 1972 ASCII 8427 4 RFC0342 RFC0330 UNKNOWN UNKNOWN Legacy 10.17487/RFC0332 RFC0333 Proposed experiment with a Message Switching Protocol R.D. Bressler D. Murphy D.C. Walden May 1972 ASCII 62507 26 UNKNOWN UNKNOWN Legacy 10.17487/RFC0333 RFC0334 Network Use on May 8 A.M. McKenzie May 1972 ASCII 1376 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0334 RFC0335 New Interface - IMP/360 R.F. Bryan May 1972 ASCII 934 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0335 RFC0336 Level 0 Graphic Input Protocol I.W. Cotton May 1972 ASCII 3787 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0336 RFC0337 RFC0338 EBCDIC/ASCII Mapping for Network RJE R.T. Braden May 1972 ASCII 11494 6 PS 2386987 PDF 1871020 UNKNOWN UNKNOWN Legacy 10.17487/RFC0338 RFC0339 MLTNET: A "Multi Telnet" Subsystem for Tenex R. Thomas May 1972 ASCII 7941 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0339 RFC0340 Proposed Telnet Changes T.C. O'Sullivan May 1972 ASCII 2656 2 RFC0328 UNKNOWN UNKNOWN Legacy 10.17487/RFC0340 RFC0341 RFC0342 Network Host Status E. Westheimer May 1972 ASCII 8382 4 RFC0332 RFC0344 UNKNOWN UNKNOWN Legacy 10.17487/RFC0342 RFC0343 IMP System change notification A.M. McKenzie May 1972 ASCII 3370 2 RFC0331 RFC0359 UNKNOWN UNKNOWN Legacy 10.17487/RFC0343 RFC0344 Network Host Status E. Westheimer May 1972 ASCII 8221 4 RFC0342 RFC0353 UNKNOWN UNKNOWN Legacy 10.17487/RFC0344 RFC0345 Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN) K.C. Kelley May 1972 ASCII 1999 1 MIP UNKNOWN UNKNOWN Legacy 10.17487/RFC0345 RFC0346 Satellite Considerations J. Postel May 1972 ASCII 2778 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0346 RFC0347 Echo process J. Postel May 1972 ASCII 1377 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0347 RFC0348 Discard Process J. Postel May 1972 ASCII 1181 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0348 RFC0349 Proposed Standard Socket Numbers J. Postel May 1972 ASCII 1663 1 RFC0433 RFC0204 RFC0322 UNKNOWN UNKNOWN Legacy 10.17487/RFC0349 RFC0350 User Accounts for UCSB On-Line System R. Stoughton May 1972 ASCII 5117 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0350 RFC0351 Graphics information form for the ARPANET graphics resources notebook D. Crocker June 1972 ASCII 2150 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0351 RFC0352 TIP Site Information Form D. Crocker June 1972 ASCII 2266 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0352 RFC0353 Network host status E. Westheimer June 1972 ASCII 8747 5 RFC0344 RFC0362 UNKNOWN UNKNOWN Legacy 10.17487/RFC0353 RFC0354 File Transfer Protocol A.K. Bhushan July 1972 ASCII 58074 25 FTP RFC0264 RFC0265 RFC0542 RFC0385 RFC0454 RFC0683 UNKNOWN UNKNOWN Legacy 10.17487/RFC0354 RFC0355 Response to NWG/RFC 346 J. Davidson June 1972 ASCII 3717 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0355 RFC0356 ARPA Network Control Center R. Alter June 1972 ASCII 1963 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0356 RFC0357 Echoing strategy for satellite links J. Davidson June 1972 ASCII 30103 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0357 RFC0358 RFC0359 Status of the Release of the New IMP System (2600) D.C. Walden June 1972 ASCII 2015 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0359 RFC0360 Proposed Remote Job Entry Protocol C. Holland June 1972 ASCII 39473 18 PDF 1187574 RFC0407 UNKNOWN UNKNOWN Legacy 10.17487/RFC0360 RFC0361 Deamon Processes on Host 106 R.D. Bressler July 1972 ASCII 1480 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0361 RFC0362 Network Host Status E. Westheimer June 1972 ASCII 8631 4 RFC0353 RFC0366 UNKNOWN UNKNOWN Legacy 10.17487/RFC0362 RFC0363 ARPA Network mailing lists Network Information Center. Stanford Research Institute August 1972 ASCII 25356 13 RFC0329 RFC0402 UNKNOWN UNKNOWN Legacy 10.17487/RFC0363 RFC0364 Serving remote users on the ARPANET M.D. Abrams July 1972 ASCII 11253 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0364 RFC0365 Letter to All TIP Users D.C. Walden July 1972 ASCII 10331 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0365 RFC0366 Network Host Status E. Westheimer July 1972 ASCII 8278 4 RFC0362 RFC0367 UNKNOWN UNKNOWN Legacy 10.17487/RFC0366 RFC0367 Network host status E. Westheimer July 1972 ASCII 8057 4 RFC0366 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0367 RFC0368 Comments on "Proposed Remote Job Entry Protocol" R.T. Braden July 1972 ASCII 3883 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0368 RFC0369 Evaluation of ARPANET services January-March, 1972 J.R. Pickens July 1972 ASCII 24414 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0369 RFC0370 Network Host Status E. Westheimer July 1972 ASCII 8389 5 RFC0367 RFC0376 UNKNOWN UNKNOWN Legacy 10.17487/RFC0370 RFC0371 Demonstration at International Computer Communications Conference R.E. Kahn July 1972 ASCII 3728 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0371 RFC0372 Notes on a Conversation with Bob Kahn on the ICCC R.W. Watson July 1972 ASCII 6040 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0372 RFC0373 Arbitrary Character Sets J. McCarthy July 1972 ASCII 7783 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0373 RFC0374 IMP System Announcement A.M. McKenzie July 1972 ASCII 3963 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0374 RFC0375 RFC0376 Network Host Status E. Westheimer August 1972 ASCII 8861 5 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0376 RFC0377 Using TSO via ARPA Network Virtual Terminal R.T. Braden August 1972 ASCII 7093 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0377 RFC0378 Traffic statistics (July 1972) A.M. McKenzie August 1972 ASCII 5730 3 RFC0391 UNKNOWN UNKNOWN Legacy 10.17487/RFC0378 RFC0379 Using TSO at CCN R. Braden August 1972 ASCII 8674 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0379 RFC0380 RFC0381 Three aids to improved network operation J.M. McQuillan July 1972 ASCII 9305 4 RFC0394 UNKNOWN UNKNOWN Legacy 10.17487/RFC0381 RFC0382 Mathematical Software on the ARPA Network L. McDaniel August 1972 ASCII 2041 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0382 RFC0383 RFC0384 Official site idents for organizations in the ARPA Network J.B. North August 1972 ASCII 10401 4 RFC0289 UNKNOWN UNKNOWN Legacy 10.17487/RFC0384 RFC0385 Comments on the File Transfer Protocol A.K. Bhushan August 1972 ASCII 13030 6 FTP RFC0354 RFC0414 UNKNOWN UNKNOWN Legacy 10.17487/RFC0385 RFC0386 Letter to TIP users-2 B. Cosell D.C. Walden August 1972 ASCII 12475 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0386 RFC0387 Some experiences in implementing Network Graphics Protocol Level 0 K.C. Kelley J. Meir August 1972 ASCII 9059 5 RFC0401 UNKNOWN UNKNOWN Legacy 10.17487/RFC0387 RFC0388 NCP statistics V. Cerf August 1972 ASCII 8458 5 RFC0323 UNKNOWN UNKNOWN Legacy 10.17487/RFC0388 RFC0389 UCLA Campus Computing Network Liaison Staff for ARPA Network B. Noble August 1972 ASCII 2819 2 RFC0423 UNKNOWN UNKNOWN Legacy 10.17487/RFC0389 RFC0390 TSO Scenario R.T. Braden September 1972 ASCII 6103 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0390 RFC0391 Traffic statistics (August 1972) A.M. McKenzie September 1972 ASCII 4695 3 RFC0378 UNKNOWN UNKNOWN Legacy 10.17487/RFC0391 RFC0392 Measurement of host costs for transmitting network data G. Hicks B.D. Wessler September 1972 ASCII 14462 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0392 RFC0393 Comments on Telnet Protocol Changes J.M. Winett October 1972 ASCII 9435 4 RFC0109 RFC0139 RFC0158 RFC0318 RFC0328 UNKNOWN UNKNOWN Legacy 10.17487/RFC0393 RFC0394 Two Proposed Changes to the IMP-Host Protocol J.M. McQuillan September 1972 ASCII 5780 3 RFC0381 UNKNOWN UNKNOWN Legacy 10.17487/RFC0394 RFC0395 Switch Settings on IMPs and TIPs J.M. McQuillan October 1972 ASCII 1827 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0395 RFC0396 Network Graphics Working Group Meeting - Second Iteration S. Bunch November 1972 ASCII 2224 1 RFC0474 UNKNOWN UNKNOWN Legacy 10.17487/RFC0396 RFC0397 RFC0398 UCSB Online Graphics J.R. Pickens E. Faeh September 1972 ASCII 3846 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0398 RFC0399 SMFS Login and Logout M. Krilanovich September 1972 ASCII 3024 2 RFC0431 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0399 RFC0400 Traffic Statistics (September 1972) A.M. McKenzie October 1972 ASCII 5435 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0400 RFC0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates J. Hansen October 1972 ASCII 3894 2 RFC0387 UNKNOWN UNKNOWN Legacy 10.17487/RFC0401 RFC0402 ARPA Network Mailing Lists J.B. North October 1972 ASCII 28162 16 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0402 RFC0403 Desirability of a Network 1108 Service G. Hicks January 1973 ASCII 9750 5 PDF 219744 UNKNOWN UNKNOWN Legacy 10.17487/RFC0403 RFC0404 Host Address Changes Involving Rand and ISI A.M. McKenzie October 1972 ASCII 944 1 RFC0405 UNKNOWN UNKNOWN Legacy 10.17487/RFC0404 RFC0405 Correction to RFC 404 A.M. McKenzie October 1972 ASCII 1103 1 RFC0404 UNKNOWN UNKNOWN Legacy 10.17487/RFC0405 RFC0406 Scheduled IMP Software Releases J.M. McQuillan October 1972 ASCII 2468 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0406 RFC0407 Remote Job Entry Protocol R.D. Bressler R. Guida A.M. McKenzie October 1972 ASCII 47556 21 RJE RFC0360 HISTORIC HISTORIC Legacy 10.17487/RFC0407 RFC0408 NETBANK A.D. Owen J. Postel October 1972 ASCII 1645 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0408 RFC0409 Tenex interface to UCSB's Simple-Minded File System J.E. White December 1972 ASCII 14231 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0409 RFC0410 Removal of the 30-Second Delay When Hosts Come Up J.M. McQuillan November 1972 ASCII 3964 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0410 RFC0411 New MULTICS Network Software Features M.A. Padlipsky November 1972 ASCII 3024 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0411 RFC0412 User FTP Documentation G. Hicks November 1972 ASCII 17510 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0412 RFC0413 Traffic statistics (October 1972) A.M. McKenzie November 1972 ASCII 16145 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0413 RFC0414 File Transfer Protocol (FTP) status and further comments A.K. Bhushan December 1972 ASCII 12845 5 RFC0385 UNKNOWN UNKNOWN Legacy 10.17487/RFC0414 RFC0415 Tenex bandwidth H. Murray November 1972 ASCII 3456 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0415 RFC0416 ARC System Will Be Unavailable for Use During Thanksgiving Week J.C. Norton November 1972 ASCII 2205 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0416 RFC0417 Link usage violation J. Postel C. Kline December 1972 ASCII 901 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0417 RFC0418 Server File Transfer Under TSS/360 At NASA-Ames Research Center W. Hathaway November 1972 PDF 1080191 UNKNOWN UNKNOWN Legacy 10.17487/RFC0418 RFC0419 To: Network liaisons and station agents A. Vezza December 1972 ASCII 1252 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0419 RFC0420 CCA ICCC weather demo H. Murray January 1973 ASCII 14752 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0420 RFC0421 Software Consulting Service for Network Users A.M. McKenzie November 1972 ASCII 2483 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0421 RFC0422 Traffic statistics (November 1972) A.M. McKenzie December 1972 ASCII 5494 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0422 RFC0423 UCLA Campus Computing Network Liaison Staff for ARPANET B. Noble December 1972 ASCII 2890 2 RFC0389 UNKNOWN UNKNOWN Legacy 10.17487/RFC0423 RFC0424 RFC0425 "But my NCP costs $500 a day" R.D. Bressler December 1972 ASCII 1763 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0425 RFC0426 Reconnection Protocol R. Thomas January 1973 ASCII 26548 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0426 RFC0427 RFC0428 RFC0429 Character Generator Process J. Postel December 1972 ASCII 1319 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0429 RFC0430 Comments on File Transfer Protocol R.T. Braden February 1973 ASCII 18696 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0430 RFC0431 Update on SMFS Login and Logout M. Krilanovich December 1972 ASCII 4196 3 RFC0399 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0431 RFC0432 Network logical map N. Neigus December 1972 ASCII 1291 1 PDF 148880 PS 1344571 UNKNOWN UNKNOWN Legacy 10.17487/RFC0432 RFC0433 Socket number list J. Postel December 1972 ASCII 6834 5 RFC0349 RFC0503 UNKNOWN UNKNOWN Legacy 10.17487/RFC0433 RFC0434 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII 2242 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0434 RFC0435 Telnet issues B. Cosell D.C. Walden January 1973 ASCII 23019 10 RFC0318 UNKNOWN UNKNOWN Legacy 10.17487/RFC0435 RFC0436 Announcement of RJS at UCSB M. Krilanovich January 1973 ASCII 2579 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0436 RFC0437 Data Reconfiguration Service at UCSB E. Faeh June 1973 ASCII 21562 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0437 RFC0438 FTP server-server interaction R. Thomas R. Clements January 1973 ASCII 6514 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0438 RFC0439 PARRY encounters the DOCTOR V. Cerf January 1973 ASCII 7066 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0439 RFC0440 Scheduled network software maintenance D.C. Walden January 1973 ASCII 1870 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0440 RFC0441 Inter-Entity Communication - an experiment R.D. Bressler R. Thomas January 1973 ASCII 12876 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0441 RFC0442 Current flow-control scheme for IMPSYS V. Cerf January 1973 ASCII 16315 7 RFC0449 UNKNOWN UNKNOWN Legacy 10.17487/RFC0442 RFC0443 Traffic statistics (December 1972) A.M. McKenzie January 1973 ASCII 5664 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0443 RFC0444 RFC0445 IMP/TIP preventive maintenance schedule A.M. McKenzie January 1973 ASCII 2668 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0445 RFC0446 Proposal to consider a network program resource notebook L.P. Deutsch January 1973 ASCII 3053 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0446 RFC0447 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII 2332 2 RFC0434 RFC0476 UNKNOWN UNKNOWN Legacy 10.17487/RFC0447 RFC0448 Print files in FTP R.T. Braden February 1973 ASCII 6838 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0448 RFC0449 Current flow-control scheme for IMPSYS D.C. Walden January 1973 ASCII 1662 1 RFC0442 UNKNOWN UNKNOWN Legacy 10.17487/RFC0449 RFC0450 MULTICS sampling timeout change M.A. Padlipsky February 1973 ASCII 924 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0450 RFC0451 Tentative proposal for a Unified User Level Protocol M.A. Padlipsky February 1973 ASCII 8114 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0451 RFC0452 TELNET Command at Host LL J. Winett February 1973 ASCII 28415 14 PDF 777983 UNKNOWN UNKNOWN Legacy 10.17487/RFC0452 RFC0453 Meeting announcement to discuss a network mail system M.D. Kudlick February 1973 ASCII 4572 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0453 RFC0454 File Transfer Protocol - meeting announcement and a new proposed document A.M. McKenzie February 1973 ASCII 78966 35 FTP RFC0354 UNKNOWN UNKNOWN Legacy 10.17487/RFC0454 RFC0455 Traffic statistics (January 1973) A.M. McKenzie February 1973 ASCII 5746 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0455 RFC0456 Memorandum: Date change of mail meeting M.D. Kudlick February 1973 ASCII 950 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0456 RFC0457 TIPUG D.C. Walden February 1973 ASCII 845 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0457 RFC0458 Mail retrieval via FTP R.D. Bressler R. Thomas February 1973 ASCII 2705 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0458 RFC0459 Network questionnaires W. Kantrowitz February 1973 ASCII 1950 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0459 RFC0460 NCP survey C. Kline February 1973 ASCII 10324 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0460 RFC0461 Telnet Protocol meeting announcement A.M. McKenzie February 1973 ASCII 1966 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0461 RFC0462 Responding to user needs J. Iseli D. Crocker February 1973 ASCII 2808 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0462 RFC0463 FTP comments and response to RFC 430 A.K. Bhushan February 1973 ASCII 5729 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0463 RFC0464 Resource notebook framework M.D. Kudlick February 1973 ASCII 3684 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0464 RFC0465 RFC0466 Telnet logger/server for host LL-67 J.M. Winett February 1973 ASCII 17595 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0466 RFC0467 Proposed change to Host-Host Protocol: Resynchronization of connection status J.D. Burchfiel R.S. Tomlinson February 1973 ASCII 14325 7 RFC0492 UNKNOWN UNKNOWN Legacy 10.17487/RFC0467 RFC0468 FTP data compression R.T. Braden March 1973 ASCII 14909 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0468 RFC0469 Network mail meeting summary M.D. Kudlick March 1973 ASCII 17774 10 network mail meeting UNKNOWN UNKNOWN Legacy 10.17487/RFC0469 RFC0470 Change in socket for TIP news facility R. Thomas March 1973 ASCII 1014 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0470 RFC0471 Workshop on multi-site executive programs R. Thomas March 1973 ASCII 3339 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0471 RFC0472 Illinois' reply to Maxwell's request for graphics information (NIC 14925) S. Bunch March 1973 ASCII 4780 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0472 RFC0473 MIX and MIXAL? D.C. Walden February 1973 ASCII 868 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0473 RFC0474 Announcement of NGWG meeting: Call for papers S. Bunch March 1973 ASCII 1170 2 RFC0396 UNKNOWN UNKNOWN Legacy 10.17487/RFC0474 RFC0475 FTP and Network Mail System A.K. Bhushan March 1973 ASCII 21928 5 PDF 600361 UNKNOWN UNKNOWN Legacy 10.17487/RFC0475 RFC0476 IMP/TIP memory retrofit schedule (rev 2) A.M. McKenzie March 1973 ASCII 2281 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0476 RFC0477 Remote Job Service at UCSB M. Krilanovich May 1973 ASCII 40535 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0477 RFC0478 FTP server-server interaction - II R.D. Bressler R. Thomas March 1973 ASCII 4199 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0478 RFC0479 Use of FTP by the NIC Journal J.E. White March 1973 ASCII 11183 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0479 RFC0480 Host-dependent FTP parameters J.E. White March 1973 ASCII 2084 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0480 RFC0481 RFC0482 Traffic statistics (February 1973) A.M. McKenzie March 1973 ASCII 6162 4 RFC0497 UNKNOWN UNKNOWN Legacy 10.17487/RFC0482 RFC0483 Cancellation of the resource notebook framework meeting M.D. Kudlick March 1973 ASCII 1021 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0483 RFC0484 RFC0485 MIX and MIXAL at UCSB J.R. Pickens March 1973 ASCII 2226 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0485 RFC0486 Data transfer revisited R.D. Bressler March 1973 ASCII 4664 2 RJE FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0486 RFC0487 Free file transfer R.D. Bressler April 1973 ASCII 3249 2 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0487 RFC0488 NLS classes at network sites M.F. Auerbach March 1973 ASCII 3806 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0488 RFC0489 Comment on resynchronization of connection status proposal J. Postel March 1973 ASCII 2010 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0489 RFC0490 Surrogate RJS for UCLA-CCN J.R. Pickens March 1973 ASCII 9858 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0490 RFC0491 What is "Free"? M.A. Padlipsky April 1973 ASCII 5872 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0491 RFC0492 Response to RFC 467 E. Meyer April 1973 ASCII 18791 7 RFC0467 UNKNOWN UNKNOWN Legacy 10.17487/RFC0492 RFC0493 GRAPHICS PROTOCOL J.C. Michener I.W. Cotton K.C. Kelley D.E. Liddle E. Meyer April 1973 ASCII 67843 28 PDF 1563891 RFC0292 UNKNOWN UNKNOWN Legacy 10.17487/RFC0493 RFC0494 Availability of MIX and MIXAL in the Network D.C. Walden April 1973 ASCII 2007 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0494 RFC0495 Telnet Protocol specifications A.M. McKenzie May 1973 ASCII 4260 2 RFC0158 RFC0562 UNKNOWN UNKNOWN Legacy 10.17487/RFC0495 RFC0496 TNLS quick reference card is available M.F. Auerbach April 1973 ASCII 1110 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0496 RFC0497 Traffic Statistics (March 1973) A.M. McKenzie April 1973 ASCII 6078 4 PDF 191264 RFC0482 UNKNOWN UNKNOWN Legacy 10.17487/RFC0497 RFC0498 On mail service to CCN R.T. Braden April 1973 ASCII 5315 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0498 RFC0499 Harvard's network RJE B.R. Reussow April 1973 ASCII 12584 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0499 RFC0500 Integration of data management systems on a computer network A. Shoshani I. Spiegler April 1973 PDF 3045801 UNKNOWN UNKNOWN Legacy 10.17487/RFC0500 RFC0501 Un-muddling "free file transfer" K.T. Pogran May 1973 ASCII 13177 5 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0501 RFC0502 RFC0503 Socket number list N. Neigus J. Postel April 1973 ASCII 8690 8 RFC0433 RFC0739 UNKNOWN UNKNOWN Legacy 10.17487/RFC0503 RFC0504 Distributed resources workshop announcement R. Thomas April 1973 ASCII 9061 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0504 RFC0505 Two solutions to a file transfer access problem M.A. Padlipsky June 1973 ASCII 7476 3 FTP free UNKNOWN UNKNOWN Legacy 10.17487/RFC0505 RFC0506 FTP command naming problem M.A. Padlipsky June 1973 ASCII 1974 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0506 RFC0507 RFC0508 Real-time data transmission on the ARPANET L. Pfeifer J. McAfee May 1973 ASCII 25002 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0508 RFC0509 Traffic statistics (April 1973) A.M. McKenzie April 1973 ASCII 6538 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0509 RFC0510 Request for network mailbox addresses J.E. White May 1973 ASCII 4150 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0510 RFC0511 Enterprise phone service to NIC from ARPANET sites J.B. North May 1973 ASCII 4664 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0511 RFC0512 More on lost message detection W. Hathaway May 1973 ASCII 3641 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0512 RFC0513 Comments on the new Telnet specifications W. Hathaway May 1973 ASCII 7980 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0513 RFC0514 Network make-work W. Kantrowitz June 1973 ASCII 8734 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0514 RFC0515 Specifications for Datalanguage, Version 0/9 R. Winter June 1973 ASCII 60557 31 UNKNOWN UNKNOWN Legacy 10.17487/RFC0515 RFC0516 Lost message detection J. Postel May 1973 ASCII 4086 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0516 RFC0517 RFC0518 ARPANET accounts N. Vaughan E.J. Feinler June 1973 ASCII 12880 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0518 RFC0519 Resource Evaluation J.R. Pickens June 1973 ASCII 7750 4 PDF 224969 UNKNOWN UNKNOWN Legacy 10.17487/RFC0519 RFC0520 Memo to FTP group: Proposal for File Access Protocol J.D. Day June 1973 ASCII 16825 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0520 RFC0521 Restricted use of IMP DDT A.M. McKenzie May 1973 ASCII 3724 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0521 RFC0522 Traffic Statistics (May 1973) A.M. McKenzie June 1973 ASCII 6125 4 PDF 163705 RFC0509 UNKNOWN UNKNOWN Legacy 10.17487/RFC0522 RFC0523 SURVEY is in operation again A.K. Bhushan June 1973 ASCII 2852 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0523 RFC0524 Proposed Mail Protocol J.E. White June 1973 ASCII 75385 40 UNKNOWN UNKNOWN Legacy 10.17487/RFC0524 RFC0525 MIT-MATHLAB meets UCSB-OLS -an example of resource sharing W. Parrish J.R. Pickens June 1973 ASCII 18501 9 PS 304440 PDF 228274 UNKNOWN UNKNOWN Legacy 10.17487/RFC0525 RFC0526 Technical meeting: Digital image processing software systems W.K. Pratt June 1973 ASCII 4062 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0526 RFC0527 ARPAWOCKY R. Merryman May 1973 ASCII 1857 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0527 RFC0528 Software checksumming in the IMP and network reliability J.M. McQuillan June 1973 ASCII 23152 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0528 RFC0529 Note on protocol synch sequences A.M. McKenzie R. Thomas R.S. Tomlinson K.T. Pogran June 1973 ASCII 9068 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0529 RFC0530 Report on the Survey Project A.K. Bhushan June 1973 PDF 408102 RFC0308 RFC0523 UNKNOWN UNKNOWN Legacy 10.17487/RFC0530 RFC0531 Feast or famine? A response to two recent RFC's about network information M.A. Padlipsky June 1973 ASCII 5070 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0531 RFC0532 UCSD-CC Server-FTP facility R.G. Merryman July 1973 ASCII 7298 4 FTP server UNKNOWN UNKNOWN Legacy 10.17487/RFC0532 RFC0533 Message-ID numbers D.C. Walden July 1973 ASCII 2102 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0533 RFC0534 Lost message detection D.C. Walden July 1973 ASCII 3227 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0534 RFC0535 Comments on File Access Protocol R. Thomas July 1973 ASCII 8393 4 PDF 239916 UNKNOWN UNKNOWN Legacy 10.17487/RFC0535 RFC0536 RFC0537 Announcement of NGG meeting July 16-17 S. Bunch June 1973 ASCII 2695 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0537 RFC0538 Traffic statistics (June 1973) A.M. McKenzie July 1973 ASCII 6389 4 RFC0556 UNKNOWN UNKNOWN Legacy 10.17487/RFC0538 RFC0539 Thoughts on the mail protocol proposed in RFC 524 D. Crocker J. Postel July 1973 ASCII 6213 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0539 RFC0540 RFC0541 RFC0542 File Transfer Protocol N. Neigus August 1973 ASCII 100666 40 FTP RFC0354 RFC0765 RFC0614 RFC0640 RFC0454 RFC0495 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=542 10.17487/RFC0542 RFC0543 Network journal submission and delivery N.D. Meyer July 1973 ASCII 15621 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0543 RFC0544 Locating on-line documentation at SRI-ARC N.D. Meyer K. Kelley July 1973 ASCII 1541 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0544 RFC0545 Of what quality be the UCSB resources evaluators? J.R. Pickens July 1973 ASCII 3754 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0545 RFC0546 Tenex load averages for July 1973 R. Thomas August 1973 ASCII 6632 4 PS 356023 PDF 268918 UNKNOWN UNKNOWN Legacy 10.17487/RFC0546 RFC0547 Change to the Very Distant Host specification D.C. Walden August 1973 ASCII 6236 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0547 RFC0548 Hosts using the IMP Going Down message D.C. Walden August 1973 ASCII 1435 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0548 RFC0549 Minutes of Network Graphics Group meeting, 15-17 July 1973 J.C. Michener July 1973 ASCII 23367 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0549 RFC0550 NIC NCP experiment L.P. Deutsch August 1973 ASCII 3688 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0550 RFC0551 NYU, ANL, and LBL Joining the Net Y. Feinroth R. Fink August 1973 ASCII 3020 2 PDF 73188 UNKNOWN UNKNOWN Legacy 10.17487/RFC0551 RFC0552 Single access to standard protocols A.D. Owen July 1973 ASCII 1404 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0552 RFC0553 Draft design for a text/graphics protocol C.H. Irby K. Victor July 1973 ASCII 35414 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0553 RFC0554 RFC0555 Responses to critiques of the proposed mail protocol J.E. White July 1973 ASCII 21521 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0555 RFC0556 Traffic Statistics (July 1973) A.M. McKenzie August 1973 ASCII 6648 4 PDF 142156 RFC0538 UNKNOWN UNKNOWN Legacy 10.17487/RFC0556 RFC0557 REVELATIONS IN NETWORK HOST MEASUREMENTS B.D. Wessler August 1973 ASCII 3167 2 PDF 90256 UNKNOWN UNKNOWN Legacy 10.17487/RFC0557 RFC0558 RFC0559 Comments on The New Telnet Protocol and its Implementation A.K. Bushan August 1973 ASCII 10643 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0559 RFC0560 Remote Controlled Transmission and Echoing Telnet option D. Crocker J. Postel August 1973 ASCII 22686 12 PDF 649235 RFC0581 UNKNOWN UNKNOWN Legacy 10.17487/RFC0560 RFC0561 Standardizing Network Mail Headers A.K. Bhushan K.T. Pogran R.S. Tomlinson J.E. White September 1973 ASCII 6159 3 RFC0680 UNKNOWN UNKNOWN Legacy 10.17487/RFC0561 RFC0562 Modifications to the TELNET Specification A.M. McKenzie August 1973 ASCII 2760 2 PDF 79307 RFC0495 UNKNOWN UNKNOWN Legacy 10.17487/RFC0562 RFC0563 Comments on the RCTE Telnet option J. Davidson August 1973 ASCII 10788 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0563 RFC0564 RFC0565 Storing network survey data at the datacomputer D. Cantor August 1973 ASCII 9307 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0565 RFC0566 Traffic statistics (August 1973) A.M. McKenzie September 1973 ASCII 6674 4 RFC0579 UNKNOWN UNKNOWN Legacy 10.17487/RFC0566 RFC0567 Cross Country Network Bandwidth L.P. Deutsch September 1973 ASCII 1529 1 RFC0568 UNKNOWN UNKNOWN Legacy 10.17487/RFC0567 RFC0568 Response to RFC 567 - cross country network bandwidth J.M. McQuillan September 1973 ASCII 3244 3 RFC0567 UNKNOWN UNKNOWN Legacy 10.17487/RFC0568 RFC0569 NETED: A Common Editor for the ARPA Network M.A. Padlipsky October 1973 ASCII 17717 6 NETED HISTORIC HISTORIC Legacy 10.17487/RFC0569 RFC0570 Experimental input mapping between NVT ASCII and UCSB On Line System J.R. Pickens October 1973 ASCII 177 1 PS 488023 PDF 375635 UNKNOWN UNKNOWN Legacy 10.17487/RFC0570 RFC0571 TENEX FTP PROBLEM R. Braden November 1973 ASCII 1530 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0571 RFC0572 RFC0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS A. Bhushan September 1973 ASCII 19474 8 PDF 543794 UNKNOWN UNKNOWN Legacy 10.17487/RFC0573 RFC0574 Announcement of a Mail Facility at UCSB M. Krilanovich September 1973 ASCII 1253 1 PDF 40358 UNKNOWN UNKNOWN Legacy 10.17487/RFC0574 RFC0575 RFC0576 Proposal for modifying linking K. Victor September 1973 ASCII 3916 2 PDF 175955 UNKNOWN UNKNOWN Legacy 10.17487/RFC0576 RFC0577 Mail priority D. Crocker October 1973 ASCII 2434 2 PDF 91292 UNKNOWN UNKNOWN Legacy 10.17487/RFC0577 RFC0578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle A.K. Bhushan N.D. Ryan October 1973 ASCII 21185 9 PDF 1044808 UNKNOWN UNKNOWN Legacy 10.17487/RFC0578 RFC0579 Traffic statistics (September 1973) A.M. McKenzie November 1973 ASCII 7827 5 PDF 283306 RFC0566 RFC0586 UNKNOWN UNKNOWN Legacy 10.17487/RFC0579 RFC0580 Note to Protocol Designers and Implementers J. Postel October 1973 ASCII 1451 1 RFC0582 UNKNOWN UNKNOWN Legacy 10.17487/RFC0580 RFC0581 Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option D. Crocker J. Postel November 1973 ASCII 11060 5 PDF 385657 RFC0560 UNKNOWN UNKNOWN Legacy 10.17487/RFC0581 RFC0582 Comments on RFC 580: Machine readable protocols R. Clements November 1973 ASCII 1635 1 RFC0580 UNKNOWN UNKNOWN Legacy 10.17487/RFC0582 RFC0583 RFC0584 Charter for ARPANET Users Interest Working Group J. Iseli D. Crocker N. Neigus November 1973 ASCII 3461 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0584 RFC0585 ARPANET users interest working group meeting D. Crocker N. Neigus E.J. Feinler J. Iseli November 1973 ASCII 18243 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0585 RFC0586 Traffic statistics (October 1973) A.M. McKenzie November 1973 ASCII 7428 5 PDF 231714 RFC0579 UNKNOWN UNKNOWN Legacy 10.17487/RFC0586 RFC0587 Announcing New Telnet Options J. Postel November 1973 ASCII 832 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0587 RFC0588 London Node Is Now Up A. Stokes October 1973 ASCII 5608 3 PDF 180352 UNKNOWN UNKNOWN Legacy 10.17487/RFC0588 RFC0589 CCN NETRJS server messages to remote user R.T. Braden November 1973 ASCII 7998 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0589 RFC0590 MULTICS address change M.A. Padlipsky November 1973 ASCII 1436 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0590 RFC0591 Addition to the Very Distant Host specifications D.C. Walden November 1973 ASCII 901 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0591 RFC0592 Some thoughts on system design to facilitate resource sharing R.W. Watson November 1973 ASCII 10323 5 PDF 289505 UNKNOWN UNKNOWN Legacy 10.17487/RFC0592 RFC0593 Telnet and FTP implementation schedule change A.M. McKenzie J. Postel November 1973 ASCII 2506 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0593 RFC0594 Speedup of Host-IMP interface J.D. Burchfiel December 1973 ASCII 5855 3 PDF 182977 UNKNOWN UNKNOWN Legacy 10.17487/RFC0594 RFC0595 Second thoughts in defense of the Telnet Go-Ahead W. Hathaway December 1973 ASCII 13507 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0595 RFC0596 Second thoughts on Telnet Go-Ahead E.A. Taft December 1973 ASCII 11919 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0596 RFC0597 Host status N. Neigus E.J. Feinler December 1973 ASCII 11678 6 RFC0603 UNKNOWN UNKNOWN Legacy 10.17487/RFC0597 RFC0598 RFC index - December 5, 1973 Network Information Center. Stanford Research Institute December 1973 PDF 1078956 UNKNOWN UNKNOWN Legacy 10.17487/RFC0598 RFC0599 Update on NETRJS R.T. Braden December 1973 ASCII 16590 9 RFC0189 RFC0740 UNKNOWN UNKNOWN Legacy 10.17487/RFC0599 RFC0600 Interfacing an Illinois plasma terminal to the ARPANET A. Berggreen November 1973 ASCII 8510 3 PDF 213041

Discusses some unusual interface issues for the Plato terminal.

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

Susceptibility of ARPANET to security violations.

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

Questions about the ARPANET topology described in RFC 597.

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

Modifies official host-host protocol. Replaces RFC 377.

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

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

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

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

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

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

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

See also RFCs 621 and 620.

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

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

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

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

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

See also RFCs 624, 542 and 640.

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

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

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

Distribution of NCP and IMP message types by actual measurement.

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

Actual measurements of round-trip times.

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

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

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

See also RFCs 620 and 609.

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

Modification of previous policy.

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

See also RFCs 627, 625, 608 and 606.

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

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

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

See also RFCs 606, 608, 623 and 627.

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

See also RFCs 606, 608, 623 and 625.

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

Describes FTP reply-code usage in TENEX mail processing.

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

An old version; see RFC 638.

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

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

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

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

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

Corrects RFC 633.

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

Updates RFC 542.

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

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

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

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

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

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

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

Options defined in RFCs 651-658.

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

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

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

An old version; see RFC 694.

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

Experimenting with host output buffers to improve throughput.

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

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

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

Discusses and proposes a common command language.

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

Approved scheme to connect host ports to the network.

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

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

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

Experience with implementation in RSEXEC context.

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

Applicability of TIP/TENEX protocols beyond TIP accounting.

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

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

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

The first detailed specification of TCP; see RFC 793.

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

For transmission of documents across different environments.

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

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

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

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

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

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

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

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

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

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

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

The contribution of ARPANET communication to response time.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discusses FTP login access to "files only" directories.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HISTORIC HISTORIC Legacy 10.17487/RFC0818
RFC0819 Domain naming convention for Internet user applications Z. Su J. Postel August 1982 ASCII 35314 18

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

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

This RFC is an old version, see RFC 870.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This RFC has been revised, see RFC 880.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 STD0013 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1035 10.17487/RFC1035
RFC1036 Standard for interchange of USENET messages M.R. Horton R. Adams December 1987 ASCII 46891 19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

STD0047 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1055
RFC1056 PCMAIL: A distributed mail system for personal computers M.L. Lambert June 1988 ASCII 85368 38 PCMAIL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RFC1120 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1160
RFC1161 SNMP over OSI M.T. Rose June 1990 ASCII 16036 8

This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community,

RFC1418 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1161
RFC1162 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base G. Satz June 1990 ASCII 109893 70

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community.

RFC1238 EXPERIMENTAL EXPERIMENTAL IETF snmp 10.17487/RFC1162
RFC1163 Border Gateway Protocol (BGP) K. Lougheed Y. Rekhter June 1990 ASCII 69404 29 BGP

This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1105 RFC1267 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1163
RFC1164 Application of the Border Gateway Protocol in the Internet J.C. Honig D. Katz M. Mathis Y. Rekhter J.Y. Yu June 1990 ASCII 56278 23 BGP

This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1268 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1164
RFC1165 Network Time Protocol (NTP) over the OSI Remote Operations Service J. Crowcroft J.P. Onions June 1990 ASCII 18277 10 NTP-OSI

This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1165
RFC1166 Internet numbers S. Kirkpatrick M.K. Stahl M. Recker July 1990 ASCII 566778 182

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

RFC1117 RFC1062 RFC1020 RFC5737 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1166
RFC1167 Thoughts on the National Research and Education Network V.G. Cerf July 1990 ASCII 20682 8

The memo provides a brief outline of a National Research and Education Network (NREN). This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1167
RFC1168 Intermail and Commercial Mail Relay services A. Westine A.L. DeSchon J. Postel C.E. Ward July 1990 ASCII 40306 18 PS 149816 PDF 55890

This RFC discusses the history and evolution of the Intermail and Commercial mail systems. The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed. This RFC provides information for the Internet community, and does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1168
RFC1169 Explaining the role of GOSIP V.G. Cerf K.L. Mills August 1990 ASCII 30255 15

This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC). This RFC does not specify a standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1169
RFC1170 Public key standards and licenses R.B. Fougner January 1991 ASCII 3144 2

This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1170
RFC1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links D. Perkins July 1990 ASCII 92321 51

This memo specifies the Point-to-Point Protocol (PPP) as a Draft Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.

RFC1134 RFC1331 DRAFT STANDARD DRAFT STANDARD IETF int ppp 10.17487/RFC1171
RFC1172 Point-to-Point Protocol (PPP) initial configuration options D. Perkins R. Hobby July 1990 ASCII 76132 40

This memo specifies the Point-to-Point Protocol (PPP) Initial Configuration Options as a Proposed Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.

RFC1331 RFC1332 PROPOSED STANDARD PROPOSED STANDARD IETF int ppp 10.17487/RFC1172
RFC1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet J. VanBokkelen August 1990 ASCII 12527 5

This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet. It is a summary of the "oral tradition" of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions. It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet. This RFC does not specify a standard, or a policy of the IAB.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1173
RFC1174 IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status V.G. Cerf August 1990 ASCII 21321 9

This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1174
RFC1175 FYI on where to start: A bibliography of internetworking information K.L. Bowers T.L. LaQuey J.K. Reynolds K. Roubicek M.K. Stahl A. Yuan August 1990 ASCII 67330 43

This FYI RFC is a bibliography of information about TCP/IP internetworking, prepared by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 3.]

FYI0003 INFORMATIONAL INFORMATIONAL IETF userdoc 10.17487/RFC1175
RFC1176 Interactive Mail Access Protocol: Version 2 M.R. Crispin August 1990 ASCII 67330 30 IMAP2

This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server ("repository"). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

RFC1064 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1176
RFC1177 FYI on Questions and Answers: Answers to commonly asked "new internet user" questions G.S. Malkin A.N. Marine J.K. Reynolds August 1990 ASCII 52852 24

This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.]

RFC1206 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1177
RFC1178 Choosing a name for your computer D. Libes August 1990 ASCII 18472 8

This FYI RFC is a republication of a Communications of the ACM article on guidelines on what to do and what not to do when naming your computer. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 5.]

FYI0005 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1178
RFC1179 Line printer daemon protocol L. McLaughlin August 1990 ASCII 24324 14 LPDP

This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers). This memo is for informational purposes only, and does not specify an Internet standard. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1179
RFC1180 TCP/IP tutorial T.J. Socolofsky C.J. Kale January 1991 ASCII 65494 28

This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1180 10.17487/RFC1180
RFC1181 RIPE Terms of Reference R. Blokzijl September 1990 ASCII 2523 2

This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1181
RFC1182 RFC1183 New DNS RR Definitions C.F. Everhart L.A. Mamakos R. Ullmann P.V. Mockapetris October 1990 ASCII 23788 11 DNS-RR

This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.

RFC1034 RFC1035 RFC5395 RFC5864 RFC6195 RFC6895 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1183 10.17487/RFC1183
RFC1184 Telnet Linemode Option D.A. Borman October 1990 ASCII 53085 23 TOPT-LINE

This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol. It obsoletes RFC 1116. [STANDARDS-TRACK]

RFC1116 DRAFT STANDARD DRAFT STANDARD IETF app telnet 10.17487/RFC1184
RFC1185 TCP Extension for High-Speed Paths V. Jacobson R.T. Braden L. Zhang October 1990 ASCII 49508 21

This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

RFC1323 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1185
RFC1186 MD4 Message Digest Algorithm R.L. Rivest October 1990 ASCII 35391 18

This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard.

RFC1320 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1186
RFC1187 Bulk Table Retrieval with the SNMP M.T. Rose K. McCloghrie J.R. Davin October 1990 ASCII 27220 12 SNMP-BULK

This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1187
RFC1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks D. Katz October 1990 ASCII 22424 11

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

RFC1103 DRAFT STANDARD DRAFT STANDARD IETF int fddi 10.17487/RFC1188
RFC1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP) U.S. Warrier L. Besaw L. LaBarre B.D. Handspicker October 1990 ASCII 32928 15 CMOT

This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in the Internet. [STANDARDS-TRACK]

RFC1095 HISTORIC HISTORIC IETF oim 10.17487/RFC1189
RFC1190 Experimental Internet Stream Protocol: Version 2 (ST-II) C. Topolcic October 1990 ASCII 386909 148

This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

IEN119 RFC1819 EXPERIMENTAL EXPERIMENTAL IETF int cip 10.17487/RFC1190
RFC1191 Path MTU discovery J.C. Mogul S.E. Deering November 1990 ASCII 47936 19 IP-MTU

This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]

RFC1063 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1191
RFC1192 Commercialization of the Internet summary report B. Kahin November 1990 ASCII 35253 13

This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1192
RFC1193 Client requirements for real-time communication services D. Ferrari November 1990 ASCII 61540 24

This memo describes client requirements for real-time communication services. This memo provides information for the Internet community, and requests discussion and suggestions for improvements. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1193
RFC1194 Finger User Information Protocol D.P. Zimmerman November 1990 ASCII 24626 12

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. [STANDARDS-TRACK]

RFC0742 RFC1196 RFC1288 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1194
RFC1195 Use of OSI IS-IS for routing in TCP/IP and dual environments R.W. Callon December 1990 ASCII 187866 85 PS 362052 IS-IS

This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]

RFC1349 RFC5302 RFC5304 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1195 10.17487/RFC1195
RFC1196 Finger User Information Protocol D.P. Zimmerman December 1990 ASCII 24799 12

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. [STANDARDS-TRACK]

RFC1194 RFC0742 RFC1288 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1196
RFC1197 Using ODA for translating multimedia information M. Sherman December 1990 ASCII 3620 2

The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA). Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1197
RFC1198 FYI on the X window system R.W. Scheifler January 1991 ASCII 3629 3

This FYI RFC provides pointers to the published standards of the MIT X Consortium. This memo provides information for the Internet community. It does not specify any Internet standard.

FYI0006 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1198
RFC1199 Request for Comments Summary Notes: 1100-1199 J. Reynolds December 1991 ASCII 46443 22 Summary RFC INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1199 RFC1200 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board April 1991 ASCII 67069 31 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.

RFC1140 RFC1250 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1200
RFC1201 Transmitting IP traffic over ARCNET networks D. Provan February 1991 ASCII 16565 7 IP-ARC

This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network.This memo specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across ARCNET using the "ARCNET Packet Header Definition Standard". [STANDARDS-TRACK]

RFC1051 STD0046 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1201
RFC1202 Directory Assistance service M.T. Rose February 1991 ASCII 21645 11 DAS

This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection. This is a local mechanism. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1202
RFC1203 Interactive Mail Access Protocol: Version 3 J. Rice February 1991 ASCII 123325 49 IMAP3

This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

RFC1064 HISTORIC HISTORIC Legacy 10.17487/RFC1203
RFC1204 Message Posting Protocol (MPP) S. Yeh D. Lee February 1991 ASCII 11371 6 MPP

This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1204
RFC1205 5250 Telnet interface P. Chmielewski February 1991 ASCII 27179 12

This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation. This memo provides information for the Internet community. It does not specify any standard.

RFC2877 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1205
RFC1206 FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions G.S. Malkin A.N. Marine February 1991 ASCII 72479 32

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4]

RFC1177 RFC1325 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1206
RFC1207 FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions G.S. Malkin A.N. Marine J.K. Reynolds February 1991 ASCII 33385 15

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard.

FYI0007 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1207
RFC1208 A Glossary of Networking Terms O.J. Jacobsen D.C. Lynch March 1991 ASCII 41156 18

This RFC is a glossary adapted from "The INTEROP Pocket Glossary of Networking Terms" distributed at Interop '90. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1208
RFC1209 The Transmission of IP Datagrams over the SMDS Service D. Piscitello J. Lawrence March 1991 ASCII 24662 11 IP-SMDS Switched Multi-megabit Data Service

This memo defines a protocol for the transmission of IP and ARP packets over a Switched Multi-megabit Data Service Network configured as a logical IP subnetwork. [STANDARDS-TRACK]

STD0052 INTERNET STANDARD INTERNET STANDARD IETF int smds 10.17487/RFC1209
RFC1210 Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990 V.G. Cerf P.T. Kirstein B. Randell March 1991 ASCII 79048 36

This report complements a shorter printed version which appeared in a summary report of all the committees which met in Brussels and Washington last July, 1990. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1210
RFC1211 Problems with the maintenance of large mailing lists A. Westine J. Postel March 1991 ASCII 96167 54

This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1211
RFC1212 Concise MIB definitions M.T. Rose K. McCloghrie March 1991 ASCII 43579 19 Concise-MIB

This memo describes a straight-forward approach toward producing concise, yet descriptive, MIB modules. This memo defines a format for producing MIB modules. [STANDARDS-TRACK]

STD0016 INTERNET STANDARD INTERNET STANDARD IETF snmp 10.17487/RFC1212
RFC1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II K. McCloghrie M. Rose March 1991 ASCII 142158 70 MIB-II

This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

RFC1158 RFC2011 RFC2012 RFC2013 STD0017 INTERNET STANDARD INTERNET STANDARD IETF snmp 10.17487/RFC1213
RFC1214 OSI internet management: Management Information Base L. LaBarre April 1991 ASCII 172564 83 OIM-MIB-II

This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification. It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF oim 10.17487/RFC1214
RFC1215 Convention for defining traps for use with the SNMP M.T. Rose March 1991 ASCII 19336 9 SNMP-TRAPS

This memo suggests a straight-forward approach towards defining traps used with the SNMP. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL IETF snmp 10.17487/RFC1215
RFC1216 Gigabit network economics and paradigm shifts P. Richard P. Kynikos April 1 1991 ASCII 8130 4

This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1216
RFC1217 Memo from the Consortium for Slow Commotion Research (CSCR) V.G. Cerf April 1 1991 ASCII 11079 5

This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1217
RFC1218 Naming scheme for c=US North American Directory Forum April 1991 ASCII 42698 23

This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1255 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1218
RFC1219 On the assignment of subnet numbers P.F. Tsuchiya April 1991 ASCII 30609 13 SUBNETASGN

This memo suggests a new procedure for assigning subnet numbers. Use of this assignment technique within a network would be a purely local matter, and would not effect other networks. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1219
RFC1220 Point-to-Point Protocol extensions for bridging F. Baker April 1991 ASCII 38165 18

This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK]

RFC1638 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1220
RFC1221 Host Access Protocol (HAP) specification: Version 2 W. Edmond April 1991 ASCII 152740 68 HAP2

This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC0907 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1221
RFC1222 Advancing the NSFNET routing architecture H.W. Braun Y. Rekhter May 1991 ASCII 15067 6

This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1222
RFC1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel J.M. Halpern May 1991 ASCII 29601 12 OSI-HYPER

The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1223
RFC1224 Techniques for managing asynchronously generated alerts L. Steinberg May 1991 ASCII 54303 22 ALERTS

This memo defines common mechanisms for managing asynchronously produced alerts in a manner consistent with current network management protocols. This memo specifies an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL IETF alertman 10.17487/RFC1224
RFC1225 Post Office Protocol: Version 3 M.T. Rose May 1991 ASCII 37340 16

This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]

RFC1081 RFC1460 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1225
RFC1226 Internet protocol encapsulation of AX.25 frames B. Kantor May 1991 ASCII 2573 2 IP-AX.25

This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1226
RFC1227 SNMP MUX protocol and MIB M.T. Rose May 1991 ASCII 25868 13 SNMP-MUX

This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB. This mechanism would be local to the host.This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

HISTORIC HISTORIC Legacy http://www.rfc-editor.org/errata_search.php?rfc=1227 10.17487/RFC1227
RFC1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface G. Carpenter B. Wijnen May 1991 ASCII 96972 50

This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1592 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1228
RFC1229 Extensions to the generic-interface MIB K. McCloghrie May 1991 ASCII 36022 16

This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS-TRACK]

RFC1573 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1229
RFC1230 IEEE 802.4 Token Bus MIB K. McCloghrie R. Fox May 1991 ASCII 53100 23 802.4-MIP

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK]

RFC1239 HISTORIC HISTORIC IETF snmp 10.17487/RFC1230
RFC1231 IEEE 802.5 Token Ring MIB K. McCloghrie R. Fox E. Decker May 1991 ASCII 53542 23

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

RFC1743 RFC1748 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1231
RFC1232 Definitions of managed objects for the DS1 Interface type F. Baker C.P. Kolb May 1991 ASCII 60757 28 RFC1406 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1232 RFC1233 Definitions of managed objects for the DS3 Interface type T.A. Cox K. Tesink May 1991 ASCII 49559 23

This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]

RFC1407 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1233
RFC1234 Tunneling IPX traffic through IP networks D. Provan June 1991 ASCII 12333 6 IPX-IP

This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1234
RFC1235 Coherent File Distribution Protocol J. Ioannidis G. Maguire June 1991 ASCII 29345 12 CFDP

This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1235
RFC1236 IP to X.121 address mapping for DDN L. Morales P. Hasse June 1991 ASCII 12626 7 IP-X.121

This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1236
RFC1237 Guidelines for OSI NSAP Allocation in the Internet R. Colella E. Gardner R. Callon July 1991 ASCII 116989 48 PS 160478 PDF 171423

This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]

RFC1629 PROPOSED STANDARD PROPOSED STANDARD IETF osinsap 10.17487/RFC1237
RFC1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) G. Satz June 1991 ASCII 65159 32 CLNS-MIB

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1162 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1238
RFC1239 Reassignment of experimental MIBs to standard MIBs J.K. Reynolds June 1991 ASCII 3656 2 STD-MIBs

This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]

RFC1229 RFC1230 RFC1231 RFC1232 RFC1233 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1239
RFC1240 OSI connectionless transport services on top of UDP: Version 1 C. Shue W. Haggerty K. Dobbins June 1991 ASCII 18140 8 OSI-UDP

This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1240
RFC1241 Scheme for an internet encapsulation protocol: Version 1 R.A. Woodburn D.L. Mills July 1991 ASCII 42468 17 PS 128921 PDF 44593 IN-ENCAP

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1241
RFC1242 Benchmarking Terminology for Network Interconnection Devices S. Bradner July 1991 ASCII 22817 12

This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6201 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC1242
RFC1243 AppleTalk Management Information Base S. Waldbusser July 1991 ASCII 61985 29

This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]

RFC1742 PROPOSED STANDARD PROPOSED STANDARD IETF int appleip 10.17487/RFC1243
RFC1244 Site Security Handbook J.P. Holbrook J.K. Reynolds July 1991 ASCII 259129 101

This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8]

RFC2196 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1244
RFC1245 OSPF Protocol Analysis J. Moy July 1991 ASCII 26160 12 PS 33546 PDF 31723 OSPF SPF routing TOS LSA flooding

This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet. This memo provides information for the Internet community. It does not specify any Internet standard.

RFC1246 RFC1247 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1245
RFC1246 Experience with the OSPF Protocol J. Moy July 1991 ASCII 70441 31 PS 141924 PDF 84633 OSPF SPF routing MIB experience testing

This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. This memo provides information for the Internet community. It does not specify any Internet standard.

RFC1245 RFC1247 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1246
RFC1247 OSPF Version 2 J. Moy July 1991 ASCII 433332 189 PS 989724 PDF 490300 equal-cost multipath link state LSA

This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK]

RFC1131 RFC1583 RFC1349 RFC1245 RFC1246 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC1247
RFC1248 OSPF Version 2 Management Information Base F. Baker R. Coltun July 1991 ASCII 74347 42 OSPF SPF MIB routing network management

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]

RFC1252 RFC1349 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1248
RFC1249 DIXIE Protocol Specification T. Howes M. Smith B. Beecher August 1991 ASCII 20028 10 DIXIE DIXIE protocol directory services X.500 DAP

This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. This memo provides information for the Internet community. It does not specify any standard.

RFC1202 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1249
RFC1250 IAB Official Protocol Standards J. Postel August 1991 ASCII 62555 28 standards protocol IAB

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1200 RFC2200 RFC1280 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1250
RFC1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members G. Malkin August 1991 ASCII 70383 26 IESG IRSG IAB

This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9]

RFC1336 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1251
RFC1252 OSPF Version 2 Management Information Base F. Baker R. Coltun August 1991 ASCII 74471 42 OSPF SPF MIB routing network management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]

RFC1248 RFC1253 RFC1245 RFC1247 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1252
RFC1253 OSPF Version 2 Management Information Base F. Baker R. Coltun August 1991 ASCII 74453 42

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]

RFC1252 RFC1850 RFC1245 RFC1246 RFC1247 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1253
RFC1254 Gateway Congestion Control Survey A. Mankin K. Ramakrishnan August 1991 ASCII 67609 25 gateway congestion SQ source quench fiar queueing random drop

The purpose of this paper is to present a review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing.

INFORMATIONAL INFORMATIONAL IETF int pcc 10.17487/RFC1254
RFC1255 A Naming Scheme for c=US The North American Directory Forum September 1991 ASCII 51103 25 naming NADF X.500 directory services c=us

This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1218 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1255
RFC1256 ICMP Router Discovery Messages S. Deering Editor September 1991 ASCII 43059 19 ICMP-ROUT ICMP router gateway discovery standard protocol

This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. [STANDARDS-TRACK]

RFC0792 PROPOSED STANDARD PROPOSED STANDARD IETF int rdisc 10.17487/RFC1256
RFC1257 Isochronous applications do not require jitter-controlled networks C. Partridge September 1991 ASCII 11075 5

This memo argues that jitter control is not required for networks to support isochronous applications. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1257
RFC1258 BSD Rlogin B. Kantor September 1991 ASCII 10763 5

The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1282 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1258 10.17487/RFC1258
RFC1259 Building the open road: The NREN as test-bed for the national public network M. Kapor September 1991 ASCII 61654 23 NREN test-bed network policy

This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1259
RFC1260 RFC1261 Transition of Nic Services S. Williamson L. Nobile September 1991 ASCII 4244 3 NIC transition

This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1261
RFC1262 Guidelines for Internet Measurement Activities V.G. Cerf October 1991 ASCII 6381 3

This RFC represents IAB guidance for researchers considering measurement experiments on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1262
RFC1263 TCP Extensions Considered Harmful S. O'Malley L.L. Peterson October 1991 ASCII 54078 19

This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve the Internet protocol suite. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1263
RFC1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria R.M. Hinden October 1991 ASCII 17016 8

This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard.

RFC4794 HISTORIC INFORMATIONAL IETF IESG 10.17487/RFC1264
RFC1265 BGP Protocol Analysis Y. Rekhter October 1991 ASCII 20728 8

This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1265
RFC1266 Experience with the BGP Protocol Y. Rekhter October 1991 ASCII 21938 9

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1266
RFC1267 Border Gateway Protocol 3 (BGP-3) K. Lougheed Y. Rekhter October 1991 ASCII 80724 35 BGP3

This memo, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1163 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1267
RFC1268 Application of the Border Gateway Protocol in the Internet Y. Rekhter P. Gross October 1991 ASCII 31102 13 BGP3

This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]

RFC1164 RFC1655 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1268
RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 S. Willis J.W. Burruss October 1991 ASCII 25717 13 BGP-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. [STANDARDS-TRACK]

RFC4273 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1269
RFC1270 SNMP Communications Services F. Kastenholz October 1991 ASCII 26167 11

This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1270
RFC1271 Remote Network Monitoring Management Information Base S. Waldbusser November 1991 ASCII 184111 81

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

RFC1757 RFC1513 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC1271
RFC1272 Internet Accounting: Background C. Mills D. Hirsh G.R. Ruth November 1991 ASCII 46562 19

This document provides background information for the "Internet Accounting Architecture". This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF acct 10.17487/RFC1272
RFC1273 Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations M.F. Schwartz November 1991 ASCII 19949 8

This memo describes plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1273
RFC1274 The COSINE and Internet X.500 Schema P. Barker S. Kille November 1991 ASCII 92827 60 Naming

This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. [STANDARDS-TRACK]

RFC4524 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1274
RFC1275 Replication Requirements to provide an Internet Directory using X.500 S.E. Hardcastle-Kille November 1991 ASCII 4616 3 PS 83736 PDF 73349

This RFC considers certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective open Internet Directory can be established using these protocols and services [CCI88]. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1275
RFC1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 S.E. Hardcastle-Kille November 1991 ASCII 33731 17 PS 217170

Some requirements on extensions to X.500 are described in the RFC[HK91b], in order to build an Internet Directory using X.500(1988). This document specifies a set of solutions to the problems raised. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1276
RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers S.E. Hardcastle-Kille November 1991 ASCII 22254 12 PS 176169 address ISO OSI

This document defines a new network address format, and rules for using some existing network address formats. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1277
RFC1278 A string encoding of Presentation Address S.E. Hardcastle-Kille November 1991 ASCII 10256 7 PS 128696 OSI ASN.1

There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1278
RFC1279 X.500 and Domains S.E. Hardcastle-Kille November 1991 ASCII 26669 15 PS 170029 PDF 142776 Domain Name naming

This RFC considers X.500 in relation to Internet and UK Domains. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL IETF app osids 10.17487/RFC1279
RFC1280 IAB Official Protocol Standards J. Postel March 1992 ASCII 70458 32

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1250 RFC1360 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1280
RFC1281 Guidelines for the Secure Operation of the Internet R. Pethia S. Crocker B. Fraser November 1991 ASCII 22618 10 security privacy protection guideline

The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF sec spwg 10.17487/RFC1281
RFC1282 BSD Rlogin B. Kantor December 1991 ASCII 10704 5 BSD Login Unix remote-login remote-logon

This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1258 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1282
RFC1283 SNMP over OSI M. Rose December 1991 ASCII 16857 8 ISO Management MIB

This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard.

RFC1418 EXPERIMENTAL EXPERIMENTAL IETF snmp 10.17487/RFC1283
RFC1284 Definitions of Managed Objects for the Ethernet-like Interface Types J. Cook Editor December 1991 ASCII 43225 21 SNMP MIB Management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC1398 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1284
RFC1285 FDDI Management Information Base J. Case January 1992 ASCII 99747 46 FDDI-MIB standard standards MIB SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI. [STANDARDS-TRACK]

RFC1512 HISTORIC PROPOSED STANDARD IETF fddimib 10.17487/RFC1285
RFC1286 Definitions of Managed Objects for Bridges E. Decker P. Langille A. Rijsinghani K. McCloghrie December 1991 ASCII 79104 40 SNMP MIB standard standards

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK]

RFC1493 RFC1525 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC1286
RFC1287 Towards the Future Internet Architecture D. Clark L. Chapin V. Cerf R. Braden R. Hobby December 1991 ASCII 59812 29

This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1287
RFC1288 The Finger User Information Protocol D. Zimmerman December 1991 ASCII 25161 12 FINGER

This memo describes the Finger user information protocol.This is a simple protocol which provides an interface to a remote user information program. [STANDARDS-TRACK]

RFC1196 RFC1194 RFC0742 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1288
RFC1289 DECnet Phase IV MIB Extensions J. Saperia December 1991 ASCII 122272 64 SNMP Management protocol standard standards

This memo is an extension to the SNMP MIB. This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. [STANDARDS-TRACK]

RFC1559 PROPOSED STANDARD PROPOSED STANDARD IETF decnetiv 10.17487/RFC1289
RFC1290 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places J. Martin December 1991 ASCII 46997 27 SIGUCCS User Services Help Internet

This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users. This RFC provides information for the Internet community. It does not specify an Internet standard.

RFC1402 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1290
RFC1291 Mid-Level Networks Potential Technical Services V. Aggarwal December 1991 ASCII 24314 10 PS 218918 statistics connectivity management

This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. This RFC provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1291
RFC1292 A Catalog of Available X.500 Implementations R. Lang R. Wright January 1992 ASCII 129468 103

The goal of this document is to provide information regarding the availability and capability of implementations of X.500. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1632 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1292
RFC1293 Inverse Address Resolution Protocol T. Bradley C. Brown January 1992 ASCII 11368 6 standard standards ARP DLCI

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

RFC2390 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1293
RFC1294 Multiprotocol Interconnect over Frame Relay T. Bradley C. Brown A. Malis January 1992 ASCII 54992 28 standard standards

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]

RFC1490 RFC2427 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1294
RFC1295 User Bill of Rights for entries and listings in the Public Directory The North American Directory Forum January 1992 ASCII 3502 2 NADF-265 NADF X.500

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 and RFC1407. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1295
RFC1296 Internet Growth (1981-1991) M. Lottor January 1992 ASCII 20103 9 statistics ZONE

This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1296
RFC1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS") D. Johnson January 1992 ASCII 32964 12 problems tracking operations NOC

This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF ucp 10.17487/RFC1297
RFC1298 SNMP over IPX R. Wormley S. Bostock February 1992 ASCII 7878 5

This memo defines a convention for encapsulating Simple Network Management Protocol (SNMP) packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1420 INFORMATIONAL INFORMATIONAL IETF snmp 10.17487/RFC1298
RFC1299 Summary of 1200-1299 M. Kennedy January 1997 ASCII 36594 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1299 RFC1300 Remembrances of Things Past S. Greenfield February 1992 ASCII 4963 4 poem

Poem. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1300
RFC1301 Multicast Transport Protocol S. Armstrong A. Freier K. Marzullo February 1992 ASCII 91976 38 MTP MTP reliable transport multicast broadcast collaboration networking

This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1301
RFC1302 Building a Network Information Services Infrastructure D. Sitzler P. Smith A. Marine February 1992 ASCII 29135 13 NISI NIC User Services

This FYI RFC document is intended for existing Internet Network Information Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0012 INFORMATIONAL INFORMATIONAL IETF nisi 10.17487/RFC1302
RFC1303 A Convention for Describing SNMP-based Agents K. McCloghrie M. Rose February 1992 ASCII 22915 12 SNMP MIB Network Management,

This memo suggests a straight-forward approach towards describing SNMP- based agents. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1155 RFC1157 RFC1212 RFC1213 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1303
RFC1304 Definitions of Managed Objects for the SIP Interface Type T. Cox K. Tesink Editors February 1992 ASCII 52491 25 Standard MIB Network Management SMDS

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing SIP (SMDS Interface Protocol) objects. [STANDARDS-TRACK]

RFC1694 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1304
RFC1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis D. Mills March 1992 ASCII 307085 109 PDF 442493 NTPV3 NTP

This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]

RFC0958 RFC1059 RFC1119 RFC5905 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1305
RFC1306 Experiences Supporting By-Request Circuit-Switched T3 Networks A. Nicholson J. Young March 1992 ASCII 25788 10 WAN Wide Area Net FDDI

This memo describes the experiences of a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. This RFC provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1306
RFC1307 Dynamically Switched Link Control Protocol J. Young A. Nicholson March 1992 ASCII 24145 13 DSLCP Experimental Protocol T3 FDDI

This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1307
RFC1308 Executive Introduction to Directory Services Using the X.500 Protocol C. Weider J. Reynolds March 1992 ASCII 9392 4

This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0013 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1308
RFC1309 Technical Overview of Directory Services Using the X.500 Protocol C. Weider J. Reynolds S. Heker March 1992 ASCII 35694 16

This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts Directory Services based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0014 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1309
RFC1310 The Internet Standards Process L. Chapin March 1992 ASCII 54738 23

This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]

RFC1602 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1310
RFC1311 Introduction to the STD Notes J. Postel March 1992 ASCII 11308 5 new IAB

The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS-TRACK]

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1311
RFC1312 Message Send Protocol 2 R. Nelson G. Arnold April 1992 ASCII 18037 8 MSP2 MSP talk

The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community.

RFC1159 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1312
RFC1313 Today's Programming for KRFC AM 1313 Internet Talk Radio C. Partridge April 1 1992 ASCII 5444 3

Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1313
RFC1314 A File Format for the Exchange of Images in the Internet A. Katz D. Cohen April 1992 ASCII 54072 23 NETFAX netfax TIFF facsimile

This document defines a standard file format for the exchange of fax- like black and white images within the Internet. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app netfax 10.17487/RFC1314
RFC1315 Management Information Base for Frame Relay DTEs C. Brown F. Baker C. Carvalho April 1992 ASCII 33825 19 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Frame Relay. [STANDARDS-TRACK]

RFC2115 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1315
RFC1316 Definitions of Managed Objects for Character Stream Devices B. Stewart April 1992 ASCII 35143 17 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for the management of character stream devices. [STANDARDS-TRACK]

RFC1658 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1316
RFC1317 Definitions of Managed Objects for RS-232-like Hardware Devices B. Stewart April 1992 ASCII 30442 17 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]

RFC1659 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1317
RFC1318 Definitions of Managed Objects for Parallel-printer-like Hardware Devices B. Stewart April 1992 ASCII 19570 11 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of parallel-printer- like devices. [STANDARDS-TRACK]

RFC1660 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1318
RFC1319 The MD2 Message-Digest Algorithm B. Kaliski April 1992 ASCII 25661 17 security encryption signature

This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6149 HISTORIC INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1319 10.17487/RFC1319
RFC1320 The MD4 Message-Digest Algorithm R. Rivest April 1992 ASCII 32407 20 MD4 security encryption signature

This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1186 RFC6150 HISTORIC INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1320 10.17487/RFC1320
RFC1321 The MD5 Message-Digest Algorithm R. Rivest April 1992 ASCII 35222 21 security signature eneryption

This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6151 INFORMATIONAL INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1321 10.17487/RFC1321
RFC1322 A Unified Approach to Inter-Domain Routing D. Estrin Y. Rekhter S. Hotz May 1992 ASCII 96934 38 path vector routing source demand routing

This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF rtg bgp http://www.rfc-editor.org/errata_search.php?rfc=1322 10.17487/RFC1322
RFC1323 TCP Extensions for High Performance V. Jacobson R. Braden D. Borman May 1992 ASCII 84558 37 TCP-EXT options PAWS window scale window

This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. [STANDARDS-TRACK]

RFC1072 RFC1185 RFC7323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcplw http://www.rfc-editor.org/errata_search.php?rfc=1323 10.17487/RFC1323
RFC1324 A Discussion on Computer Network Conferencing D. Reed May 1992 ASCII 24988 11 talk real time chat

This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1324
RFC1325 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions G. Malkin A. Marine May 1992 ASCII 91884 42 documentation help information

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1206 RFC1594 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1325
RFC1326 Mutual Encapsulation Considered Dangerous P. Tsuchiya May 1992 ASCII 11277 5 protocol layering wrapping

This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1326
RFC1327 Mapping between X.400(1988) / ISO 10021 and RFC 822 S. Hardcastle-Kille May 1992 ASCII 228598 113 Electronic-mail,Message handling systems

This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK]

RFC0987 RFC1026 RFC1138 RFC1148 RFC2156 RFC0822 RFC1495 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1327
RFC1328 X.400 1988 to 1984 downgrading S. Hardcastle-Kille May 1992 ASCII 10006 5 Electronic-mail message handling systems,mail

This document considers issues of downgrading from X.400(1988) to X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1328
RFC1329 Thoughts on Address Resolution for Dual MAC FDDI Networks P. Kuehn May 1992 ASCII 58150 28

In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC5494 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1329
RFC1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community ESCC X.500/X.400 Task Force ESnet Site Coordinating Comittee (ESCC) Energy Sciences Network (ESnet) May 1992 ASCII 192925 87

This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1330
RFC1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links W. Simpson May 1992 ASCII 129892 69 serial line IP over serial dial-up

This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

RFC1171 RFC1172 RFC1548 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1331
RFC1332 The PPP Internet Protocol Control Protocol (IPCP) G. McGregor May 1992 ASCII 17613 14 PPP-IPCP serial line IP over serial dial-up

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. [STANDARDS-TRACK]

RFC1172 RFC3241 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1332
RFC1333 PPP Link Quality Monitoring W. Simpson May 1992 ASCII 29965 17 serial line IP over serial dial-up

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. [STANDARDS-TRACK]

RFC1989 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1333
RFC1334 PPP Authentication Protocols B. Lloyd W. Simpson October 1992 ASCII 33248 16 point serial line dial-up

This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol. [STANDARDS-TRACK]

RFC1994 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1334
RFC1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion Z. Wang J. Crowcroft May 1992 ASCII 15418 7 internet protocol IP

This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an "idea" paper and discussion is strongly encouraged. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1335
RFC1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members G. Malkin May 1992 ASCII 92119 33 Almquist Braden Braun Callon Cerf Chiappa Chapin Clark Crocker Davin Estrin Hobby Huitema Huizer Kent Lauck Leiner Lynch Piscitello Postel Reynolds Schwartz Stockman Vaudreuil

This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify any standard.

RFC1251 FYI0009 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1336
RFC1337 TIME-WAIT Assassination Hazards in TCP R. Braden May 1992 ASCII 22887 11 TCP protocol protocol state graceful close reset

This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1337
RFC1338 Supernetting: an Address Assignment and Aggregation Strategy V. Fuller T. Li J. Yu K. Varadhan June 1992 ASCII 47975 20 internet address routing

This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1519 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1338
RFC1339 Remote Mail Checking Protocol S. Dorner P. Resnick June 1992 ASCII 13115 6 RMCP email remote mail

This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1339
RFC1340 Assigned Numbers J. Reynolds J. Postel July 1992 ASCII 232974 139

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

RFC1060 RFC1700 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1340 10.17487/RFC1340
RFC1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies N. Borenstein N. Freed June 1992 ASCII 211117 80 PS 347082 PDF 192244 EMail Multimedia

This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK]

RFC1521 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1341
RFC1342 Representation of Non-ASCII Text in Internet Message Headers K. Moore June 1992 ASCII 15845 7 EMail Character Sets

This memo describes an extension to the message format defined in [1] (known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC 822 message headers. [STANDARDS-TRACK]

RFC1522 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1342
RFC1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information N. Borenstein June 1992 ASCII 29295 10 PS 59978 PDF 28495 EMail Multimedia

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1343
RFC1344 Implications of MIME for Internet Mail Gateways N. Borenstein June 1992 ASCII 25872 9 PS 51812 PDF 24430 EMail Forwarding Relaying Fragmentation Multimedia

While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1344
RFC1345 Character Mnemonics and Character Sets K. Simonsen June 1992 ASCII 249737 103

This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=1345 10.17487/RFC1345
RFC1346 Resource Allocation, Control, and Accounting for the Use of Network Resources P. Jones June 1992 ASCII 13084 6

The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1346
RFC1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing R. Callon June 1992 ASCII 26563 8 PS 42398 PDF 22398

This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1347
RFC1348 DNS NSAP RRs B. Manning July 1992 ASCII 6871 4 domain names CLNP resource records

This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community.

RFC1637 RFC1034 RFC1035 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1348
RFC1349 Type of Service in the Internet Protocol Suite P. Almquist July 1992 ASCII 68949 28 TOS TOS IP

This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]

RFC2474 RFC1248 RFC1247 RFC1195 RFC1123 RFC1122 RFC1060 RFC0791 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq 10.17487/RFC1349
RFC1350 The TFTP Protocol (Revision 2) K. Sollins July 1992 ASCII 24599 11 TFTP trivial file transfer booting

TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK]

RFC0783 RFC1782 RFC1783 RFC1784 RFC1785 RFC2347 RFC2348 RFC2349 STD0033 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1350 10.17487/RFC1350
RFC1351 SNMP Administrative Model J. Davin J. Galvin K. McCloghrie July 1992 ASCII 80721 35 SNMP-ADMIN network management authentication

This memo presents an elaboration of the SNMP administrative model set forth in [1]. This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1351
RFC1352 SNMP Security Protocols J. Galvin K. McCloghrie J. Davin July 1992 ASCII 95732 41 SNMP-SEC network management authentication

The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1352
RFC1353 Definitions of Managed Objects for Administration of SNMP Parties K. McCloghrie J. Davin J. Galvin July 1992 ASCII 59556 26 SNMP-PARTY-MIB network management authentication

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet Standard SMI [1]. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1353
RFC1354 IP Forwarding Table MIB F. Baker July 1992 ASCII 24905 12 Network Management Route Table

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing routes in the IP Internet. [STANDARDS-TRACK]

RFC2096 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq 10.17487/RFC1354
RFC1355 Privacy and Accuracy Issues in Network Information Center Databases J. Curran A. Marine August 1992 ASCII 8858 4 NIC data privacy accuracy

This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0015 INFORMATIONAL INFORMATIONAL IETF nisi 10.17487/RFC1355
RFC1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode A. Malis D. Robinson R. Ullmann August 1992 ASCII 32043 14 IP-X.25 IP on X.25

This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment with ISO/IEC and CCITT standards. It is a replacement for RFC 877, "A Standard for the Transmission of IP Datagrams Over Public Data Networks" [1]. [STANDARDS-TRACK]

RFC0877 DRAFT STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1356
RFC1357 A Format for E-mailing Bibliographic Records D. Cohen July 1992 ASCII 25021 13 library technical reports email services

This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1807 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1357
RFC1358 Charter of the Internet Architecture Board (IAB) L. Chapin August 1992 ASCII 11328 5 ISOC Internet Society IETF IRTF

The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1601 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1358
RFC1359 Connecting to the Internet - What Connecting Institutions Should Anticipate ACM SIGUCCS August 1992 ASCII 53449 25 Internet access

This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0016 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1359
RFC1360 IAB Official Protocol Standards J. Postel September 1992 ASCII 71860 33 proposed draft experimental informational historic full RFC1280 RFC1410 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1360 RFC1361 Simple Network Time Protocol (SNTP) D. Mills August 1992 ASCII 23812 10 Clocks Synchronization NTP

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memorandum does not obsolete or update any RFC. This memo provides information for the Internet community. It does not specify an Internet standard. Discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.9 contain the lists of protocols in each stage of standardization. Finally come pointers to references and contacts for further information. [STANDARDS-TRACK]

RFC1769 RFC1305 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1361 10.17487/RFC1361
RFC1362 Novell IPX over Various WAN Media (IPXWAN) M. Allen September 1992 ASCII 30219 13 IPX on X.25 IPX on PPP IPX on Frame Relay

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1634 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1362
RFC1363 A Proposed Flow Specification C. Partridge September 1992 ASCII 59214 20 flow spec resource reservation stream type of service quality of service INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1363 RFC1364 BGP OSPF Interaction K. Varadhan September 1992 ASCII 32121 14 autonomous system border router open shortest path first routing protocol domain route exchange exporting importing RFC1403 RFC1247 RFC1267 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1364 RFC1365 An IP Address Extension Proposal K. Siyan September 1992 ASCII 12790 6 class F addresses INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1365 10.17487/RFC1365 RFC1366 Guidelines for Management of IP Address Space E. Gerich October 1992 ASCII 17793 8 routing tables allocation registry IR IANA

This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] 1363 Partridge Spt 92 A Proposed Flow Specification The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only). This RFC is a product of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1466 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1366
RFC1367 Schedule for IP Address Space Management Guidelines C. Topolcic October 1992 ASCII 4780 3 routing tables allocation registry IR IANA

This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1467 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1367
RFC1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices D. McMaster K. McCloghrie October 1992 ASCII 83905 40 MIB hub management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs". [STANDARDS-TRACK]

RFC1516 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC1368
RFC1369 Implementation Notes and Experience for the Internet Ethernet MIB F. Kastenholz October 1992 ASCII 13961 7 management

This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL PROPOSED STANDARD IETF ethermib 10.17487/RFC1369
RFC1370 Applicability Statement for OSPF Internet Architecture Board L. Chapin October 1992 ASCII 4303 2 routing open shortest path first

This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1370
RFC1371 Choosing a Common IGP for the IP Internet P. Gross October 1992 ASCII 18168 9 routing recommendation interior gateway protocol

This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to the IAB for a single "common IGP" for the IP portions of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1371
RFC1372 Telnet Remote Flow Control Option C. Hedrick D. Borman October 1992 ASCII 11098 6 TOPT-RFC terminal access

This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]

RFC1080 PROPOSED STANDARD PROPOSED STANDARD IETF app telnet 10.17487/RFC1372
RFC1373 Portable DUAs T. Tignor October 1992 ASCII 19931 12 directory user agents whois de dixie ud doog ISODE X.500

This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1373
RFC1374 IP and ARP on HIPPI J. Renwick A. Nicholson October 1992 ASCII 100903 43

The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks. This memo is intended to become an Internet Standard. [STANDARDS-TRACK]

RFC2834 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1374
RFC1375 Suggestion for New Classes of IP Addresses P. Robinson October 1992 ASCII 16990 7 network numbers

This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1375
RFC1376 The PPP DECnet Phase IV Control Protocol (DNCP) S. Senum November 1992 ASCII 12448 6 point DNA DDCMP

This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.). [STANDARDS-TRACK]

RFC1762 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1376
RFC1377 The PPP OSI Network Layer Control Protocol (OSINLCP) D. Katz November 1992 ASCII 22109 10 PPP-OSINLCP point open systems interconnection

This document defines the NCP for establishing and configuring OSI Network Layer Protocols. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1377
RFC1378 The PPP AppleTalk Control Protocol (ATCP) B. Parker November 1992 ASCII 28496 16 PPP-ATCP point

This document defines the NCP for establishing and configuring the AppleTalk Protocol [3] over PPP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1378
RFC1379 Extending TCP for Transactions -- Concepts R. Braden November 1992 ASCII 91353 38 transmission control protocol

This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6247 RFC1644 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1379
RFC1380 IESG Deliberations on Routing and Addressing P. Gross P. Almquist November 1992 ASCII 49415 22 ROAD

This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1380
RFC1381 SNMP MIB Extension for X.25 LAPB D. Throop F. Baker November 1992 ASCII 71253 33 SNMP-LAPB management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Link Layer of X.25, LAPB. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF x25mib 10.17487/RFC1381
RFC1382 SNMP MIB Extension for the X.25 Packet Layer D. Throop Editor November 1992 ASCII 153877 69 SNMP-X.25 management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF x25mib 10.17487/RFC1382
RFC1383 An Experiment in DNS Based IP Routing C. Huitema December 1992 ASCII 32680 14 DNS-IP

Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1383
RFC1384 Naming Guidelines for Directory Pilots P. Barker S.E. Hardcastle-Kille January 1993 ASCII 25870 12 PS 175044 PDF 134487 X.500 Multinational

This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1617 RTR0011 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1384
RFC1385 EIP: The Extended Internet Protocol Z. Wang November 1992 ASCII 39123 17 addressing

EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6814 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1385
RFC1386 The US Domain A. Cooper J. Postel December 1992 ASCII 62310 31 DNS top-level

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1480 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1386
RFC1387 RIP Version 2 Protocol Analysis G. Malkin January 1993 ASCII 5598 3 RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1721 INFORMATIONAL INFORMATIONAL IETF rtg ripv2 10.17487/RFC1387
RFC1388 RIP Version 2 Carrying Additional Information G. Malkin January 1993 ASCII 16227 7 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP), as defined in [STANDARDS-TRACK]

RFC1723 RFC1058 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC1388
RFC1389 RIP Version 2 MIB Extensions G. Malkin F. Baker January 1993 ASCII 23569 13 RIP-2 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

RFC1724 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC1389
RFC1390 Transmission of IP and ARP over FDDI Networks D. Katz January 1993 ASCII 22077 11 IP-FDDI IEEE 802 MAC

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

STD0036 INTERNET STANDARD INTERNET STANDARD IETF int fddi 10.17487/RFC1390
RFC1391 The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force G. Malkin January 1993 ASCII 41892 19 meetings

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1539 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1391
RFC1392 Internet Users' Glossary G. Malkin T. LaQuey Parker January 1993 ASCII 104624 53

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1983 INFORMATIONAL INFORMATIONAL IETF userglos 10.17487/RFC1392
RFC1393 Traceroute Using an IP Option G. Malkin January 1993 ASCII 13140 7 TRACE-IP ICMP MTU Line Speed

This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time. This memo defines an Experimental Protocol for the Internet community.

RFC6814 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1393
RFC1394 Relationship of Telex Answerback Codes to Internet Domains P. Robinson January 1993 ASCII 43776 15 DNS Country

This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available. It will also list major Internet "Public" E-Mail addresses. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1394
RFC1395 BOOTP Vendor Information Extensions J. Reynolds January 1993 ASCII 16314 8 TAGS

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).

RFC1084 RFC1048 RFC1497 RFC1533 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1395
RFC1396 The Process for Organization of Internet Standards Working Group (POISED) S. Crocker January 1993 ASCII 22096 10 IAB IESG ISOC

This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1396
RFC1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol D. Haskin January 1993 ASCII 4124 2 BGP

This document speficies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg idr 10.17487/RFC1397
RFC1398 Definitions of Managed Objects for the Ethernet-Like Interface Types F. Kastenholz January 1993 ASCII 36684 17 MIB Management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ehternet-like objects. [STANDARDS-TRACK]

RFC1284 RFC1623 DRAFT STANDARD DRAFT STANDARD IETF ethermib 10.17487/RFC1398
RFC1399 Summary of 1300-1399 J. Elliott January 1997 ASCII 43662 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1399 RFC1400 Transition and Modernization of the Internet Registration Service S. Williamson March 1993 ASCII 13008 7 INTERNIC IR

As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1400
RFC1401 Correspondence between the IAB and DISA on the use of DNS Internet Architecture Board January 1993 ASCII 12528 8 Domain Name Milnet

This memo reproduces three letters exchanged between the Internet Activities Board (IAB) and the Defense Information Systems Agency (DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt". This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1401
RFC1402 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places J. Martin January 1993 ASCII 71176 39 information introduction SIGUCCS User Services Help

The ultimate goal is to make the route to these sources of information invisible to you. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer. This RFC provides information for the Internet community. It does not specify an Internet standard.

RFC1290 FYI0010 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1402
RFC1403 BGP OSPF Interaction K. Varadhan January 1993 ASCII 36173 17 BGP-OSPF border gateway protocol open shortest path first routing

This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]

RFC1364 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1403
RFC1404 A Model for Common Operational Statistics B. Stockman January 1993 ASCII 52814 27 Management Operations

This memo describes a model for operational statistics in the Internet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1857 INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1404
RFC1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) C. Allocchio January 1993 ASCII 33885 19 SMTP EMail 822

This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 ) Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol. This memo defines an Experimental Protocol for the Internet community.

RFC2162 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1405
RFC1406 Definitions of Managed Objects for the DS1 and E1 Interface Types F. Baker J. Watt Editors January 1993 ASCII 97559 50 DS1/E1-MIB T1 MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. [STANDARDS-TRACK]

RFC1232 RFC2495 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC1406
RFC1407 Definitions of Managed Objects for the DS3/E3 Interface Type T. Cox K. Tesink January 1993 ASCII 90682 43 DS3/E3-MIB T3 MIB Management SNMP

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3 Interfaces. [STANDARDS-TRACK]

RFC1233 RFC2496 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC1407
RFC1408 Telnet Environment Option D. Borman Editor January 1993 ASCII 13936 7 TOPT-ENVIR Negotiation

This document specifies a mechanism for passing environment information between a telnet client and server. [STANDARDS-TRACK]

RFC1571 HISTORIC HISTORIC IETF app telnet 10.17487/RFC1408
RFC1409 Telnet Authentication Option D. Borman Editor January 1993 ASCII 13119 7 security

This memo defines an Experimental Protocol for the Internet community.

RFC1416 EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1409
RFC1410 IAB Official Protocol Standards J. Postel Editor March 1993 ASCII 76524 35 proposed draft experimental informational historic full

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).

RFC1360 RFC1500 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1410
RFC1411 Telnet Authentication: Kerberos Version 4 D. Borman Editor January 1993 ASCII 7967 4 TEL-KER Security option

This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1411
RFC1412 Telnet Authentication: SPX K. Alagappan January 1993 ASCII 6952 4 TEL-SPX Security option

This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1412
RFC1413 Identification Protocol M. St. Johns February 1993 ASCII 16291 8 IDENT Authentication

The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK]

RFC0931 PROPOSED STANDARD PROPOSED STANDARD IETF sec ident http://www.rfc-editor.org/errata_search.php?rfc=1413 10.17487/RFC1413
RFC1414 Identification MIB M. St. Johns M. Rose February 1993 ASCII 14165 7 IDENT-MIB Management SNMP

This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1]. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec ident 10.17487/RFC1414
RFC1415 FTP-FTAM Gateway Specification J. Mindel R. Slaski January 1993 ASCII 128261 58 FTP FTAM transfer ISO OSI

This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1415
RFC1416 Telnet Authentication Option D. Borman Editor February 1993 ASCII 13270 7 TOPT-AUTH Security

This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community.

RFC1409 RFC2941 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1416
RFC1417 NADF Standing Documents: A Brief Overview The North American Directory Forum February 1993 ASCII 7270 4 X.500 Directory

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1295 RFC1255 RFC1218 RFC1758 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1417
RFC1418 SNMP over OSI M. Rose March 1993 ASCII 7721 4 SNMP-OSI Management

This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK]

RFC1161 RFC1283 HISTORIC PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1418
RFC1419 SNMP over AppleTalk G. Minshall M. Ritter March 1993 ASCII 16470 7 SNMP-AT Management

This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1419
RFC1420 SNMP over IPX S. Bostock March 1993 ASCII 6762 4 SNMP-IPX Management

This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. [STANDARDS-TRACK]

RFC1298 PROPOSED STANDARD PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1420
RFC1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures J. Linn February 1993 ASCII 103894 42 PEM-ENC PEM

This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK]

RFC1113 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1421
RFC1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management S. Kent February 1993 ASCII 86085 32 PEM-CKM PEM

This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]

RFC1114 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1422
RFC1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers D. Balenson February 1993 ASCII 33277 14 PEM-ALG PEM

This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. [STANDARDS-TRACK]

RFC1115 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1423
RFC1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services B. Kaliski February 1993 ASCII 17537 9 PEM-KEY PEM

This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1424
RFC1425 SMTP Service Extensions J. Klensin WG Chair N. Freed Editor M. Rose E. Stefferud D. Crocker February 1993 ASCII 20932 10 Mail

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

RFC1651 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1425
RFC1426 SMTP Service Extension for 8bit-MIMEtransport J. Klensin WG Chair N. Freed Editor M. Rose E. Stefferud D. Crocker February 1993 ASCII 11661 6 Mail

This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex

RFC1652 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1426
RFC1427 SMTP Service Extension for Message Size Declaration J. Klensin WG Chair N. Freed Editor K. Moore February 1993 ASCII 17856 8 Mail

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

RFC1653 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1427
RFC1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME G. Vaudreuil February 1993 ASCII 12064 6 Mail

This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME. This RFC provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app smtpext 10.17487/RFC1428
RFC1429 Listserv Distribute Protocol E. Thomas February 1993 ASCII 17759 8 LISTSERV Mail

This memo specifies a subset of the distribution protocol used by the BITNET LISTSERV to deliver mail messages to large amounts of recipients. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1429
RFC1430 A Strategic Plan for Deploying an Internet X.500 Directory Service S. Hardcastle-Kille E. Huizer V. Cerf R. Hobby S. Kent February 1993 ASCII 47587 20 X.500

This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1430
RFC1431 DUA Metrics (OSI-DS 33 (v2)) P. Barker February 1993 ASCII 42240 19 Directory User Agent Measurement Statistics Survey X.500

This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1431
RFC1432 Recent Internet Books J. Quarterman March 1993 ASCII 27089 15 bibiography

Here is a list of books related to using the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1432
RFC1433 Directed ARP J. Garrett J. Hagan J. Wong March 1993 ASCII 41028 18 DIR-ARP public networks SMDS

Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF int iplpdn 10.17487/RFC1433
RFC1434 Data Link Switching: Switch-to-Switch Protocol R. Dixon D. Kushi March 1993 ASCII 80182 33 PS 292006 PDF 181839 IBM SNA DLS SSP NetBIos

This RFC describes IBM's support of Data Link Switching over TCP/IP. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1795 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1434
RFC1435 IESG Advice from Experience with Path MTU Discovery S. Knowles March 1993 ASCII 2708 2 Maximum Transmission Unit

In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1435
RFC1436 The Internet Gopher Protocol (a distributed document search and retrieval protocol) F. Anklesaria M. McCahill P. Lindner D. Johnson D. Torrey B. Albert March 1993 ASCII 36493 16 GOPHER information locating

This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1436
RFC1437 The Extension of MIME Content-Types to a New Medium N. Borenstein M. Linimon April 1 1993 ASCII 13356 6 life form Matter transport Sentient

This document defines one particular type of MIME data, the matter- transport/sentient-life-form type. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1437
RFC1438 Internet Engineering Task Force Statements Of Boredom (SOBs) A. Lyman Chapin C. Huitema April 1 1993 ASCII 3044 2 process policy

This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1438
RFC1439 The Uniqueness of Unique Identifiers C. Finseth March 1993 ASCII 20477 11 names

This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1439
RFC1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer R. Troth July 1993 ASCII 17366 9 SIFT UFT Send FTP

This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1440
RFC1441 Introduction to version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 25386 13 SNMPv2 SNMP Management Framework

The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF snmpv2 10.17487/RFC1441
RFC1442 Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 95779 56 SNMP Management Framework SMI

Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK]

RFC1902 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1442
RFC1443 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 60947 31 SNMP Management Framework

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

RFC1903 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1443
RFC1444 Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 57744 33 SNMP Management Framework

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

RFC1904 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1444
RFC1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2) J. Galvin K. McCloghrie April 1993 ASCII 99443 48 SNMP Management Framework

It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1445
RFC1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) J. Galvin K. McCloghrie April 1993 ASCII 108733 52 SNMP Management Framework

It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1446
RFC1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2) K. McCloghrie J. Galvin April 1993 ASCII 80762 50 SNMP Management Framework

The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1447
RFC1448 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 74224 36 SNMP Management Framework

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

RFC1905 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1448
RFC1449 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 41161 25 SNMP Management Framework

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

RFC1906 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1449
RFC1450 Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 42172 27 SNMP Management Framework

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

RFC1907 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1450
RFC1451 Manager-to-Manager Management Information Base J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 62935 36 SNMP Management Framework

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF snmpv2 10.17487/RFC1451
RFC1452 Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII 32176 17 SNMP Management Framework

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

RFC1908 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1452
RFC1453 A Comment on Packet Video Remote Conferencing and the Transport/Network Layers W. Chimiak April 1993 ASCII 23563 10 XTP

This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1453
RFC1454 Comparison of Proposals for Next Version of IP T. Dixon May 1993 ASCII 35064 15 IPng PIP TUBA SIP

This is a slightly edited reprint of RARE Technical Report (RTC(93)004). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1454
RFC1455 Physical Link Security Type of Service D. Eastlake 3rd May 1993 ASCII 12391 6 TOS-LS TOS

This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite. This memo defines an Experimental Protocol for the Internet community.

RFC2474 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1455
RFC1456 Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification Vietnamese Standardization Working Group May 1993 ASCII 14775 7 Character Set

This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into 7-bit US ASCII and in an 8-bit form. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1456
RFC1457 Security Label Framework for the Internet R. Housley May 1993 ASCII 35802 14

This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1457
RFC1458 Requirements for Multicast Protocols R. Braudes S. Zabele May 1993 ASCII 48106 19 Real-Time

This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1458
RFC1459 Internet Relay Chat Protocol J. Oikarinen D. Reed May 1993 ASCII 138964 65 IRCP IRC

The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. This memo defines an Experimental Protocol for the Internet community.

RFC2810 RFC2811 RFC2812 RFC2813 RFC7194 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1459 10.17487/RFC1459
RFC1460 Post Office Protocol - Version 3 M. Rose June 1993 ASCII 38827 17 Email

This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS-TRACK]

RFC1225 RFC1725 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1460
RFC1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 D. Throop May 1993 ASCII 47945 21 X25-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Multiprotocol Interconnect (including IP) traffic carried over X.25. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF x25mib 10.17487/RFC1461
RFC1462 FYI on "What is the Internet?" E. Krol E. Hoffman May 1993 ASCII 27811 11 Introduction

This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0020 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC1462
RFC1463 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings E. Hoffman L. Jackson May 1993 ASCII 7116 4

This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0019 INFORMATIONAL INFORMATIONAL IETF userdoc2 10.17487/RFC1463
RFC1464 Using the Domain Name System To Store Arbitrary String Attributes R. Rosenbaum May 1993 ASCII 7953 4 DNS TXT

This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1464
RFC1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing D. Eppenberger May 1993 ASCII 66833 31 X400

This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1465
RFC1466 Guidelines for Management of IP Address Space E. Gerich May 1993 ASCII 22262 10 CIDR

This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1366 RFC2050 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1466
RFC1467 Status of CIDR Deployment in the Internet C. Topolcic August 1993 ASCII 20720 9 routing tables allocation registry IR IANA classless

This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1367 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1467
RFC1468 Japanese Character Encoding for Internet Messages J. Murai M. Crispin E. van der Poel June 1993 ASCII 10970 6 Set

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app 822ext 10.17487/RFC1468
RFC1469 IP Multicast over Token-Ring Local Area Networks T. Pusateri June 1993 ASCII 8189 4 IP-TR-MC 802.2 802.5

This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1469
RFC1470 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices R. Enger J. Reynolds June 1993 ASCII 308528 192 NOCTOOLS

The goal of this FYI memo is to provide an update to FYI 2, RFC 1147 [1], which provided practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1147 FYI0002 INFORMATIONAL INFORMATIONAL IETF noctool2 10.17487/RFC1470
RFC1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII 53558 25 PPP/LCP MIB Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1471
RFC1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII 27152 13 PPP/SEC MIB Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1472
RFC1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII 20484 10 PPP/IP MIB Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1473
RFC1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII 31846 15 PPP/Bridge Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1474
RFC1475 TP/IX: The Next Internet R. Ullmann June 1993 ASCII 77854 35 TP-IX IPv7 IPng

This memo presents the specification for version 7 of the Internet Protocol, as well as version 7 of the TCP and the user datagram protocol. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC6814 HISTORIC EXPERIMENTAL IETF int tpix 10.17487/RFC1475
RFC1476 RAP: Internet Route Access Protocol R. Ullmann June 1993 ASCII 45560 20 RAP Routing

This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL IETF int tpix 10.17487/RFC1476
RFC1477 IDPR as a Proposed Standard M. Steenstrup July 1993 ASCII 32238 13 Routing Policy

This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1477
RFC1478 An Architecture for Inter-Domain Policy Routing M. Steenstrup June 1993 ASCII 90673 35 IDPR-ARCH IDPR

We present an architecture for inter-domain policy routing (IDPR). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1478
RFC1479 Inter-Domain Policy Routing Protocol Specification: Version 1 M. Steenstrup July 1993 ASCII 275823 108 IDPR IDPR

We present the set of protocols and procedures that constitute Inter- Domain Policy Routing (IDPR). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1479
RFC1480 The US Domain A. Cooper J. Postel June 1993 ASCII 100556 47 DNS top-level

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1386 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1480
RFC1481 IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling C. Huitema July 1993 ASCII 3502 2 CIDR

CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space. This memo provides information for the Internet community. It does not specify an Internet standard.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC1481
RFC1482 Aggregation Support in the NSFNET Policy-Based Routing Database M. Knopper S. Richardson June 1993 ASCII 25330 11 CIDR

This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network Service. This memo provides information for the Internet community. It does not specify an Internet standard.

HISTORIC INFORMATIONAL IETF bgpdepl 10.17487/RFC1482
RFC1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5 Juha Heinanen July 1993 ASCII 35192 16 ATM-ENCAP IP AAL5 over

This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK]

RFC2684 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1483
RFC1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)) S. Hardcastle-Kille July 1993 ASCII 48974 25 X.500 directory names representing names

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1781 RFC3494 HISTORIC EXPERIMENTAL IETF app osids 10.17487/RFC1484
RFC1485 A String Representation of Distinguished Names (OSI-DS 23 (v5)) S. Hardcastle-Kille July 1993 ASCII 11158 7 X.500 directory names representing names

When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. [STANDARDS-TRACK]

RFC1779 RFC3494 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1485
RFC1486 An Experiment in Remote Printing M. Rose C. Malamud July 1993 ASCII 26373 14 electronic mail facsimile

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1528 RFC1529 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1486
RFC1487 X.500 Lightweight Directory Access Protocol W. Yeong T. Howes S. Kille July 1993 ASCII 44947 21 X.500 DAP interactive access

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]

RFC1777 RFC3494 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1487
RFC1488 The X.500 String Representation of Standard Attribute Syntaxes T. Howes S. Kille W. Yeong C. Robbins July 1993 ASCII 17182 11 X.500 LDAP lightweight directory protocol

This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. [STANDARDS-TRACK]

RFC1778 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1488
RFC1489 Registration of a Cyrillic Character Set A. Chernov July 1993 ASCII 7798 5

Though the proposed character set "koi8-r" is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes "koi8-r" should be registered. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1489
RFC1490 Multiprotocol Interconnect over Frame Relay T. Bradley C. Brown A. Malis July 1993 ASCII 75206 35 standard standards IP over

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU. [STANDARDS-TRACK]

RFC1294 RFC2427 DRAFT STANDARD DRAFT STANDARD IETF int iplpdn 10.17487/RFC1490
RFC1491 A Survey of Advanced Usages of X.500 C. Weider R. Wright July 1993 ASCII 34883 18 directory

This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service. This RFC is a product of the Integrated Directory Services Working Group of the Application and User Services Areas of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0021 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1491
RFC1492 An Access Control Protocol, Sometimes Called TACACS C. Finseth July 1993 ASCII 41880 21 TACACS Terminal Server TAC

This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1492
RFC1493 Definitions of Managed Objects for Bridges E. Decker P. Langille A. Rijsinghani K. McCloghrie July 1993 ASCII 74493 34 BRIDGE-MIB SNMP MIB standard standards

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. [STANDARDS-TRACK]

RFC1286 RFC4188 DRAFT STANDARD DRAFT STANDARD IETF ops bridge 10.17487/RFC1493
RFC1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies H. Alvestrand S. Thompson August 1993 ASCII 37273 19 Equiv Mail

This document describes the content of the "IANA MHS/MIME Equivalence table", and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1494
RFC1495 Mapping between X.400 and RFC-822 Message Bodies H. Alvestrand S. Kille R. Miles M. Rose S. Thompson August 1993 ASCII 20071 11 Mail

Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]

RFC2156 RFC1327 PROPOSED STANDARD PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1495
RFC1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages H. Alvestrand J. Romaguera K. Jordan August 1993 ASCII 8411 5 HARPOON Mail

This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT obsoleted. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1496
RFC1497 BOOTP Vendor Information Extensions J. Reynolds August 1993 ASCII 16805 8 TAGS Boot

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).

RFC1395 RFC1084 RFC1048 RFC1533 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1497
RFC1498 On the Naming and Binding of Network Destinations J. Saltzer August 1993 ASCII 24698 10 NAMES Addresses Routes Objects Nodes Paths

This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas: First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1498
RFC1499 Summary of 1400-1499 J. Elliott January 1997 ASCII 40923 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1499 RFC1500 Internet Official Protocol Standards J. Postel August 1993 ASCII 79557 36 IAB

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

RFC1410 RFC1540 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1500
RFC1501 OS/2 User Group E. Brunsen August 1993 ASCII 3636 2

Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1501
RFC1502 X.400 Use of Extended Character Sets H. Alvestrand August 1993 ASCII 27976 14 Mail

This RFC defines a suggested method of using "GeneralText" in order to harmonize as much as possible the usage of this body part. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app x400ops 10.17487/RFC1502
RFC1503 Algorithms for Automating Administration in SNMPv2 Managers K. McCloghrie M. Rose August 1993 ASCII 33542 14 Management SNMP

When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1503
RFC1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing A. Oppenheimer August 1993 ASCII 201553 82 AVRP

This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1504
RFC1505 Encoding Header Field for Internet Messages A. Costanzo D. Robinson R. Ullmann August 1993 ASCII 63796 36 EHF-MAIL Mail

This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1154 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1505
RFC1506 A Tutorial on Gatewaying between X.400 and Internet Mail J. Houttuin August 1993 ASCII 85550 39 822 email RTR

This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1506
RFC1507 DASS - Distributed Authentication Security Service C. Kaufman September 1993 ASCII 287809 119 DASS CAT

The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL IETF sec cat 10.17487/RFC1507
RFC1508 Generic Security Service Application Program Interface J. Linn September 1993 ASCII 111228 49 CAT,GSS,API

This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]

RFC2078 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1508
RFC1509 Generic Security Service API : C-bindings J. Wray September 1993 ASCII 99608 48 GSSAPI CAT,GSS

This document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents. [STANDARDS-TRACK]

RFC2744 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1509
RFC1510 The Kerberos Network Authentication Service (V5) J. Kohl C. Neuman September 1993 ASCII 275395 112 KERBEROS CAT,Security

This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. [STANDARDS-TRACK]

RFC4120 RFC6649 HISTORIC PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=1510 10.17487/RFC1510
RFC1511 Common Authentication Technology Overview J. Linn September 1993 ASCII 4185 2 CAT,Security

This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1511
RFC1512 FDDI Management Information Base J. Case A. Rijsinghani September 1993 ASCII 108589 51 FDDI-MIB MIB SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard, which has been forwarded for publication by the X3T9.5 committee.

RFC1285 HISTORIC PROPOSED STANDARD IETF fddimib 10.17487/RFC1512
RFC1513 Token Ring Extensions to the Remote Network Monitoring MIB S. Waldbusser September 1993 ASCII 121974 55 Monitoring SNMP

This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. [STANDARDS-TRACK]

RFC1271 HISTORIC PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC1513
RFC1514 Host Resources MIB P. Grillo S. Waldbusser September 1993 ASCII 63775 33 HOST-MIB Management SNMP

This memo defines a MIB for use with managing host systems. [STANDARDS-TRACK]

RFC2790 PROPOSED STANDARD PROPOSED STANDARD IETF hostmib 10.17487/RFC1514
RFC1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) D. McMaster K. McCloghrie S. Roberts September 1993 ASCII 52828 25 MIB Management SNMP

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). [STANDARDS-TRACK]

RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC1515
RFC1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices D. McMaster K. McCloghrie September 1993 ASCII 82918 40 Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs." [STANDARDS-TRACK]

RFC1368 RFC2108 DRAFT STANDARD DRAFT STANDARD IETF ops hubmib 10.17487/RFC1516
RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) Internet Engineering Steering Group R. Hinden September 1993 ASCII 7357 4 CIDR Address

Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF IESG http://www.rfc-editor.org/errata_search.php?rfc=1517 10.17487/RFC1517
RFC1518 An Architecture for IP Address Allocation with CIDR Y. Rekhter T. Li September 1993 ASCII 72609 27 CIDR-ARCH Classless Routing

This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1518
RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy V. Fuller T. Li J. Yu K. Varadhan September 1993 ASCII 59998 24 CIDR-STRA]

This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK]

RFC1338 RFC4632 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1519 10.17487/RFC1519
RFC1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment Y. Rekhter C. Topolcic September 1993 ASCII 20389 9 Classless Routing

The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing. This memo provides information for the Internet community. It does not specify an Internet standard.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC1520
RFC1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies N. Borenstein N. Freed September 1993 ASCII 187424 81 PS 393670 PDF 205091 email multimedia

This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. [STANDARDS-TRACK]

RFC1341 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 RFC1590 DRAFT STANDARD DRAFT STANDARD IETF app 822ext 10.17487/RFC1521
RFC1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text K. Moore September 1993 ASCII 22502 10 email character

This memo describes an extension to the message format defined in RFC 1521, to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521.

RFC1342 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 DRAFT STANDARD DRAFT STANDARD IETF app 822ext 10.17487/RFC1522
RFC1523 The text/enriched MIME Content-type N. Borenstein September 1993 ASCII 32691 15 email mail richtext

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1563 RFC1896 INFORMATIONAL INFORMATIONAL IETF app 822ext 10.17487/RFC1523
RFC1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information N. Borenstein September 1993 ASCII 26464 12 MIME email mailcap

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1524 10.17487/RFC1524
RFC1525 Definitions of Managed Objects for Source Routing Bridges E. Decker K. McCloghrie P. Langille A. Rijsinghani September 1993 ASCII 38100 18 SRB-MIB MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK]

RFC1286 HISTORIC PROPOSED STANDARD IETF ops bridge 10.17487/RFC1525
RFC1526 Assignment of System Identifiers for TUBA/CLNP Hosts D. Piscitello September 1993 ASCII 16848 8 NSAP Address

This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF int tuba 10.17487/RFC1526
RFC1527 What Should We Plan Given the Dilemma of the Network? G. Cook September 1993 ASCII 46935 17

The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow for Congress to make? This memo is a shortened version of the suggested policy draft. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1527
RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures C. Malamud M. Rose October 1993 ASCII 18576 12 REM-PRINT FAX Facsimile

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1486 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1528
RFC1529 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies C. Malamud M. Rose October 1993 ASCII 11142 5 FAX Facsimile

This document defines the administrative policies for the operation of remote printer facilities within the context of the tpc.int subdomain. The document describes different approaches to resource recovery for remote printer server sites and includes discussions of issues pertaining to auditing, security, and denial of access. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1486 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1529
RFC1530 Principles of Operation for the TPC.INT Subdomain: General Principles and Policy C. Malamud M. Rose October 1993 ASCII 15031 7 FAX Facsimile

This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1530
RFC1531 Dynamic Host Configuration Protocol R. Droms October 1993 ASCII 96192 39 DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. [STANDARDS-TRACK]

RFC1541 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1531 10.17487/RFC1531
RFC1532 Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993 ASCII 51545 22 BOOTP

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]

RFC1542 RFC0951 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC1532
RFC1533 DHCP Options and BOOTP Vendor Extensions S. Alexander R. Droms October 1993 ASCII 50919 30 Dynamic Host Configuration Bootstrap

This document specifies the current set of DHCP options. [STANDARDS-TRACK]

RFC1497 RFC1395 RFC1084 RFC1048 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1533 10.17487/RFC1533
RFC1534 Interoperation Between DHCP and BOOTP R. Droms October 1993 ASCII 6966 4 DHCP-BOOTP Dynamic Host Configuration Bootstrap

DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants. [STANDARDS-TRACK]

DRAFT STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1534 10.17487/RFC1534
RFC1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software E. Gavron October 1993 ASCII 9722 5 Domain Name System

This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit. This document points out the flaw, a case in point, and a solution. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1535 10.17487/RFC1535
RFC1536 Common DNS Implementation Errors and Suggested Fixes A. Kumar J. Postel C. Neuman P. Danzig S. Miller October 1993 ASCII 25476 12 Domain Name System

This memo describes common errors seen in DNS implementations and suggests some fixes. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1536
RFC1537 Common DNS Data File Configuration Errors P. Beertema October 1993 ASCII 19825 9 Domain Name System

This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1912 INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1537
RFC1538 Advanced SNA/IP : A Simple SNA Transport Protocol W. Behl B. Sterling W. Teskey October 1993 ASCII 21217 10 ADSNA-IP Domain Name System

This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1538
RFC1539 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force G. Malkin October 1993 ASCII 48199 22 Introduction

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]

RFC1391 RFC1718 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1539
RFC1540 Internet Official Protocol Standards J. Postel October 1993 ASCII 75496 34 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

RFC1500 RFC1600 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1540
RFC1541 Dynamic Host Configuration Protocol R. Droms October 1993 ASCII 96950 39 DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]

RFC1531 RFC2131 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1541
RFC1542 Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993 ASCII 52948 23 BOOTP

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]

RFC1532 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1542 10.17487/RFC1542
RFC1543 Instructions to RFC Authors J. Postel October 1993 ASCII 31383 16 Request For Comment

This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1111 RFC0825 RFC2223 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1543
RFC1544 The Content-MD5 Header Field M. Rose November 1993 ASCII 6478 3 MIME EMail Integrity MIC Digest

This memo defines the use of an optional header field, Content-MD5, which may be used as a message integrity check (MIC), to verify that the decoded data are the same data that were initially sent. [STANDARDS-TRACK]

RFC1864 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1544
RFC1545 FTP Operation Over Big Address Records (FOOBAR) D. Piscitello November 1993 ASCII 8985 5 FTP File Transfer PORT PASV LPRT LPSV

This RFC specifies a method for assigning long addresses in the HOST- PORT specification for the data port to be used in establishing a data connection for File Transfer Protocol, FTP (STD 9, RFC 959). This is a general solution, applicable for all "next generation" IP alternatives, and can also be extended to allow FTP operation over transport interfaces other than TCP. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1639 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1545
RFC1546 Host Anycasting Service C. Partridge T. Mendez W. Milliken November 1993 ASCII 22263 9 Resource Location Multicasting

This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC1546
RFC1547 Requirements for an Internet Standard Point-to-Point Protocol D. Perkins December 1993 ASCII 49810 21 PPP link serial line

This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1547
RFC1548 The Point-to-Point Protocol (PPP) W. Simpson December 1993 ASCII 111638 53 link serial line

This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

RFC1331 RFC1661 RFC1570 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1548
RFC1549 PPP in HDLC Framing W. Simpson Editor December 1993 ASCII 36352 18 point link serial line

This document describes the use of HDLC for framing PPP encapsulated packets. [STANDARDS-TRACK]

RFC1662 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1549
RFC1550 IP: Next Generation (IPng) White Paper Solicitation S. Bradner A. Mankin December 1993 ASCII 12472 6

This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1550
RFC1551 Novell IPX Over Various WAN Media (IPXWAN) M. Allen December 1993 ASCII 54210 22 Internetworking Packet Exchange

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1634 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1551
RFC1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) W. Simpson December 1993 ASCII 29173 16 IPXCP IPX point serial line link

This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1552
RFC1553 Compressing IPX Headers Over WAN Media (CIPX) S. Mathur M. Lewis December 1993 ASCII 47450 23 CIPX Internetworking Packet Exchange

This document describes a method for compressing the headers of IPX datagrams (CIPX). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1553
RFC1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP M. Ohta K. Handa December 1993 ASCII 11449 6 Character Set Japanese

This memo describes a text encoding scheme: "ISO-2022-JP-2", which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of "ISO-2022-JP", the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1554
RFC1555 Hebrew Character Encoding for Internet Messages H. Nussbacher Y. Bourvine December 1993 ASCII 9273 5 Character Set

This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME [RFC1521] and ISO-8859-8. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1555
RFC1556 Handling of Bi-directional Texts in MIME H. Nussbacher December 1993 ASCII 5602 3 Character Set

This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1556
RFC1557 Korean Character Encoding for Internet Messages U. Choi K. Chon H. Park December 1993 ASCII 8736 5 Character Set

This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1557
RFC1558 A String Representation of LDAP Search Filters T. Howes December 1993 ASCII 5239 3 X.500 Directory

The Lightweight Directory Access Protocol (LDAP) defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1960 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1558
RFC1559 DECnet Phase IV MIB Extensions J. Saperia December 1993 ASCII 125427 69 DECNET-MIB Management SNMP

This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK]

RFC1289 DRAFT STANDARD DRAFT STANDARD IETF decnetiv 10.17487/RFC1559
RFC1560 The MultiProtocol Internet B. Leiner Y. Rekhter December 1993 ASCII 16651 7 Architecture Protocol

There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1560
RFC1561 Use of ISO CLNP in TUBA Environments D. Piscitello December 1993 ASCII 55902 25 CLNP-TUBA OSI IP Internet Protocol

This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol for use in conjunction with RFC 1347, TCP/UDP over Bigger Addresses. It describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol and User Datagram Protocol. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL IETF int tuba 10.17487/RFC1561
RFC1562 Naming Guidelines for the AARNet X.500 Directory Service G. Michaelson M. Prior December 1993 ASCII 6884 4 Australia

This document is an AARNet (Australian Academic and Research Network) Engineering Note (AEN-001). AARNet Engineering Notes are engineering documents of the AARNet Engineering Working Group, and record current or proposed operational practices related to the provision of Internetworking services within Australia, and AARNet in particular. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1562
RFC1563 The text/enriched MIME Content-type N. Borenstein January 1994 ASCII 32913 16 PS 73543 PDF 37459 email mail richtext

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1523 RFC1896 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1563
RFC1564 DSA Metrics (OSI-DS 34 (v3)) P. Barker R. Hedberg January 1994 ASCII 46205 21 x.500 Directory Service Agent

This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1564
RFC1565 Network Services Monitoring MIB S. Kille N. Freed January 1994 ASCII 29761 17 Management Information Base

This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK]

RFC2248 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1565
RFC1566 Mail Monitoring MIB S. Kille N. Freed January 1994 ASCII 33136 20 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK]

RFC2249 RFC2789 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1566
RFC1567 X.500 Directory Monitoring MIB G. Mansfield S. Kille January 1994 ASCII 33527 18 X500-MIB Management Information Base

This document defines a portion of the Management Information Base (MIB). It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. [STANDARDS-TRACK]

RFC2605 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1567
RFC1568 Simple Network Paging Protocol - Version 1(b) A. Gwinn January 1994 ASCII 16558 8 Beeper

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1645 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1568
RFC1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures M. Rose January 1994 ASCII 12597 6 Beeper

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1703 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1569
RFC1570 PPP LCP Extensions W. Simpson Editor January 1994 ASCII 35719 19 PPP-LCP Point-to Point Link Control Protocol serial line

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years. [STANDARDS-TRACK]

RFC1548 RFC2484 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1570
RFC1571 Telnet Environment Option Interoperability Issues D. Borman January 1994 ASCII 8117 4

This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1408 INFORMATIONAL INFORMATIONAL IETF app telnet 10.17487/RFC1571
RFC1572 Telnet Environment Option S. Alexander Editor January 1994 ASCII 14676 7 TOPT-ENVIR

This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app telnet 10.17487/RFC1572
RFC1573 Evolution of the Interfaces Group of MIB-II K. McCloghrie F. Kastenholz January 1994 ASCII 123057 55 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANARDS-TRACK]

RFC1229 RFC2233 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC1573
RFC1574 Essential Tools for the OSI Internet S. Hares C. Wittbrodt February 1994 ASCII 27735 13 Echo Traceroute Routing Table CLNP

This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): ping or OSI Echo function, traceroute function which uses the OSI Echo function, and routing table dump function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1139 INFORMATIONAL INFORMATIONAL IETF noop 10.17487/RFC1574
RFC1575 An Echo Function for CLNP (ISO 8473) S. Hares C. Wittbrodt February 1994 ASCII 22479 9 ISO-TS-ECHO

This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473" an integral part of Version 2 of ISO 8473. [STANDARDS-TRACK]

RFC1139 DRAFT STANDARD DRAFT STANDARD IETF noop 10.17487/RFC1575
RFC1576 TN3270 Current Practices J. Penner January 1994 ASCII 24477 12 Telnet Option Terminal Type EOR Binary

This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270. This memo provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC1576
RFC1577 Classical IP and ARP over ATM M. Laubach January 1994 ASCII 41239 17 Internet Protocol Address Resolution Asynchronous Transmission Mode

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]

RFC2225 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1577
RFC1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions J. Sellers February 1994 ASCII 113646 53 K12

The goal of this FYI RFC is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 22]

RFC1941 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1578
RFC1579 Firewall-Friendly FTP S. Bellovin February 1994 ASCII 8806 4 file transfer PORT PASV Security

This memo describes a suggested change to the behavior of FTP client programs. This document provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1579
RFC1580 Guide to Network Resource Tools EARN Staff March 1994 ASCII 235112 107 EARN BITNET Gopher World-Wide Web WWW WAIS Archie Whois X.500 Netfind Trickle BIFTP Listserv Netnews Astra NetServ Mail Base Prospero IRC Relay

The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 23]

FYI0023 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1580
RFC1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits G. Meyer February 1994 ASCII 7536 4 routing Protocol

As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1581
RFC1582 Extensions to RIP to Support Demand Circuits G. Meyer February 1994 ASCII 63271 29 RIP-DC routing Protocol

This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1582
RFC1583 OSPF Version 2 J. Moy March 1994 ASCII 532636 216 PS 990794 PDF 465711 equal-cost multipath link state LSA

This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]

RFC1247 RFC2178 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1583
RFC1584 Multicast Extensions to OSPF J. Moy March 1994 ASCII 262463 102 PS 426358 PDF 243185 OSPF-Multi Open Shortest Path First

This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1584
RFC1585 MOSPF: Analysis and Experience J. Moy March 1994 ASCII 29754 13 Multicast Open Shortest Path First OSPF

This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering Task Force internet routing protocol standardization criteria" ([RFC 1264]). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1585
RFC1586 Guidelines for Running OSPF Over Frame Relay Networks O. deSouza M. Rodrigues March 1994 ASCII 14968 6 FR Open Shortest Path First

This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1586
RFC1587 The OSPF NSSA Option R. Coltun V. Fuller March 1994 ASCII 37412 17 OSPF-NSSA Open Shortest Path First not so stubby area routing protocol

This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]

RFC3101 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1587
RFC1588 White Pages Meeting Report J. Postel C. Anderson February 1994 ASCII 77945 35 X-500 directory

This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1588
RFC1589 A Kernel Model for Precision Timekeeping D. Mills March 1994 ASCII 88129 37 Time NTP Clock

This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1589
RFC1590 Media Type Registration Procedure J. Postel March 1994 ASCII 13044 7 email multimedia

Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content-type/subtypes). It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 RFC1521 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1590
RFC1591 Domain Name System Structure and Delegation J. Postel March 1994 ASCII 16481 7 DNS Policy Top-Level TLD

This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1591
RFC1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0 B. Wijnen G. Carpenter K. Curran A. Sehgal G. Waters March 1994 ASCII 135259 54 SNMP-DPI SNMP DPT IBM

This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1228 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1592
RFC1593 SNA APPN Node MIB W. McKenzie J. Cheng March 1994 ASCII 207882 120 IBM Management

This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1593
RFC1594 FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions A. Marine J. Reynolds G. Malkin March 1994 ASCII 98753 44 documentation help information FAQ

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 4]

RFC1325 RFC2664 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC1594
RFC1595 Definitions of Managed Objects for the SONET/SDH Interface Type T. Brown K. Tesink March 1994 ASCII 121937 59 SONET-MIB MIB Management SNMP RFC2558 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC1595 RFC1596 Definitions of Managed Objects for Frame Relay Service T. Brown Editor March 1994 ASCII 88795 46 FR MIB Management SNMP RFC1604 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC1596 RFC1597 Address Allocation for Private Internets Y. Rekhter B. Moskowitz D. Karrenberg G. de Groot March 1994 ASCII 17430 8 IP Network Number Local

This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1918 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1597
RFC1598 PPP in X.25 W. Simpson March 1994 ASCII 13835 8 PPP-X25 point

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1598
RFC1599 Summary of 1500-1599 M. Kennedy January 1997 ASCII 43761 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1599 RFC1600 Internet Official Protocol Standards J. Postel March 1994 ASCII 80958 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1540 RFC1610 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1600
RFC1601 Charter of the Internet Architecture Board (IAB) C. Huitema March 1994 ASCII 12424 6 ISOC Internet Society IETF IRTF

This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1358 RFC2850 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1601
RFC1602 The Internet Standards Process -- Revision 2 Internet Architecture Board Internet Engineering Steering Group March 1994 ASCII 88465 37

This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1310 RFC2026 RFC1871 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1602
RFC1603 IETF Working Group Guidelines and Procedures E. Huizer D. Crocker March 1994 ASCII 63900 29 WG

This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2418 RFC1871 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1603
RFC1604 Definitions of Managed Objects for Frame Relay Service T. Brown Editor March 1994 ASCII 88770 46 FR-MIB MIB Management SNMP Network

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]

RFC1596 RFC2954 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1604
RFC1605 SONET to Sonnet Translation W. Shakespeare April 1 1994 ASCII 4451 3 Humor

Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation (SONNET). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1605
RFC1606 A Historical Perspective On The Usage Of IP Version 9 J. Onions April 1 1994 ASCII 8398 4 Humor

This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1606
RFC1607 A VIEW FROM THE 21ST CENTURY V. Cerf April 1 1994 ASCII 28165 14 V. Cerf

This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1607
RFC1608 Representing IP Information in the X.500 Directory T. Johannsen G. Mansfield M. Kosters S. Sataluri March 1994 ASCII 40269 20 X500-DIR Data Structure Schemo

This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in the Directory by applying it to IP networks. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app osids 10.17487/RFC1608
RFC1609 Charting Networks in the X.500 Directory G. Mansfield T. Johannsen M. Knopper March 1994 ASCII 30044 15 X500-CHART Data Structure Schemo

This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app osids http://www.rfc-editor.org/errata_search.php?rfc=1609 10.17487/RFC1609
RFC1610 Internet Official Protocol Standards J. Postel July 1994 ASCII 81346 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1600 RFC1720 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1610
RFC1611 DNS Server MIB Extensions R. Austein J. Saperia May 1994 ASCII 58700 30 DNS-S-MIB Domain Name System Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int dns 10.17487/RFC1611
RFC1612 DNS Resolver MIB Extensions R. Austein J. Saperia May 1994 ASCII 61382 32 DNS-R-MIB Domain Name System Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int dns 10.17487/RFC1612
RFC1613 cisco Systems X.25 over TCP (XOT) J. Forster G. Satz G. Glick R. Day May 1994 ASCII 29267 13 Transmission Control Protocol

This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1613
RFC1614 Network Access to Multimedia Information C. Adie May 1994 ASCII 187253 79 RARE Technical Report

This report summarises the requirements of research and academic network users for network access to multimedia information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv imm 10.17487/RFC1614
RFC1615 Migrating from X.400(84) to X.400(88) J. Houttuin J. Craigie May 1994 ASCII 39693 17 RARE Technical Report email

This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1615
RFC1616 X.400(1988) for the Academic and Research Community in Europe RARE WG-MSG Task Force 88 E. Huizer J. Romaguera Editors May 1994 ASCII 107432 44 RARE Technical Report email

The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1616
RFC1617 Naming and Structuring Guidelines for X.500 Directory Pilots P. Barker S. Kille T. Lenggenhager May 1994 ASCII 56739 28 RARE Technical Report White Pages

This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1384 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1617
RFC1618 PPP over ISDN W. Simpson May 1994 ASCII 14896 7 PPP-ISDN Point Integrated Services Digital Network

This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1618
RFC1619 PPP over SONET/SDH W. Simpson May 1994 ASCII 8893 5 PPP-SONET Point Synchronous Optical Network Digital Heirarchy

This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. [STANDARDS-TRACK]

RFC2615 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1619
RFC1620 Internet Architecture Extensions for Shared Media B. Braden J. Postel Y. Rekhter May 1994 ASCII 44999 19 Public data networks ARP address resolution protocol

This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1620
RFC1621 Pip Near-term Architecture P. Francis May 1994 ASCII 128905 51 Internet Protocol IPng

The purpose of this RFC and the companion RFC "Pip Header Processing" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pip 10.17487/RFC1621
RFC1622 Pip Header Processing P. Francis May 1994 ASCII 34837 16 Internet Protocol IPng

The purpose of this RFC and the companion RFC "Pip Near-term Architecture" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pip 10.17487/RFC1622
RFC1623 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz May 1994 ASCII 38745 19 MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC1398 RFC1643 HISTORIC INTERNET STANDARD IETF int ifmib 10.17487/RFC1623
RFC1624 Computation of the Internet Checksum via Incremental Update A. Rijsinghani Editor May 1994 ASCII 9836 6

This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1141 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1624
RFC1625 WAIS over Z39.50-1988 M. St. Pierre J. Fullton K. Gamiel J. Goldman B. Kahle J. Kunze H. Morris F. Schiettecatte June 1994 ASCII 14694 7 Wide Area Information Servers Library

The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1625
RFC1626 Default IP MTU for use over ATM AAL5 R. Atkinson May 1994 ASCII 11841 5 Maximum Transmission Unit Asynchronous Transfer Mode Adaptation Layer Size Packet

There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK]

RFC2225 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1626
RFC1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified) E. Lear E. Fair D. Crocker T. Kessler July 1994 ASCII 18823 8 IP Network Number Local

This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1918 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1627
RFC1628 UPS Management Information Base J. Case Editor May 1994 ASCII 83439 45 UPS-MIB Uninterruptible Power Supply MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK]

INFORMATIONAL PROPOSED STANDARD IETF ops upsmib http://www.rfc-editor.org/errata_search.php?rfc=1628 10.17487/RFC1628
RFC1629 Guidelines for OSI NSAP Allocation in the Internet R. Colella R. Callon E. Gardner Y. Rekhter May 1994 ASCII 131640 52 OSI-NSAP CLNP Address

This paper provides guidelines for allocating NSAP addresses in the Internet. The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration. [STANDARDS-TRACK]

RFC1237 DRAFT STANDARD DRAFT STANDARD IETF osinsap 10.17487/RFC1629
RFC1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web T. Berners-Lee June 1994 ASCII 57601 28 World Wide Web URI

This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1630
RFC1631 The IP Network Address Translator (NAT) K. Egevang P. Francis May 1994 ASCII 22714 10 Internet Protocol

This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC3022 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1631
RFC1632 A Revised Catalog of Available X.500 Implementations A. Getchell S. Sataluri Editors May 1994 ASCII 124111 94 Directory White Pages

This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1292 RFC2116 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1632
RFC1633 Integrated Services in the Internet Architecture: an Overview R. Braden D. Clark S. Shenker June 1994 ASCII 89691 33 PS 207016 PDF 201858 real time Multi-media reservations Protocol

This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real-time as well as the current non-real-time service of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1633 10.17487/RFC1633
RFC1634 Novell IPX Over Various WAN Media (IPXWAN) M. Allen May 1994 ASCII 55347 23 wide area network

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1551 RFC1362 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1634
RFC1635 How to Use Anonymous FTP P. Deutsch A. Emtage A. Marine May 1994 ASCII 27258 13 File Transfer Protocol

This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0024 INFORMATIONAL INFORMATIONAL IETF iafa 10.17487/RFC1635
RFC1636 Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994 R. Braden D. Clark S. Crocker C. Huitema June 1994 ASCII 130761 52 Internet Architecture Board

This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1636
RFC1637 DNS NSAP Resource Records B. Manning R. Colella June 1994 ASCII 21768 11 domain Name System ISO OSI Address

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. This memo defines an Experimental Protocol for the Internet community.

RFC1348 RFC1706 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1637
RFC1638 PPP Bridging Control Protocol (BCP) F. Baker R. Bowen June 1994 ASCII 58477 28 PPP-BCP Point to Point

This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]

RFC1220 RFC2878 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1638
RFC1639 FTP Operation Over Big Address Records (FOOBAR) D. Piscitello June 1994 ASCII 10055 5 FOOBAR File Transfer Port

This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a "long Port (LPRT)" command and "Long Passive (LPSV)" reply, each having as its argument a <long-host-port>, which allows for additional address families, variable length network addresses and variable length port numbers. This memo defines an Experimental Protocol for the Internet community.

RFC1545 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1639
RFC1640 The Process for Organization of Internet Standards Working Group (POISED) S. Crocker June 1994 ASCII 21780 10 IETF IESG IAB ISOC

This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1640
RFC1641 Using Unicode with MIME D. Goldsmith M. Davis July 1994 ASCII 11258 6 PS 20451 PDF 11658 MIME-UNI Multipurpose Internet Mail Extension Character Set

This document specifies the usage of Unicode within MIME. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1641
RFC1642 UTF-7 - A Mail-Safe Transformation Format of Unicode D. Goldsmith M. Davis July 1994 ASCII 27770 14 PS 50907 PDF 29573 character Set

This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. This memo defines an Experimental Protocol for the Internet community.

RFC2152 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1642
RFC1643 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz July 1994 ASCII 39008 19 ETHER-MIB MIB Network Management SNMP Ethernet

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC1623 RFC3638 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1643
RFC1644 T/TCP -- TCP Extensions for Transactions Functional Specification R. Braden July 1994 ASCII 87362 38 T/TCP Transmission Control Protocol

This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This memo describes an Experimental Protocol for the Internet community.

RFC6247 RFC1379 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1644
RFC1645 Simple Network Paging Protocol - Version 2 A. Gwinn July 1994 ASCII 31243 15 Beeper SNPP Mail

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1568 RFC1861 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1645
RFC1646 TN3270 Extensions for LUname and Printer Selection C. Graves T. Butts M. Angel July 1994 ASCII 27564 13 Telnet Option

This document describes protocol extensions to TN3270. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC1646
RFC1647 TN3270 Enhancements B. Kelly July 1994 ASCII 84420 34 Telnet Option

This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. [STANDARDS-TRACK]

RFC2355 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC1647
RFC1648 Postmaster Convention for X.400 Operations A. Cargille July 1994 ASCII 8761 4 Mail

This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app x400ops 10.17487/RFC1648
RFC1649 Operational Requirements for X.400 Management Domains in the GO-MHS Community R. Hagens A. Hansen July 1994 ASCII 28138 14 Mail Global Open Message Handling System

The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app x400ops 10.17487/RFC1649
RFC1650 Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2 F. Kastenholz August 1994 ASCII 40484 20 MIB Management Information Base 802.3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC2358 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC1650
RFC1651 SMTP Service Extensions J. Klensin N. Freed M. Rose E. Stefferud D. Crocker July 1994 ASCII 22153 11 Mail Simple Transfer

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

RFC1425 RFC1869 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1651
RFC1652 SMTP Service Extension for 8bit-MIMEtransport J. Klensin N. Freed M. Rose E. Stefferud D. Crocker July 1994 ASCII 11842 6 SMTP Mail Simple Transfer

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]

RFC1426 RFC6152 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1652
RFC1653 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed K. Moore July 1994 ASCII 17883 8 Mail Simple Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

RFC1427 RFC1870 DRAFT STANDARD DRAFT STANDARD IETF app smtpext 10.17487/RFC1653
RFC1654 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter T. Li Editors July 1994 ASCII 130118 56 routing

This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1771 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1654
RFC1655 Application of the Border Gateway Protocol in the Internet Y. Rekhter P. Gross Editors July 1994 ASCII 43664 19 BGP-4 Routing

This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1268 RFC1772 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1655
RFC1656 BGP-4 Protocol Document Roadmap and Implementation Experience P. Traina July 1994 ASCII 7705 4 Border Gateway Protocol Routing

Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1773 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1656
RFC1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 S. Willis J. Burruss J. Chu Editor July 1994 ASCII 45505 21 BGP-4-MIB MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK]

RFC4273 DRAFT STANDARD DRAFT STANDARD IETF rtg idr 10.17487/RFC1657
RFC1658 Definitions of Managed Objects for Character Stream Devices using SMIv2 B. Stewart July 1994 ASCII 32579 18 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK]

RFC1316 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1658
RFC1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2 B. Stewart July 1994 ASCII 36479 21 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]

RFC1317 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1659
RFC1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2 B. Stewart July 1994 ASCII 16784 10 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK]

RFC1318 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1660
RFC1661 The Point-to-Point Protocol (PPP) W. Simpson Editor July 1994 ASCII 103026 53 PPP Specification Standard link serial line

This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

RFC1548 RFC2153 STD0051 INTERNET STANDARD INTERNET STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1661 10.17487/RFC1661
RFC1662 PPP in HDLC-like Framing W. Simpson Editor July 1994 ASCII 48058 26 PPP-HDLC Point Protocol Specification Standard link serial line

This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK]

RFC1549 STD0051 INTERNET STANDARD INTERNET STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1662 10.17487/RFC1662
RFC1663 PPP Reliable Transmission D. Rand July 1994 ASCII 17281 8 PPP-TRANS Point Protocol

This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1663
RFC1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables C. Allocchio A. Bonito B. Cole S. Giordano R. Hagens August 1994 ASCII 50783 23 domain Name System X.400 Email

This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. This memo defines an Experimental Protocol for the Internet community.

RFC2163 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1664
RFC1665 Definitions of Managed Objects for SNA NAUs using SMIv2 Z. Kielczewski D. Kostick K. Shih Editors July 1994 ASCII 133381 67 MIB Management Information Base System Network Architecture Addressable Units

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

RFC1666 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC1665
RFC1666 Definitions of Managed Objects for SNA NAUs using SMIv2 Z. Kielczewski D. Kostick K. Shih Editors August 1994 ASCII 134385 68 SNANAU-MIB Network Management SNMP MIB Protocol Units Architecture Addressable Information System

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

RFC1665 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1666
RFC1667 Modeling and Simulation Requirements for IPng S. Symington D. Wood M. Pullen August 1994 ASCII 17291 7 White Paper

This white paper summarizes the Distributed Interactive Simulation environment that is under development, with regard to its real-time nature, scope and magnitude of networking requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1667
RFC1668 Unified Routing Requirements for IPng D. Estrin T. Li Y. Rekhter August 1994 ASCII 5106 3 White Paper

The document provides requirements on the IPng from the perspective of the Unified Routing Architecture, as described in RFC 1322. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1668
RFC1669 Market Viability as a IPng Criteria J. Curran August 1994 ASCII 8099 4 White Paper

"Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1669
RFC1670 Input to IPng Engineering Considerations D. Heagerty August 1994 ASCII 5350 3 White Paper

This white paper expresses some personal opinions on IPng engineering considerations, based on experience with DECnet Phase V transition. It suggests breaking down the IPng decisions and transition tasks into smaller parts so they can be tackled early by the relevant experts. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1670
RFC1671 IPng White Paper on Transition and Other Considerations B. Carpenter August 1994 ASCII 17631 8

This white paper outlines some general requirements for IPng in selected areas. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1671
RFC1672 Accounting Requirements for IPng N. Brownlee August 1994 ASCII 6185 3 White Paper

This white paper discusses accounting requirements for IPng. It recommends that all IPng packets carry accounting tags, which would vary in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1672
RFC1673 Electric Power Research Institute Comments on IPng R. Skelton August 1994 ASCII 7476 4 White Paper

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1673
RFC1674 A Cellular Industry View of IPng M. Taylor August 1994 ASCII 6157 3 White Paper

This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1674
RFC1675 Security Concerns for IPng S. Bellovin August 1994 ASCII 8290 4 White Paper

A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1675
RFC1676 INFN Requirements for an IPng A. Ghiselli D. Salomoni C. Vistoli August 1994 ASCII 8493 4 White Paper

With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1676
RFC1677 Tactical Radio Frequency Communication Requirements for IPng B. Adamson August 1994 ASCII 24065 9 White Paper

This paper describes requirements for Internet Protocol next generation (IPng) candidates with respect to their application to military tactical radio frequency (RF) communication networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1677
RFC1678 IPng Requirements of Large Corporate Networks E. Britton J. Tavs August 1994 ASCII 18650 8 White Paper

This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1678
RFC1679 HPN Working Group Input to the IPng Requirements Solicitation D. Green P. Irey D. Marlow K. O'Donoghue August 1994 ASCII 22974 10 White Paper

The purpose of this document is to provide what the HPN working group perceives as requirements for an IPng protocol set. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1679
RFC1680 IPng Support for ATM Services C. Brazdziunas August 1994 ASCII 17846 7 White Paper

This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1680
RFC1681 On Many Addresses per Host S. Bellovin August 1994 ASCII 11964 5 White Paper

This document was submitted to the IETF IPng area in response to RFC 1550.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1681
RFC1682 IPng BSD Host Implementation Analysis J. Bound August 1994 ASCII 22295 10 White Paper Unix

This IPng white paper, IPng BSD Host Implementation Analysis, was submitted to the IPng Directorate to provide a BSD host point of reference to assist with the engineering considerations during the IETF process to select an IPng proposal. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1682
RFC1683 Multiprotocol Interoperability In IPng R. Clark M. Ammar K. Calvert August 1994 ASCII 28201 12 White Paper

In this document, we identify several features that affect a protocol's ability to operate in a multiprotocol environment and propose the incorporation of these features into IPng. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1683
RFC1684 Introduction to White Pages Services based on X.500 P. Jurg August 1994 ASCII 22985 10 Directory

The document provides an introduction to the international ITU-T (formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic White Pages Service. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1684
RFC1685 Writing X.400 O/R Names H. Alvestrand August 1994 ASCII 21242 11 EMail Mail

There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind.

RTR0012 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1685 10.17487/RFC1685
RFC1686 IPng Requirements: A Cable Television Industry Viewpoint M. Vecchi August 1994 ASCII 39052 14 White Paper

This paper provides comments on topics related to the IPng requirements and selection criteria from a cable television industry viewpoint. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1686
RFC1687 A Large Corporate User's View of IPng E. Fleischman August 1994 ASCII 34120 13 White Paper

The goal of this paper is to examine the implications of IPng from the point of view of Fortune 100 corporations which have heavily invested in TCP/IP technology in order to achieve their (non-computer related) business goals.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1687
RFC1688 IPng Mobility Considerations W. Simpson August 1994 ASCII 19151 9 White Paper

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1688
RFC1689 A Status Report on Networked Information Retrieval: Tools and Groups J. Foster Editor August 1994 ASCII 375469 226 NIR

The purpose of this report is to increase the awareness of Networked Information Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0025 INFORMATIONAL INFORMATIONAL IETF nir 10.17487/RFC1689
RFC1690 Introducing the Internet Engineering and Planning Group (IEPG) G. Huston August 1994 ASCII 3013 2 charter

This memo introduces the IEPG to the Internet Community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1690
RFC1691 The Document Architecture for the Cornell Digital Library W. Turner August 1994 ASCII 20438 10

This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1691
RFC1692 Transport Multiplexing Protocol (TMux) P. Cameron D. Crocker D. Cohen J. Postel August 1994 ASCII 26163 12 TMUX Internet Protocol IP

This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1692
RFC1693 An Extension to TCP : Partial Order Service T. Connolly P. Amer P. Conrad November 1994 ASCII 90100 36 TCP-POS Transmission Control Protocol

This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. This memo defines an Experimental Protocol for the Internet community.

RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1693
RFC1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2 T. Brown K. Tesink Editors August 1994 ASCII 70856 35 SIP-MIB Standard,MIB,Network,Management,Switched,Multimegabit,Data,Service,Informatiom,Base,SMDS

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing objects for SMDS access interfaces. [STANDARDS-TRACK]

RFC1304 DRAFT STANDARD DRAFT STANDARD IETF int ifmib 10.17487/RFC1694
RFC1695 Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2 M. Ahmed K. Tesink Editors August 1994 ASCII 175461 73 ATM-MIB MIB Management,Information,Base,Asychronous,Transmission,Mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

RFC2515 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC1695
RFC1696 Modem Management Information Base (MIB) using SMIv2 J. Barnes L. Brown R. Royston S. Waldbusser August 1994 ASCII 54054 31 MODEM-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF modemmgt 10.17487/RFC1696
RFC1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2 D. Brower Editor B. Purvy A. Daniel M. Sinykin J. Smith August 1994 ASCII 76202 38 RDBMS-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing relational database (RDBMS) implementations. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rdbmsmib 10.17487/RFC1697
RFC1698 Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications P. Furniss October 1994 ASCII 67433 29 Protocol Headers

This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF thinosi 10.17487/RFC1698
RFC1699 Summary of 1600-1699 J. Elliott January 1997 ASCII 40674 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1699 RFC1700 Assigned Numbers J. Reynolds J. Postel October 1994 ASCII 458860 230 status procedure index parameters registered allocated

This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

RFC1340 RFC3232 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1700
RFC1701 Generic Routing Encapsulation (GRE) S. Hanks T. Li D. Farinacci P. Traina October 1994 ASCII 15460 8 GRE Internet Protocol IP

This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1701
RFC1702 Generic Routing Encapsulation over IPv4 networks S. Hanks T. Li D. Farinacci P. Traina October 1994 ASCII 7288 4 GRE-IPv4 Internet Protocol IP

This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1702
RFC1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures M. Rose October 1994 ASCII 17985 9 RADIO-PAGE Beepers

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1569 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1703
RFC1704 On Internet Authentication N. Haller R. Atkinson October 1994 ASCII 42269 17 Security Energyption Policy Guidelines

This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1704
RFC1705 Six Virtual Inches to the Left: The Problem with IPng R. Carlson D. Ficarella October 1994 ASCII 65222 27 IPng White paper

This document was submitted to the IETF IPng area in response to RFC 1550. This RFC suggests that a new version of TCP (TCPng), and UDP, be developed and deployed. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1705
RFC1706 DNS NSAP Resource Records B. Manning R. Colella October 1994 ASCII 19721 10 DNS-NSAP Domain Name System ISO OSI Address RR Record Resource

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1637 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1706
RFC1707 CATNIP: Common Architecture for the Internet M. McGovern R. Ullmann October 1994 ASCII 37568 16 IPng White Paper IPv7

This document was submitted to the IETF IPng area in response to RFC 1550. This paper describes a common architecture for the network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1707
RFC1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3 D. Gowin October 1994 ASCII 26523 13

This RFC describes a PICS Proforma translated into an Internet acceptable form. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1708
RFC1709 K-12 Internetworking Guidelines J. Gargano D. Wasley November 1994 ASCII 66659 26 PS 662030 PDF 134065 school network education connection

The K-12 community traditionally has not had this level of staffing available for telecommunications planning. This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0026 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1709
RFC1710 Simple Internet Protocol Plus White Paper R. Hinden October 1994 ASCII 56910 23 SIPP IPng

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF sipp 10.17487/RFC1710
RFC1711 Classifications in E-mail Routing J. Houttuin October 1994 ASCII 47584 19 Email Electronic Mail

This paper presents a classification for e-mail routing issues. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1711
RFC1712 DNS Encoding of Geographical Location C. Farrell M. Schulze S. Pleitner D. Baldoni November 1994 ASCII 13237 7 DNS-ENCODE Domain Names System GPOS

This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1712 10.17487/RFC1712
RFC1713 Tools for DNS debugging A. Romao November 1994 ASCII 33500 13 Domain Names System Host DNSWalk DOC DDT Checker

Although widely used (and most of the times unnoticed), DNS (Domain Name System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work. This document presents some tools available for domain administrators to detect and correct those anomalies. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0027 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1713
RFC1714 Referral Whois Protocol (RWhois) S. Williamson M. Kosters November 1994 ASCII 85395 46 PS 204207 PDF 85556 White Pages Directory

This memo describes version 1.0 of the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2167 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1714
RFC1715 The H Ratio for Address Assignment Efficiency C. Huitema November 1994 ASCII 7392 4 IPng White Paper

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC3194 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1715
RFC1716 Towards Requirements for IP Routers P. Almquist F. Kastenholz November 1994 ASCII 432330 192 Gateway Internet Protocol

The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1812 INFORMATIONAL INFORMATIONAL IETF rtg rreq 10.17487/RFC1716
RFC1717 The PPP Multilink Protocol (MP) K. Sklower B. Lloyd G. McGregor D. Carr November 1994 ASCII 46264 21 Point

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]

RFC1990 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1717
RFC1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force IETF Secretariat G. Malkin November 1994 ASCII 50458 23 Internet Engineering Task Force Meeting

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]

RFC1539 RFC3160 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1718
RFC1719 A Direction for IPng P. Gross December 1994 ASCII 11118 6 IPng White Paper Internet Protocol

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1719
RFC1720 Internet Official Protocol Standards J. Postel November 1994 ASCII 89063 41 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1610 RFC1780 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1720
RFC1721 RIP Version 2 Protocol Analysis G. Malkin November 1994 ASCII 6680 4 RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1387 INFORMATIONAL INFORMATIONAL IETF rtg ripv2 10.17487/RFC1721
RFC1722 RIP Version 2 Protocol Applicability Statement G. Malkin November 1994 ASCII 10236 5 RIP2-APP RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet. This report is a prerequisite to advancing RIP-2 on the standards track. [STANDARDS-TRACK]

STD0057 INTERNET STANDARD DRAFT STANDARD IETF rtg ripv2 10.17487/RFC1722
RFC1723 RIP Version 2 - Carrying Additional Information G. Malkin November 1994 ASCII 18597 9 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP), o expand the amount of useful information carried in RIP messages and to add a measure of security. This memo obsoletes RFC 1388, which specifies an update to the "Routing Information Protocol" STD 34, RFC 1058. [STANDARDS-TRACK]

RFC1388 RFC2453 RFC1058 INTERNET STANDARD DRAFT STANDARD IETF rtg ripv2 10.17487/RFC1723
RFC1724 RIP Version 2 MIB Extension G. Malkin F. Baker November 1994 ASCII 29645 18 RIP2-MIB RIP-2 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing RIP Version 2. [STANDARDS-TRACK]

RFC1389 DRAFT STANDARD DRAFT STANDARD IETF rtg ripv2 http://www.rfc-editor.org/errata_search.php?rfc=1724 10.17487/RFC1724
RFC1725 Post Office Protocol - Version 3 J. Myers M. Rose November 1994 ASCII 35058 18 POP Email Electronic Mail

This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]

RFC1460 RFC1939 INTERNET STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1725 10.17487/RFC1725
RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng) C. Partridge F. Kastenholz December 1994 ASCII 74109 31 IPng White Paper Internet Protocol

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1726
RFC1727 A Vision of an Integrated Internet Information Service C. Weider P. Deutsch December 1994 ASCII 28468 11 Universal Resource Names

This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1727
RFC1728 Resource Transponders C. Weider December 1994 ASCII 12092 6 Universal Resource Names Location System

This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1728
RFC1729 Using the Z39.50 Information Retrieval Protocol C. Lynch December 1994 ASCII 20927 8 Basic Endcoding Rules ASN1

This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1729
RFC1730 Internet Message Access Protocol - Version 4 M. Crispin December 1994 ASCII 156660 77 IMAP IMAP4 EMail

The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server. [STANDARDS-TRACK]

RFC2060 RFC2061 PROPOSED STANDARD PROPOSED STANDARD IETF app imap 10.17487/RFC1730
RFC1731 IMAP4 Authentication Mechanisms J. Myers December 1994 ASCII 11433 6 IMAP4-AUTH Internet Message Access Protocol Email

The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app imap 10.17487/RFC1731
RFC1732 IMAP4 Compatibility with IMAP2 and IMAP2bis M. Crispin December 1994 ASCII 9276 5 Internet Message Access Protocol Email

This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app imap 10.17487/RFC1732
RFC1733 Distributed Electronic Mail Models in IMAP4 M. Crispin December 1994 ASCII 6205 3 Internet Message Access Protocol Email

There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app imap 10.17487/RFC1733
RFC1734 POP3 AUTHentication command J. Myers December 1994 ASCII 8499 5 POP3-AUTH Post Office Protocol Email

This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]

RFC5034 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1734
RFC1735 NBMA Address Resolution Protocol (NARP) J. Heinanen R. Govindan December 1994 ASCII 24485 11 NARP Non-Broadcast Multi Access Address Resolution Protocol

This document describes the NBMA Address Resolution Protocol (NARP). NARP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL IETF rtg rolc 10.17487/RFC1735
RFC1736 Functional Recommendations for Internet Resource Locators J. Kunze February 1995 ASCII 22415 10 Uniform Resource URL

This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1736
RFC1737 Functional Requirements for Uniform Resource Names K. Sollins L. Masinter December 1994 ASCII 16337 7

This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1737
RFC1738 Uniform Resource Locators (URL) T. Berners-Lee L. Masinter M. McCahill December 1994 ASCII 51348 25 URL

This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]

RFC4248 RFC4266 RFC1808 RFC2368 RFC2396 RFC3986 RFC6196 RFC6270 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1738 10.17487/RFC1738
RFC1739 A Primer On Internet and TCP/IP Tools G. Kessler S. Shepard December 1994 ASCII 102676 46 NSlookup PING FINGER TRACEROUTE FTP TELNET WHOIS NICNAME KNOWBOT NETFIND ARCHIE Gopher Email Mailing Lists USENET

This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2151 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1739
RFC1740 MIME Encapsulation of Macintosh Files - MacMIME P. Faltstrom D. Crocker E. Fair December 1994 ASCII 31297 16 MacMIME Multipurpose Internet Mail Extensions

This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1740
RFC1741 MIME Content Type for BinHex Encoded Files P. Faltstrom D. Crocker E. Fair December 1994 ASCII 10155 6 BINHEX Multipurpose Internet Mail Extensions

This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1741
RFC1742 AppleTalk Management Information Base II S. Waldbusser K. Frisa January 1995 ASCII 168306 84 AT-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. [STANDARDS-TRACK]

RFC1243 HISTORIC PROPOSED STANDARD IETF int appleip 10.17487/RFC1742
RFC1743 IEEE 802.5 MIB using SMIv2 K. McCloghrie E. Decker December 1994 ASCII 43224 25 Management Information Base SNMP,

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

RFC1231 RFC1748 DRAFT STANDARD DRAFT STANDARD IETF int ifmib 10.17487/RFC1743
RFC1744 Observations on the Management of the Internet Address Space G. Huston December 1994 ASCII 32411 12 IP Internet Protocol

This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1744
RFC1745 BGP4/IDRP for IP---OSPF Interaction K. Varadhan S. Hares Y. Rekhter December 1994 ASCII 43675 19 BGP4/IDRP Internet Inter-Domain Routing Protocol Border Gateway Open Shortest Path First

This memo defines the various criteria to be used when designing an Autonomous System Border Router (ASBR) that will run either BGP4 or IDRP for IP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg idr 10.17487/RFC1745
RFC1746 Ways to Define User Expectations B. Manning D. Perkins December 1994 ASCII 46164 18

This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1746
RFC1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2 J. Hilgeman Chair S. Nix A. Bartky W. Clark Editor January 1995 ASCII 147388 67 SDLCSMIv2

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg snadlc 10.17487/RFC1747
RFC1748 IEEE 802.5 MIB using SMIv2 K. McCloghrie E. Decker December 1994 ASCII 43224 25 802.5-MIB Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

RFC1743 RFC1231 RFC1749 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1748
RFC1749 IEEE 802.5 Station Source Routing MIB using SMIv2 K. McCloghrie F. Baker E. Decker December 1994 ASCII 17563 10 802.5-SSR Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK]

RFC1748 HISTORIC PROPOSED STANDARD IETF int ifmib 10.17487/RFC1749
RFC1750 Randomness Recommendations for Security D. Eastlake 3rd S. Crocker J. Schiller December 1994 ASCII 73842 30 Random Numbers Seed

Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC4086 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1750
RFC1751 A Convention for Human-Readable 128-bit Keys D. McDonald December 1994 ASCII 31428 15 Security Password

This memo proposes a convention for use with Internet applications & protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1751
RFC1752 The Recommendation for the IP Next Generation Protocol S. Bradner A. Mankin January 1995 ASCII 127784 52 IPNG IPng Internet

This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1752
RFC1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture N. Chiappa December 1994 ASCII 46586 18 IPng White Paper Internet Protocol

This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1753
RFC1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1 M. Laubach January 1995 ASCII 13483 7 Internet Asynchromous Transfer Mode

This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1754
RFC1755 ATM Signaling Support for IP over ATM M. Perez F. Liaw A. Mankin E. Hoffman D. Grossman A. Malis February 1995 ASCII 55209 32 ATM Asynchronous Transfer Mode

This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1755
RFC1756 Remote Write Protocol - Version 1.0 T. Rinne January 1995 ASCII 22078 11 RWP Application

This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1756
RFC1757 Remote Network Monitoring Management Information Base S. Waldbusser February 1995 ASCII 208117 91 RMON-MIB MIB RMON

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

RFC1271 RFC2819 DRAFT STANDARD DRAFT STANDARD IETF ops rmonmib 10.17487/RFC1757
RFC1758 NADF Standing Documents: A Brief Overview The North American Directory Forum February 1995 ASCII 7294 4 X.500 North American Directory Forum Public CCITT Providers

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1758
RFC1759 Printer MIB R. Smith F. Wright T. Hastings S. Zilles J. Gyllenskog March 1995 ASCII 239228 113 Print-MIB Management Information Base

A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]

RFC3805 PROPOSED STANDARD PROPOSED STANDARD IETF app printmib 10.17487/RFC1759
RFC1760 The S/KEY One-Time Password System N. Haller February 1995 ASCII 31124 12 Security

This document describes the S/KEY* One-Time Password system as released for public use by Bellcore. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1760
RFC1761 Snoop Version 2 Packet Capture File Format B. Callaghan R. Gilligan February 1995 ASCII 10761 6 SNOOP Measurement debugging collecting data

This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1761
RFC1762 The PPP DECnet Phase IV Control Protocol (DNCP) S. Senum March 1995 ASCII 12709 7 PPP-DNCP Point Digital Equipment Corporation

This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). [STANDARDS-TRACK]

RFC1376 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1762
RFC1763 The PPP Banyan Vines Control Protocol (BVCP) S. Senum March 1995 ASCII 17817 10 BVCP Point

This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1763
RFC1764 The PPP XNS IDP Control Protocol (XNSCP) S. Senum March 1995 ASCII 9525 5 XNSCP Point Xerox Network Internetwork Datagram Service

This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1764
RFC1765 OSPF Database Overflow J. Moy March 1995 ASCII 21613 9 OSPF-OVFL

This memo details a way of gracefully handling unanticipated database overflows. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC1765
RFC1766 Tags for the Identification of Languages H. Alvestrand March 1995 ASCII 16966 9 Lang-Tag

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. [STANDARDS-TRACK]

RFC3066 RFC3282 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC1766
RFC1767 MIME Encapsulation of EDI Objects D. Crocker March 1995 ASCII 15293 7 MIME-EDI Electronic Data Interchange Multipurpose Internet Mail Extensions delivery mechanism encapsulation

Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app edi 10.17487/RFC1767
RFC1768 Host Group Extensions for CLNP Multicasting D. Marlow March 1995 ASCII 111499 45 CLNP-MULT ISO OSI

This memo provides a specification for multicast extensions to the CLNP protocol similar to those provided to IP by RFC1112. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL IETF int tuba 10.17487/RFC1768
RFC1769 Simple Network Time Protocol (SNTP) D. Mills March 1995 ASCII 34454 14 Clocks Synchronization NTP

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1361 RFC2030 RFC4330 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1769
RFC1770 IPv4 Option for Sender Directed Multi-Destination Delivery C. Graff March 1995 ASCII 11606 6 SDMD

This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed Broadcast Mode (SDBM). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC6814 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1770
RFC1771 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter T. Li March 1995 ASCII 131903 57 BGP-4 routing

This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1654 RFC4271 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1771 10.17487/RFC1771
RFC1772 Application of the Border Gateway Protocol in the Internet Y. Rekhter P. Gross March 1995 ASCII 43916 19 BGP-4-APP BGP-4 Routing

This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]

RFC1655 DRAFT STANDARD DRAFT STANDARD IETF rtg bgp 10.17487/RFC1772
RFC1773 Experience with the BGP-4 protocol P. Traina March 1995 ASCII 19936 9 BGP-4 Border Gateway Protocol Routing

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1656 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1773
RFC1774 BGP-4 Protocol Analysis P. Traina Editor March 1995 ASCII 23823 10 Border Gateway Routing

The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=1774 10.17487/RFC1774
RFC1775 To Be "On" the Internet D. Crocker March 1995 ASCII 8454 4 access full Client Mediated Messaging

The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1775
RFC1776 The Address is the Message S. Crocker April 1 1995 ASCII 2051 2 IPng

Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1776
RFC1777 Lightweight Directory Access Protocol W. Yeong T. Howes S. Kille March 1995 ASCII 45459 22 X.500 DAP interactive access

The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP).This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself. [STANDARDS-TRACK]

RFC1487 RFC3494 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1777
RFC1778 The String Representation of Standard Attribute Syntaxes T. Howes S. Kille W. Yeong C. Robbins March 1995 ASCII 19053 12 X.500 LDAP lightweight directory protocol

The Lightweight Directory Access Protocol (LDAP) requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes. [STANDARDS-TRACK]

RFC1488 RFC3494 RFC2559 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1778
RFC1779 A String Representation of Distinguished Names S. Kille March 1995 ASCII 12429 8 STR-REP X.500 directory names representing names

The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. [STANDARDS-TRACK]

RFC1485 RFC2253 RFC3494 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1779
RFC1780 Internet Official Protocol Standards J. Postel Editor March 1995 ASCII 86594 39 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1720 RFC1800 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1780
RFC1781 Using the OSI Directory to Achieve User Friendly Naming S. Kille March 1995 ASCII 47129 26 OSI-Dir X.500 directory names representing names

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. [STANDARDS-TRACK]

RFC1484 RFC3494 HISTORIC PROPOSED STANDARD IETF app asid 10.17487/RFC1781
RFC1782 TFTP Option Extension G. Malkin A. Harkin March 1995 ASCII 11508 6 trivial file transfer booting

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.

RFC2347 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1782
RFC1783 TFTP Blocksize Option G. Malkin A. Harkin March 1995 ASCII 7814 5 trivial file transfer booting

This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]

RFC2348 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1783
RFC1784 TFTP Timeout Interval and Transfer Size Options G. Malkin A. Harkin March 1995 ASCII 6106 4 trivial file transfer booting

This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. [STANDARDS-TRACK]

RFC2349 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1784
RFC1785 TFTP Option Negotiation Analysis G. Malkin A. Harkin March 1995 ASCII 3354 2 trivial file transfer booting

This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1350 INFORMATIONAL INFORMATIONAL IETF app tftpexts 10.17487/RFC1785
RFC1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++) T. Bates E. Gerich L. Joncheray J-M. Jouanigot D. Karrenberg M. Terpstra J. Yu March 1995 ASCII 133643 83

This document is an update to the original `ripe-81' proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc. and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1786
RFC1787 Routing in a Multi-provider Internet Y. Rekhter April 1995 ASCII 20754 8 Internet Protocol Architechure Board IAB

This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1787
RFC1788 ICMP Domain Name Messages W. Simpson April 1995 ASCII 11722 7 ICMP-DM Internet Control Message Protocol DNS Service

This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

RFC6918 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1788
RFC1789 INETPhone: Telephone Services and Servers on Internet C. Yang April 1995 ASCII 14186 6

This RFC presents a true telephone service, called INETPhone, which supports voice communication through the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1789
RFC1790 An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols V. Cerf April 1995 ASCII 8226 4 ISOC

This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1790
RFC1791 TCP And UDP Over IPX Networks With Fixed Path MTU T. Sung April 1995 ASCII 22347 12 Transmission Control Protocol User Datagram Maxium Unit

TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1791
RFC1792 TCP/IPX Connection Mib Specification T. Sung April 1995 ASCII 16389 9 TCP/IPXMIB Transmission Control Protocol Management Information Base

New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1792
RFC1793 Extending OSPF to Support Demand Circuits J. Moy April 1995 ASCII 78728 32 OSPF-DC Open Shortest Path First

This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". [STANDARDS-TRACK]

RFC3883 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1793
RFC1794 DNS Support for Load Balancing T. Brisco April 1995 ASCII 15494 7 Domain Name System

This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1794
RFC1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1 L. Wells Chair A. Bartky Editor April 1995 ASCII 214848 91 IBM SNA DLS SSP NetBIos APPN

This RFC describes use of Data Link Switching over TCP/IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1434 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1795
RFC1796 Not All RFCs are Standards C. Huitema J. Postel S. Crocker April 1995 ASCII 7049 4

This document discusses the relationship of the Request for Comments (RFCs) notes to Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1796
RFC1797 Class A Subnet Experiment Internet Assigned Numbers Authority (IANA) April 1995 ASCII 6779 4 Network Address 39 Number

There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1797
RFC1798 Connection-less Lightweight X.500 Directory Access Protocol A. Young June 1995 ASCII 18548 9 CLDAP CLDAP Presentation Address Application Entity Title

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]

RFC3352 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1798
RFC1799 Request for Comments Summary RFC Numbers 1700-1799 M. Kennedy January 1997 ASCII 42038 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1799 RFC1800 Internet Official Protocol Standards J. Postel Editor July 1995 ASCII 83649 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1780 RFC1880 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1800
RFC1801 MHS use of the X.500 Directory to support MHS Routing S. Kille June 1995 ASCII 156462 73 Routing Mail EMail Message Handling System X.400

The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1801
RFC1802 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing H. Alvestrand K. Jordan S. Langlois J. Romaguera June 1995 ASCII 24637 11 Mail EMail Message Handling System MHS

This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app mhsds 10.17487/RFC1802
RFC1803 Recommendations for an X.500 Production Directory Service R. Wright A. Getchell T. Howes S. Sataluri P. Yee W. Yeong June 1995 ASCII 14721 8 White Pages DSA Directory User Agent

This document contains a set of basic recommendations for a country- level X.500 DSA. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1803
RFC1804 Schema Publishing in X.500 Directory G. Mansfield P. Rajeev S. Raghavan T. Howes June 1995 ASCII 18268 10

In this document we propose a solution using the existing mechanisms of the directory [1] itself. We present a naming scheme for naming schema objects and a meta-schema for storing schema objects in the directory. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app asid 10.17487/RFC1804
RFC1805 Location-Independent Data/Software Integrity Protocol A. Rubin June 1995 ASCII 13352 6 Betsi Security Cryptography

This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1805
RFC1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header R. Troost S. Dorner June 1995 ASCII 15548 8 MIME EMail Mail

This memo provides a mechanism whereby messages conforming to the [RFC 1521] ("MIME") specification can convey presentational information. This memo defines an Experimental Protocol for the Internet community.

RFC2183 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1806
RFC1807 A Format for Bibliographic Records R. Lasher D. Cohen June 1995 ASCII 29417 15 library technical reports email services

This RFC defines a format for bibliographic records describing technical reports. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1357 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1807
RFC1808 Relative Uniform Resource Locators R. Fielding June 1995 ASCII 34950 16 URL URL syntax semantics

In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative Uniform Resource Locators. [STANDARDS-TRACK]

RFC3986 RFC1738 RFC2368 RFC2396 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1808
RFC1809 Using the Flow Label Field in IPv6 C. Partridge June 1995 ASCII 13591 6

The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1809
RFC1810 Report on MD5 Performance J. Touch June 1995 ASCII 16607 7 IPv6 Message Digest Algorithm Authentication

This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1810 10.17487/RFC1810
RFC1811 U.S. Government Internet Domain Names Federal Networking Council June 1995 ASCII 6641 3 GOV FNC IANA

This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1816 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1811
RFC1812 Requirements for IP Version 4 Routers F. Baker Editor June 1995 ASCII 415740 175 routing IPv4

This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]

RFC1716 RFC1009 RFC2644 RFC6633 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq http://www.rfc-editor.org/errata_search.php?rfc=1812 10.17487/RFC1812
RFC1813 NFS Version 3 Protocol Specification B. Callaghan B. Pawlowski P. Staubach June 1995 ASCII 229793 126 NFSV3

This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1094 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1813
RFC1814 Unique Addresses are Good E. Gerich June 1995 ASCII 5936 3 Internet Registries Protocol Private Network Numbers

The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1814
RFC1815 Character Sets ISO-10646 and ISO-10646-J-1 M. Ohta July 1995 ASCII 11823 6 Japanese Latin

For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary. This memo provides information on such profiling, along with charset names to each profiled instance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1815
RFC1816 U.S. Government Internet Domain Names Federal Networking Council August 1995 ASCII 17979 8 GOV FNC IANA

This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1811 RFC2146 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1816
RFC1817 CIDR and Classful Routing Y. Rekhter August 1995 ASCII 3416 2 Classless Inter Domain Routing

This document represents the IAB's (Internet Architecture Board) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC1817
RFC1818 Best Current Practices J. Postel T. Li Y. Rekhter August 1995 ASCII 4114 3 BCP

This document describes a new series of documents which describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering Steering Group (IESG).

HISTORIC BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=1818 10.17487/RFC1818
RFC1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+ L. Delgrossi L. Berger Editors August 1995 ASCII 266875 109 ST2

This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2). This memo defines an Experimental Protocol for the Internet community.

RFC1190 IEN119 EXPERIMENTAL EXPERIMENTAL IETF int st2 10.17487/RFC1819
RFC1820 Multimedia E-mail (MIME) User Agent Checklist E. Huizer August 1995 ASCII 14672 8 Multipurpose Internet Mail Extensions Media Types

This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1844 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1820
RFC1821 Integration of Real-time Services in an IP-ATM Network Architecture M. Borden E. Crawley B. Davie S. Batsell August 1995 ASCII 64466 24 Asynchronous Transfer Mode

The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1821
RFC1822 A Grant of Rights to Use a Specific IBM patent with Photuris J. Lowe August 1995 ASCII 2664 2 Internet Key Management Protocol IKMP IETF

This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1822
RFC1823 The LDAP Application Program Interface T. Howes M. Smith August 1995 ASCII 41081 22 lightweight directory access protocol API X.500

This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1823
RFC1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4) H. Danisch August 1995 ASCII 45540 21 TESS public keys

This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1824
RFC1825 Security Architecture for the Internet Protocol R. Atkinson August 1995 ASCII 56772 22 IPv4 IPv6 IP-layer ipsec

This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS-TRACK]

RFC2401 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1825
RFC1826 IP Authentication Header R. Atkinson August 1995 ASCII 27583 13 ipsec IPV6-AH Internet Protocol AH security IPv4 IPv6

This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]

RFC2402 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1826
RFC1827 IP Encapsulating Security Payload (ESP) R. Atkinson August 1995 ASCII 30278 12 ESP Internet Protocol IPv4 IPv6 ipsec

This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]

RFC2406 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1827
RFC1828 IP Authentication using Keyed MD5 P. Metzger W. Simpson August 1995 ASCII 9800 6 ipsec Internet Protocol Authentication Header AH Message Digest 5 Security

This document describes the use of keyed MD5 with the IP Authentication Header. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1828
RFC1829 The ESP DES-CBC Transform P. Karn P. Metzger W. Simpson August 1995 ASCII 19291 11 Encapsulating Security Payload US Data Encryption Standard Cipher Block Chaining IP Internet Protocol Security ipsec

This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1829
RFC1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages G. Vaudreuil August 1995 ASCII 16555 8 Simple Mail Transfer Multipurpose Mail Extensions

This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community.

RFC3030 EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1830
RFC1831 RPC: Remote Procedure Call Protocol Specification Version 2 R. Srinivasan August 1995 ASCII 37798 18 RPC] ONC Open Network Computing

This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

RFC5531 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1831
RFC1832 XDR: External Data Representation Standard R. Srinivasan August 1995 ASCII 47418 24 XDR RPC ONC Open Network Computing

This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

RFC4506 DRAFT STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1832
RFC1833 Binding Protocols for ONC RPC Version 2 R. Srinivasan August 1995 ASCII 24449 14 ONC Open Network Computing

This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]

RFC5665 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1833
RFC1834 Whois and Network Information Lookup Service, Whois++ J. Gargano K. Weiss August 1995 ASCII 14429 7 nicname TCP Transmission Control Protocol directory service server retrieval

This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF wnils 10.17487/RFC1834
RFC1835 Architecture of the WHOIS++ service P. Deutsch R. Schoultz P. Faltstrom C. Weider August 1995 ASCII 80581 41 WHOIS++ nicname TCP Transmission Control Protocol directory service server retrieval

This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1835
RFC1836 Representing the O/R Address hierarchy in the X.500 Directory Information Tree S. Kille August 1995 ASCII 20175 11 message handling

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This memo defines an Experimental Protocol for the Internet community.

RFC2294 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1836
RFC1837 Representing Tables and Subtrees in the X.500 Directory S. Kille August 1995 ASCII 10924 7 message handling

This document defines techniques for representing two types of information mapping in the OSI Directory. This memo defines an Experimental Protocol for the Internet community.

RFC2293 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1837
RFC1838 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses S. Kille August 1995 ASCII 12216 8 message handling

This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. This memo defines an Experimental Protocol for the Internet community.

RFC2164 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1838
RFC1839 RFC1840 RFC1841 PPP Network Control Protocol for LAN Extension J. Chapman D. Coli A. Harvey B. Jensen K. Rowett September 1995 ASCII 146206 66 point-to-point local area interface, INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1841 RFC1842 ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages Y. Wei Y. Zhang J. Li J. Ding Y. Jiang August 1995 ASCII 24143 12 electronic mail HZ-GB-2312

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informational RFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1842
RFC1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters F. Lee August 1995 ASCII 8787 5 GB2312-80 electronic mail

The content of this memo is identical to an article of the same title written by the author on September 4, 1989. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1843
RFC1844 Multimedia E-mail (MIME) User Agent Checklist E. Huizer August 1995 ASCII 15072 8 Multipurpose Internet Mail Extensions Media Types

This document presents a checklist to facilitate evaluation of MIME capable User Agents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1820 INFORMATIONAL INFORMATIONAL IETF app mailext 10.17487/RFC1844
RFC1845 SMTP Service Extension for Checkpoint/Restart D. Crocker N. Freed A. Cargille September 1995 ASCII 15399 7 simple mail transfer transaction EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1845 RFC1846 SMTP 521 Reply Code A. Durand F. Dupont September 1995 ASCII 6558 4 simple mail transfer RFC7504 EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1846 RFC1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted J. Galvin S. Murphy S. Crocker N. Freed October 1995 ASCII 23679 11 MIME-Encyp mail multipurpose extensions

This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community.

PROPOSED STANDARD PROPOSED STANDARD IETF sec pem 10.17487/RFC1847
RFC1848 MIME Object Security Services S. Crocker N. Freed J. Galvin S. Murphy October 1995 ASCII 95010 48 MIME-Sec mail multipurpose extensions

This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services to MIME objects. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1848
RFC1849 "Son of 1036": News Article Format and Transmission H. Spencer March 2010 ASCII 259422 106 netnews usenet rfc 1036 usefor historic

By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews.

It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. This document defines a Historic Document for the Internet community.

draft-spencer-usefor-son-of-1036-01 RFC5536 RFC5537 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC1849
RFC1850 OSPF Version 2 Management Information Base F. Baker R. Coltun November 1995 ASCII 140255 80 OSPF-MIB Open Shortest Path First SPF MIB routing network management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. [STANDARDS-TRACK]

RFC1253 RFC4750 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC1850
RFC1851 The ESP Triple DES Transform P. Karn P. Metzger W. Simpson September 1995 ASCII 20000 11 ESP3DES encryption encapsulating security payload cipher block chaining EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1851 RFC1852 IP Authentication using Keyed SHA P. Metzger W. Simpson September 1995 ASCII 9367 6 encryption secure hash algorithm RFC2841 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1852 RFC1853 IP in IP Tunneling W. Simpson October 1995 ASCII 14803 8 internet protocol payload encapsulation

This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols. This memo provides information for the Internet community. It does not specify an Internet standard. This document describes the use of keyed SHA with the IP Authentication Header. This document defines an Experimental Protocol for the Internet community. This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP). This document defines an Experimental Protocol for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1853
RFC1854 SMTP Service Extension for Command Pipelining N. Freed October 1995 ASCII 14097 7 simple mail transfer protocol

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]

RFC2197 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC1854
RFC1855 Netiquette Guidelines S. Hambridge October 1995 ASCII 46185 21 Network Etiquette

This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0028 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC1855
RFC1856 The Opstat Client-Server Model for Statistics Retrieval H. Clark September 1995 ASCII 29954 17 tools performance utilization INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1856 RFC1857 A Model for Common Operational Statistics M. Lambert October 1995 ASCII 55314 27 metrics measurements polling periods

This memo describes a model for operational statistics in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document defines a model and protocol for a set of tools which could be used by NSPs and Network Operation Centers (NOCs) to share data among themselves and with customers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1404 INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1857
RFC1858 Security Considerations for IP Fragment Filtering G. Ziemba D. Reed P. Traina October 1995 ASCII 20468 10 internet protocol tcp transmission control protocol routers hosts

IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC3128 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1858
RFC1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension Y. Pouffary October 1995 ASCII 14572 8 International Standard Organizatio

This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1859
RFC1860 Variable Length Subnet Table For IPv4 T. Pummill B. Manning October 1995 ASCII 5694 3 values IPv4 subnets

This document itemizes the potential values for IPv4 subnets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1878 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1860
RFC1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced A. Gwinn October 1995 ASCII 49181 23 SNPP SNPP wireless paging

This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1645 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1861
RFC1862 Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994 M. McCahill J. Romkey M. Schwartz K. Sollins T. Verschuren C. Weider November 1995 ASCII 62483 27 Internet Architecture Board

This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1862
RFC1863 A BGP/IDRP Route Server alternative to a full mesh routing D. Haskin October 1995 ASCII 37426 16 BGP-IDRP border gateway protocol inter-domain routing

This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers. This memo defines an Experimental Protocol for the Internet community.

RFC4223 HISTORIC EXPERIMENTAL IETF rtg idr 10.17487/RFC1863
RFC1864 The Content-MD5 Header Field J. Myers M. Rose October 1995 ASCII 7216 4 CON-MD5 MIME EMail Integrity MIC Digest

This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK]

RFC1544 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1864
RFC1865 EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet W. Houser J. Griffin C. Hage January 1996 ASCII 98361 41 FAQ

This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app edi 10.17487/RFC1865
RFC1866 Hypertext Markup Language - 2.0 T. Berners-Lee D. Connolly November 1995 ASCII 146904 77 HTML HTML SGML Standard Generalized Language WWW World Wide Web

This document defines a HTML 2.0 (to distinguish it from the previous informal specifications). [STANDARDS-TRACK]

RFC2854 HISTORIC PROPOSED STANDARD IETF app html 10.17487/RFC1866
RFC1867 Form-based File Upload in HTML E. Nebel L. Masinter November 1995 ASCII 26183 13 Hypertext Markup Language MIME Multipurpose Internet Mail Extensions

Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community.

RFC2854 HISTORIC EXPERIMENTAL IETF app html http://www.rfc-editor.org/errata_search.php?rfc=1867 10.17487/RFC1867
RFC1868 ARP Extension - UNARP G. Malkin November 1995 ASCII 7681 4 UNARP Address Resolution Protocol delete entry

This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1868
RFC1869 SMTP Service Extensions J. Klensin N. Freed M. Rose E. Stefferud D. Crocker November 1995 ASCII 23299 11 ESMTP Simple Mail Transfer Protocol

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

RFC1651 RFC2821 STD0010 INTERNET STANDARD INTERNET STANDARD IETF app smtpext 10.17487/RFC1869
RFC1870 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed K. Moore November 1995 ASCII 18226 9 SMTP-SIZE Simple Mail Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

RFC1653 STD0010 INTERNET STANDARD INTERNET STANDARD IETF app smtpext 10.17487/RFC1870
RFC1871 Addendum to RFC 1602 -- Variance Procedure J. Postel November 1995 ASCII 7747 4 BCP WG escape clause procedures

This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2026 RFC1602 RFC1603 HISTORIC BEST CURRENT PRACTICE Legacy 10.17487/RFC1871
RFC1872 The MIME Multipart/Related Content-type E. Levinson December 1995 ASCII 15565 8 multipurpose Internet Mail Extensions

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. This memo defines an Experimental Protocol for the Internet community.

RFC2112 EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1872
RFC1873 Message/External-Body Content-ID Access Type E. Levinson December 1995 ASCII 5878 4 CONT-MT Multipurpose Internet Mail Extensions

The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1873
RFC1874 SGML Media Types E. Levinson December 1995 ASCII 12515 6 SGML-MT Multipurpose Internet Mail Extensions

This document proposes new media sub-types of Text/SGML and Application/SGML. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1874
RFC1875 UNINETT PCA Policy Statements N. Berge December 1995 ASCII 19089 10 Policy Certification Authority Encryption

This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1875
RFC1876 A Means for Expressing Location Information in the Domain Name System C. Davis P. Vixie T. Goodwin I. Dickinson January 1996 ASCII 29631 18 DNS-LOC DNS Resource Record (RR) LOC

This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community.

RFC1034 RFC1035 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1876
RFC1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses S. Cobb December 1995 ASCII 10591 6 Point-to-Point Protocol Network Control Domain System NetBIOS

This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1877
RFC1878 Variable Length Subnet Table For IPv4 T. Pummill B. Manning December 1995 ASCII 19414 8 values IPv4 subnets

This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1860 HISTORIC INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1878 10.17487/RFC1878
RFC1879 Class A Subnet Experiment Results and Recommendations B. Manning Editor January 1996 ASCII 10589 6 Internet Registry Operations

This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1879
RFC1880 Internet Official Protocol Standards J. Postel Editor November 1995 ASCII 89153 38 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1800 RFC1920 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1880
RFC1881 IPv6 Address Allocation Management IAB IESG December 1995 ASCII 3215 2 IANA Internet Assigned Numbers Authority

The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1881
RFC1882 The 12-Days of Technology Before Christmas B. Hancock December 1995 ASCII 9130 5

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1882
RFC1883 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden December 1995 ASCII 82089 37 IP Next Generation IPng

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]

RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1883
RFC1884 IP Version 6 Addressing Architecture R. Hinden Editor S. Deering Editor December 1995 ASCII 37860 18 IPV6-Addr IP Next Generation IPng

This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]

RFC2373 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1884
RFC1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) A. Conta S. Deering December 1995 ASCII 32214 20 IP Next Generation IPng Internet Group Management IGMP

This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

RFC2463 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1885
RFC1886 DNS Extensions to support IP version 6 S. Thomson C. Huitema December 1995 ASCII 6424 5 DNS-IPV6 IP Next Generation IPng Domain Name System

This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). [STANDARDS-TRACK]

RFC3596 RFC2874 RFC3152 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1886
RFC1887 An Architecture for IPv6 Unicast Address Allocation Y. Rekhter T. Li Editors December 1995 ASCII 66066 26 IP Next Generation IPng,

This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC1887
RFC1888 OSI NSAPs and IPv6 J. Bound B. Carpenter D. Harrington J. Houldsworth A. Lloyd August 1996 ASCII 36469 16 Internet Protocol Open Systems Interconnection

This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. This memo defines an Experimental Protocol for the Internet community.

RFC4048 RFC4548 HISTORIC EXPERIMENTAL IETF int ipngwg 10.17487/RFC1888
RFC1889 RTP: A Transport Protocol for Real-Time Applications Audio-Video Transport Working Group H. Schulzrinne S. Casner R. Frederick V. Jacobson January 1996 ASCII 188544 75 RTP end-to-end network audio video RTCP

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. [STANDARDS-TRACK]

RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC1889
RFC1890 RTP Profile for Audio and Video Conferences with Minimal Control Audio-Video Transport Working Group H. Schulzrinne January 1996 ASCII 37509 18 RTP-AV end-to-end network conference

This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. [STANDARDS-TRACK]

RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC1890
RFC1891 SMTP Service Extension for Delivery Status Notifications K. Moore January 1996 ASCII 65192 31 SMTP-DSN simple mail transfer protocol

This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

RFC3461 PROPOSED STANDARD PROPOSED STANDARD IETF app notary http://www.rfc-editor.org/errata_search.php?rfc=1891 10.17487/RFC1891
RFC1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages G. Vaudreuil January 1996 ASCII 7800 4 MIME-RPT Multipurpose Internet Mail Extensions

The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK]

RFC3462 PROPOSED STANDARD PROPOSED STANDARD IETF app notary 10.17487/RFC1892
RFC1893 Enhanced Mail System Status Codes G. Vaudreuil January 1996 ASCII 28218 15 EMS-CODE simple mail transfer protocol SMTP

There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]

RFC3463 PROPOSED STANDARD PROPOSED STANDARD IETF app notary 10.17487/RFC1893
RFC1894 An Extensible Message Format for Delivery Status Notifications K. Moore G. Vaudreuil January 1996 ASCII 77462 39 DSN Multipurpose Internet Mail Extensions Content Type

This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. [STANDARDS-TRACK]

RFC3464 RFC2852 PROPOSED STANDARD PROPOSED STANDARD IETF app notary http://www.rfc-editor.org/errata_search.php?rfc=1894 10.17487/RFC1894
RFC1895 The Application/CALS-1840 Content-type E. Levinson February 1996 ASCII 10576 6 MIL-STD-1840 MIME Multipurpose Internet Mail Extensions

This memorandum provides guidelines for using the United States Department of Defense Military Standard MIL-STD-1840, "Automated Interchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1895
RFC1896 The text/enriched MIME Content-type P. Resnick A. Walker February 1996 ASCII 45926 21 PS 81217 MIME Multipurpose Internet Mail Extensions

This document defines one particular type of MIME data, the text/enriched MIME type. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1523 RFC1563 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1896
RFC1897 IPv6 Testing Address Allocation R. Hinden J. Postel January 1996 ASCII 6643 4 Internet Protocol prototype software

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community.

RFC2471 EXPERIMENTAL EXPERIMENTAL IETF int ipngwg 10.17487/RFC1897
RFC1898 CyberCash Credit Card Protocol Version 0.8 D. Eastlake 3rd B. Boesch S. Crocker M. Yesil February 1996 ASCII 113633 52 general payments system

This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1898
RFC1899 Request for Comments Summary RFC Numbers 1800-1899 J. Elliott January 1997 ASCII 37984 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1899 RFC1900 Renumbering Needs Work B. Carpenter Y. Rekhter February 1996 ASCII 9528 4 IP network number addressing

Hosts in an IP network are identified by IP addresses, and the IP address prefixes of subnets are advertised by routing protocols. A change in such IP addressing information associated with a host or subnet is known as "renumbering". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1900
RFC1901 Introduction to Community-based SNMPv2 J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 15903 8 SNMPV2CB Simple Network Management Protocol Version 2

The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community.

HISTORIC EXPERIMENTAL IETF snmpv2 10.17487/RFC1901
RFC1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 77453 40 Simple Network Management Protocol Version 2

It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

RFC1442 RFC2578 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1902
RFC1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 52652 23 Simple Network Management Protocol Version 2

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

RFC1443 RFC2579 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1903
RFC1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 47083 24 Simple Network Management Protocol Version 2

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

RFC1444 RFC2580 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1904
RFC1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 55526 24 OPS-MIB Simple Network Management Protocol Version 2

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

RFC1448 RFC3416 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1905
RFC1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 27465 13 TRANS-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

RFC1449 RFC3417 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1906
RFC1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 34881 20 SNMPv2-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

RFC1450 RFC3418 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1907
RFC1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII 21463 10 COEX-MIB Simple Network Management Protocol Version 2

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

RFC1452 RFC2576 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1908
RFC1909 An Administrative Infrastructure for SNMPv2 K. McCloghrie Editor February 1996 ASCII 45773 19 SNMPV2AI Simple Network Management Protocol Version 2

It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community.

HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1909
RFC1910 User-based Security Model for SNMPv2 G. Waters Editor February 1996 ASCII 98252 44 SNMPV2SM Simple Network Management Protocol Version 2

In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community.

HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1910
RFC1911 Voice Profile for Internet Mail G. Vaudreuil February 1996 ASCII 50242 22 MIME Multipurpose Internet Mail Extensions ESMTP SMTP Service Extensions

The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community.

RFC2421 RFC2422 RFC2423 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1911
RFC1912 Common DNS Operational and Configuration Errors D. Barr February 1996 ASCII 38252 16 Domain Name System

This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1537 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1912
RFC1913 Architecture of the Whois++ Index Service C. Weider J. Fullton S. Spero February 1996 ASCII 33743 16 WHOIS++A Bunyip Information Systems Inc. MCNC Center for Communications

The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1913
RFC1914 How to Interact with a Whois++ Mesh P. Faltstrom R. Schoultz C. Weider February 1996 ASCII 17842 10 WHOIS++M distributed databases directory service

In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1914
RFC1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol F. Kastenholz February 1996 ASCII 14347 7 Point to Point Protocol

The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0003 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=1915 10.17487/RFC1915
RFC1916 Enterprise Renumbering: Experience and Information Solicitation H. Berkowitz P. Ferguson W. Leland P. Nesser February 1996 ASCII 16117 8 tools applications

Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC1916
RFC1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA P. Nesser II February 1996 ASCII 23623 10 address space Internet Assigned Numbers Authority IANA

This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0004 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd 10.17487/RFC1917
RFC1918 Address Allocation for Private Internets Y. Rekhter B. Moskowitz D. Karrenberg G. J. de Groot E. Lear February 1996 ASCII 22270 9 TCP/IP network host

This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1627 RFC1597 RFC6761 BCP0005 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd http://www.rfc-editor.org/errata_search.php?rfc=1918 10.17487/RFC1918
RFC1919 Classical versus Transparent IP Proxies M. Chatel March 1996 ASCII 87374 35 firewalls security

This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1919
RFC1920 Internet Official Protocol Standards J. Postel March 1996 ASCII 91936 40 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1880 RFC2000 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1920
RFC1921 TNVIP Protocol J. Dujonc March 1996 ASCII 57475 30

The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1921
RFC1922 Chinese Character Encoding for Internet Messages HF. Zhu DY. Hu ZG. Wang TC. Kao WCH. Chang M. Crispin March 1996 ASCII 50995 27 transport electronic mail telnet WWW

This memo describes methods of transporting Chinese characters in Internet services which transport text, such as electronic mail [RFC-822], network news [RFC-1036], telnet [RFC-854] and the World Wide Web [RFC-1866]. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1922
RFC1923 RIPv1 Applicability Statement for Historic Status J. Halpern S. Bradner March 1996 ASCII 5560 3 Routing Information Protocol

RIP Version 1 [RFC-1058] has been declared an historic document. This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is the Classful nature of RIPv1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg rip 10.17487/RFC1923
RFC1924 A Compact Representation of IPv6 Addresses R. Elz April 1 1996 ASCII 10409 6 encoding

This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1924
RFC1925 The Twelve Networking Truths R. Callon April 1 1996 ASCII 4294 3 fundamentals

This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1925 10.17487/RFC1925
RFC1926 An Experimental Encapsulation of IP Datagrams on Top of ATM J. Eriksson April 1 1996 ASCII 2969 2 Acoustical Transmission Media (ATM)

This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1926
RFC1927 Suggested Additional MIME Types for Associating Documents C. Rogers April 1 1996 ASCII 5254 3 media-type

Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1927 10.17487/RFC1927
RFC1928 SOCKS Protocol Version 5 M. Leech M. Ganis Y. Lee R. Kuris D. Koblas L. Jones March 1996 ASCII 19741 9 SOCKSV5 firewalls authentication

This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec aft http://www.rfc-editor.org/errata_search.php?rfc=1928 10.17487/RFC1928
RFC1929 Username/Password Authentication for SOCKS V5 M. Leech March 1996 ASCII 3568 2 AUTH-SOCKS firewalls authentication

The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec aft 10.17487/RFC1929
RFC1930 Guidelines for creation, selection, and registration of an Autonomous System (AS) J. Hawkinson T. Bates March 1996 ASCII 22073 10 routing policy Exterior Gateway Protocol Border Inter-Domain Domain Identifier EGP BGP IDRP

This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC6996 RFC7300 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC1930
RFC1931 Dynamic RARP Extensions for Automatic Network Address Acquisition D. Brownell April 1996 ASCII 27544 11 Reverse Address Resolution Protocol

This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1931
RFC1932 IP over ATM: A Framework Document R. Cole D. Shur C. Villamizar April 1996 ASCII 68031 31 end-to-end connectivity

It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ipatm 10.17487/RFC1932
RFC1933 Transition Mechanisms for IPv6 Hosts and Routers R. Gilligan E. Nordmark April 1996 ASCII 47005 22 TRANS-IPV6 IPv4

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]

RFC2893 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC1933
RFC1934 Ascend's Multilink Protocol Plus (MP+) K. Smith April 1996 ASCII 87072 47 PPP

This document proposes an extension to the PPP Multilink Protocol (MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1934
RFC1935 What is the Internet, Anyway? J. Quarterman S. Carl-Mitchell April 1996 ASCII 30369 11 information tutorial

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1935
RFC1936 Implementing the Internet Checksum in Hardware J. Touch B. Parham April 1996 ASCII 36618 21 PLD code UDP TCP

This memo presents a techniques for efficiently implementing the Internet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1936 10.17487/RFC1936
RFC1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks Y. Rekhter D. Kandlur May 1996 ASCII 18302 8 IP subnet

This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg rolc 10.17487/RFC1937
RFC1938 A One-Time Password System N. Haller C. Metz May 1996 ASCII 44844 18 OTP authentication S/KEY

This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]

RFC2289 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC1938
RFC1939 Post Office Protocol - Version 3 J. Myers M. Rose May 1996 ASCII 47018 23 POP3 POP3

The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]

RFC1725 RFC1957 RFC2449 RFC6186 STD0053 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1939 10.17487/RFC1939
RFC1940 Source Demand Routing: Packet Format and Forwarding Specification (Version 1) D. Estrin T. Li Y. Rekhter K. Varadhan D. Zappala May 1996 ASCII 60858 27 SDRP

The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg sdr 10.17487/RFC1940
RFC1941 Frequently Asked Questions for Schools J. Sellers J. Robichaux May 1996 ASCII 150980 70 FAQ Internet Education

The goal of this FYI document, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to act as an introduction to the Internet for faculty, administration, and other school personnel in primary and secondary schools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1578 FYI0022 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1941
RFC1942 HTML Tables D. Raggett May 1996 ASCII 68705 30 HTML-TBL HyperText Markup Language SGML

This specification extends HTML to support a wide variety of tables. This memo defines an Experimental Protocol for the Internet community.

RFC2854 HISTORIC EXPERIMENTAL IETF app html 10.17487/RFC1942
RFC1943 Building an X.500 Directory Service in the US B. Jennings May 1996 ASCII 51266 22 White Pages

This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the United States. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1943
RFC1944 Benchmarking Methodology for Network Interconnect Devices S. Bradner J. McQuaid May 1996 ASCII 66061 30 testing performance

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC1944
RFC1945 Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee R. Fielding H. Frystyk May 1996 ASCII 137582 60 HTTP-1.0 HTTP World-Wide Web application

The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app http 10.17487/RFC1945
RFC1946 Native ATM Support for ST2+ S. Jackowski May 1996 ASCII 50430 21 integrated services ATM Quality of Service QoS

This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments: ATM to internet, internet to ATM, and internet to internet across ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1946
RFC1947 Greek Character Encoding for Electronic Mail Messages D. Spinellis May 1996 ASCII 14428 7 character set ISO MIME

This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1947
RFC1948 Defending Against Sequence Number Attacks S. Bellovin May 1996 ASCII 13074 6 crypgraphic authentication spoofing

IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC6528 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1948 10.17487/RFC1948
RFC1949 Scalable Multicast Key Distribution A. Ballardie May 1996 ASCII 41853 18 SMKD MBONE security authentication

This memo provides a scalable solution to the multicast key distribution problem. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC1949
RFC1950 ZLIB Compressed Data Format Specification version 3.3 P. Deutsch J-L. Gailly May 1996 ASCII 20502 11 PS 37768 PDF 36393 ZLIB compressed data format checksum

This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1950
RFC1951 DEFLATE Compressed Data Format Specification version 1.3 P. Deutsch May 1996 ASCII 36944 17 PS 57408 PDF 56620 DEFLATE compressed data format coding

This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1951
RFC1952 GZIP file format specification version 4.3 P. Deutsch May 1996 ASCII 25036 12 PS 43337 PDF 43211 GZIP compressed data format redundancy check

This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1952
RFC1953 Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall May 1996 ASCII 43749 20 IFMP IP flow routing information

The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1953
RFC1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall May 1996 ASCII 16075 8 datagrams IFMP

This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP]. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1954
RFC1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG R. Hinden June 1996 ASCII 10115 5 IPNG addressing routing

This paper proposes a new scheme which I believe is a good medium term solution to the routing and address problems of the internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1955
RFC1956 Registration in the MIL Domain D. Engebretson R. Plzak June 1996 ASCII 2923 2 DoD Department of Defense

This RFC describes the policy for the registration of second level domains under the ".MIL" domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1956
RFC1957 Some Observations on Implementations of the Post Office Protocol (POP3) R. Nelson June 1996 ASCII 2325 2 client server

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1939 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1957
RFC1958 Architectural Principles of the Internet B. Carpenter Editor June 1996 ASCII 17345 8 IAB

The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC3439 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1958
RFC1959 An LDAP URL Format T. Howes M. Smith June 1996 ASCII 7243 4 LDAP-URL Lightweight Directory Access Protocol Uniform Resource Locator

This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]

RFC2255 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=1959 10.17487/RFC1959
RFC1960 A String Representation of LDAP Search Filters T. Howes June 1996 ASCII 5288 3 LDAP-STR Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]

RFC1558 RFC2254 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC1960
RFC1961 GSS-API Authentication Method for SOCKS Version 5 P. McMahon June 1996 ASCII 16036 9 GSSAPI-SOC Generic Security Service Application Program Interface

This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec aft 10.17487/RFC1961
RFC1962 The PPP Compression Control Protocol (CCP) D. Rand June 1996 ASCII 18005 9 PPP-CCP point-to-point protocol data links

This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK]

RFC2153 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1962
RFC1963 PPP Serial Data Transport Protocol (SDTP) K. Schneider S. Venters August 1996 ASCII 38185 20 Point-to-Point Protocol

This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1963
RFC1964 The Kerberos Version 5 GSS-API Mechanism J. Linn June 1996 ASCII 47413 20 GSSAPI-KER Generic Security Service Application Program Interface

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS-TRACK]

RFC4121 RFC6649 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1964
RFC1965 Autonomous System Confederations for BGP P. Traina June 1996 ASCII 13575 7 BGP-ASC Border Gateway Protocol

This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation. This memo defines an Experimental Protocol for the Internet community.

RFC3065 EXPERIMENTAL EXPERIMENTAL IETF rtg idr 10.17487/RFC1965
RFC1966 BGP Route Reflection An alternative to full mesh IBGP T. Bates R. Chandra June 1996 ASCII 14320 7 BGP-RR Border Gateway Protocol autonomous system

This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. This memo defines an Experimental Protocol for the Internet community.

RFC4456 RFC2796 EXPERIMENTAL EXPERIMENTAL IETF rtg idr 10.17487/RFC1966
RFC1967 PPP LZS-DCP Compression Protocol (LZS-DCP) K. Schneider R. Friend August 1996 ASCII 40039 18 Point-to-Point Protocol Compression Control CCP

This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1967
RFC1968 The PPP Encryption Control Protocol (ECP) G. Meyer June 1996 ASCII 20781 11 PPP-ECP Point-to-Point Protocol data

This document defines a method for negotiating data encryption over PPP links. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1968
RFC1969 The PPP DES Encryption Protocol (DESE) K. Sklower G. Meyer June 1996 ASCII 20383 10 Point-to-Point Protocol encapsulated packets

This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2419 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1969
RFC1970 Neighbor Discovery for IP Version 6 (IPv6) T. Narten E. Nordmark W. Simpson August 1996 ASCII 197632 82 Internet Protocol

This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]

RFC2461 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1970
RFC1971 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten August 1996 ASCII 56890 23 Internet Protocol link-local address Duplicate Address Detection procedure

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]

RFC2462 PROPOSED STANDARD PROPOSED STANDARD IETF int addrconf 10.17487/RFC1971
RFC1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks M. Crawford August 1996 ASCII 6353 4 IPV6-ETHER Internet Protocol frame format transmission

This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]

RFC2464 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1972
RFC1973 PPP in Frame Relay W. Simpson June 1996 ASCII 14780 10 PPP-FRAME Point-to-Point Protocol encapsulated packets

This document describes the use of Frame Relay for framing PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1973
RFC1974 PPP Stac LZS Compression Protocol R. Friend W. Simpson August 1996 ASCII 45267 20 PPP-STAC Point-to-Point Protocol Compression Control CCP

This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1974
RFC1975 PPP Magnalink Variable Resource Compression D. Schremp J. Black J. Weiss August 1996 ASCII 8655 6 PPP-MAG Point-to-Point Protocol MVRCA

The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1975
RFC1976 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) K. Schneider S. Venters August 1996 ASCII 19781 10 PPP-DCE Point-to-Point Protocol LCP extension

This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1976
RFC1977 PPP BSD Compression Protocol V. Schryver August 1996 ASCII 50747 25 PPP-BSD Point-to-Point Protocol Unix Compress

This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1977
RFC1978 PPP Predictor Compression Protocol D. Rand August 1996 ASCII 17424 9 PPP-PRED Point-to-Point Protocol

This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1978
RFC1979 PPP Deflate Protocol J. Woods August 1996 ASCII 18803 10 PPP-DEFL Point-to-Point Protocol Compression Control

This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1979 10.17487/RFC1979
RFC1980 A Proposed Extension to HTML : Client-Side Image Maps J. Seidman August 1996 ASCII 13448 7 HyperText Markup Language Uniform Identifier URI

The markup language known as "HTML/2.0" provides for image maps. Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified by Uniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client- Side Image Maps," which resolves these limitations.

RFC2854 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1980
RFC1981 Path MTU Discovery for IP version 6 J. McCann S. Deering J. Mogul August 1996 ASCII 34088 15 MTU-IPV6 Internet Protocol

This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. [STANDARDS-TRACK]

DRAFT STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=1981 10.17487/RFC1981
RFC1982 Serial Number Arithmetic R. Elz R. Bush August 1996 ASCII 14440 6 SNA domain name system DNS

The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK]

RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC1982
RFC1983 Internet Users' Glossary G. Malkin Editor August 1996 ASCII 123008 62 basic terms acronyms

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1392 FYI0018 INFORMATIONAL INFORMATIONAL IETF userglos 10.17487/RFC1983
RFC1984 IAB and IESG Statement on Cryptographic Technology and the Internet IAB IESG August 1996 ASCII 10738 5 security privacy

The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1984
RFC1985 SMTP Service Extension for Remote Message Queue Starting J. De Winter August 1996 ASCII 14815 7 SMTP-ETRN Simple ETRN Mail Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1985 10.17487/RFC1985
RFC1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP) W. Polites W. Wollman D. Woo R. Langan August 1996 ASCII 49772 21 ETFTP TFTP NETBLT

This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1986
RFC1987 Ipsilon's General Switch Management Protocol Specification Version 1.1 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall August 1996 ASCII 105821 44 GSMP ATM switch

The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2297 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1987
RFC1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework G. McAnally D. Gilbert J. Flick August 1996 ASCII 3821 2 HP

This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1988
RFC1989 PPP Link Quality Monitoring W. Simpson August 1996 ASCII 29289 16 PPP-LINK Point-to-Point Protocol

This document defines a protocol for generating Link-Quality-Reports. [STANDARDS-TRACK]

RFC1333 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1989
RFC1990 The PPP Multilink Protocol (MP) K. Sklower B. Lloyd G. McGregor D. Carr T. Coradetti August 1996 ASCII 53271 24 PPP-MP Point-to-Point Protocol datagrams

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]

RFC1717 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1990
RFC1991 PGP Message Exchange Formats D. Atkins W. Stallings P. Zimmermann August 1996 ASCII 46255 21 PGP-MEF Pretty Good Privacy encryption electronic mail

This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC4880 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1991
RFC1992 The Nimrod Routing Architecture I. Castineyra N. Chiappa M. Steenstrup August 1996 ASCII 59848 27 scalable internetwork

Nimrod is a scalable routing architecture designed to accommodate a continually expanding and diversifying internetwork. First suggested by Noel Chiappa, the Nimrod architecture has undergone revision and refinement through the efforts of the Nimrod working group of the IETF. In this document, we present a detailed description of this architecture. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC1992
RFC1993 PPP Gandalf FZA Compression Protocol A. Barbir D. Carr W. Simpson August 1996 ASCII 9811 7 Point-to-Point Protocol

This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1993
RFC1994 PPP Challenge Handshake Authentication Protocol (CHAP) W. Simpson August 1996 ASCII 24094 13 PPP-CHAP Point-to-Point Protocol cryptology

This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. [STANDARDS-TRACK]

RFC1334 RFC2484 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1994
RFC1995 Incremental Zone Transfer in DNS M. Ohta August 1996 ASCII 16810 8 DNS-IZT Domain Name System IXFR

This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK]

RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=1995 10.17487/RFC1995
RFC1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) P. Vixie August 1996 ASCII 15247 7 DNS-NOTIFY Domain Name System

This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]

RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC1996
RFC1997 BGP Communities Attribute R. Chandra P. Traina T. Li August 1996 ASCII 8275 5 BGP-COMM Border Gateway Protocol

This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=1997 10.17487/RFC1997
RFC1998 An Application of the BGP Community Attribute in Multi-home Routing E. Chen T. Bates August 1996 ASCII 16953 9 Border Gateway Protocol

This document presents an application of the BGP community attribute [2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1998
RFC1999 Request for Comments Summary RFC Numbers 1900-1999 J. Elliott January 1997 ASCII 39819 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1999 RFC2000 Internet Official Protocol Standards J. Postel Editor February 1997 ASCII 121356 56 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard.

RFC1920 RFC2200 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2000
RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms W. Stevens January 1997 ASCII 12981 6 TCPSLOWSRT Transmission Control Protocol

Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [STANDARDS-TRACK]

RFC2581 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2001
RFC2002 IP Mobility Support C. Perkins Editor October 1996 ASCII 193103 79 MOBILEIPSUPIP Internet Protocol

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. [STANDARDS-TRACK]

RFC3220 RFC2290 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2002
RFC2003 IP Encapsulation within IP C. Perkins October 1996 ASCII 30291 14 IPENCAPIP Internet Protocol

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]

RFC3168 RFC6864 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2003 10.17487/RFC2003
RFC2004 Minimal Encapsulation within IP C. Perkins October 1996 ASCII 12202 6 MINI-IP Internet Protocol

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2004 10.17487/RFC2004
RFC2005 Applicability Statement for IP Mobility Support J. Solomon October 1996 ASCII 10509 5 Internet Protocol

As required by [RFC 1264], this report discusses the applicability of Mobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2005
RFC2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2 D. Cong M. Hamlen C. Perkins October 1996 ASCII 95030 52 MOBILEIPMIB Mobile Internet Protocol MIB Managed Information Base

This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2006
RFC2007 Catalogue of Network Training Materials J. Foster M. Isaacs M. Prior October 1996 ASCII 78941 55 TRAINMAT IETF TERENA

The purpose of this document is to provide a catalogue of quality Network Training Materials for use by Internet trainers in training their users. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0029 INFORMATIONAL INFORMATIONAL IETF trainmat 10.17487/RFC2007
RFC2008 Implications of Various Address Allocation Policies for Internet Routing Y. Rekhter T. Li October 1996 ASCII 34717 13 IP unicast

The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0007 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd 10.17487/RFC2008
RFC2009 GPS-Based Addressing and Routing T. Imielinski J. Navas November 1996 ASCII 66229 27 GPS-AR domain names geographic

This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2009
RFC2010 Operational Criteria for Root Name Servers B. Manning P. Vixie October 1996 ASCII 14870 7 host hardware

This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2870 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2010
RFC2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII 31168 18 MIB-IP IP Simple Network Management Protocol MIB

This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK]

RFC4293 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2011
RFC2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII 16792 10 MIB-TCP TCP Simple Network Management Protocol MIB

This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]

RFC4022 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2012
RFC2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII 9333 6 MIB-UDP] Simple Network Management Protocol MIB UDP

This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]

RFC4113 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2013
RFC2014 IRTF Research Group Guidelines and Procedures A. Weinrib J. Postel October 1996 ASCII 27507 13 Internet Research Task Force

This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0008 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2014
RFC2015 MIME Security with Pretty Good Privacy (PGP) M. Elkins October 1996 ASCII 14223 8 MIME-PGP Authentication Encryption

This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847. [STANDARDS-TRACK]

RFC3156 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2015 10.17487/RFC2015
RFC2016 Uniform Resource Agents (URAs) L. Daigle P. Deutsch B. Heelan C. Alpaugh M. Maclachlan October 1996 ASCII 38355 21 URAS

This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2016
RFC2017 Definition of the URL MIME External-Body Access-Type N. Freed K. Moore A. Cargille October 1996 ASCII 9000 5 URL-ACC Uniform Resource Locators Multipurpose Internet Message Extensions

This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC2017
RFC2018 TCP Selective Acknowledgment Options M. Mathis J. Mahdavi S. Floyd A. Romanow October 1996 ASCII 25671 12 TCP-ACK Transmission Control Protocol SACK

This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]

RFC1072 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcplw http://www.rfc-editor.org/errata_search.php?rfc=2018 10.17487/RFC2018
RFC2019 Transmission of IPv6 Packets Over FDDI M. Crawford October 1996 ASCII 12344 6 IPV6-FDDI frame format Fiber Distributed Data Interface

This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK]

RFC2467 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2019
RFC2020 IEEE 802.12 Interface MIB J. Flick October 1996 ASCII 72135 31 802.12-MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2020
RFC2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2 S. Waldbusser January 1997 ASCII 262223 130 RMON-MIB RMON MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

RFC4502 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=2021 10.17487/RFC2021
RFC2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks G. Armitage November 1996 ASCII 189219 82 MULTI-UNI Asynchronous Transfer Mode

This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC2022
RFC2023 IP Version 6 over PPP D. Haskin E. Allen October 1996 ASCII 20275 10 IPV6-PPP Internet Protocol Point IPv6

This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. [STANDARDS-TRACK]

RFC2472 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2023
RFC2024 Definitions of Managed Objects for Data Link Switching using SMIv2 D. Chen Editor P. Gayek S. Nix October 1996 ASCII 173952 90 DLSW-MIB MIB DLSW Management Information Base

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg dlswmib 10.17487/RFC2024
RFC2025 The Simple Public-Key GSS-API Mechanism (SPKM) C. Adams October 1996 ASCII 101692 45 SPKM

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2025
RFC2026 The Internet Standards Process -- Revision 3 S. Bradner October 1996 ASCII 86731 36 Protocols copyrights intellectual property

This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1602 RFC1871 RFC3667 RFC3668 RFC3932 RFC3979 RFC3978 RFC5378 RFC5657 RFC5742 RFC6410 RFC7100 RFC7127 RFC7475 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen poised95 http://www.rfc-editor.org/errata_search.php?rfc=2026 10.17487/RFC2026
RFC2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin October 1996 ASCII 24207 11 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2282 INFORMATIONAL BEST CURRENT PRACTICE IETF gen poised95 10.17487/RFC2027
RFC2028 The Organizations Involved in the IETF Standards Process R. Hovey S. Bradner October 1996 ASCII 13865 7 Internet Engineering Task Force

This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC3668 RFC3979 BCP0011 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen poised95 http://www.rfc-editor.org/errata_search.php?rfc=2028 10.17487/RFC2028
RFC2029 RTP Payload Format of Sun's CellB Video Encoding M. Speer D. Hoffman October 1996 ASCII 11216 6 RTP-CELLB Real Time Transport Protocol

This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2029
RFC2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI D. Mills October 1996 ASCII 48620 18 NTP SNTP time computer clock synchronization

This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1769 RFC4330 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2030 10.17487/RFC2030
RFC2031 IETF-ISOC relationship E. Huizer October 1996 ASCII 8816 4 Internet Society Engineering Task Force

This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF gen poised95 10.17487/RFC2031
RFC2032 RTP Payload Format for H.261 Video Streams T. Turletti C. Huitema October 1996 ASCII 27488 11 RTP-H.261 Real Time Transport Protocol

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK]

RFC4587 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2032
RFC2033 Local Mail Transfer Protocol J. Myers October 1996 ASCII 14711 7 LMTP SMTP Simple Mail Transfer Protocol

SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2033
RFC2034 SMTP Service Extension for Returning Enhanced Error Codes N. Freed October 1996 ASCII 10460 6 SMTP-ENH Simple Mail Transfer Protocol

This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2034
RFC2035 RTP Payload Format for JPEG-compressed Video L. Berc W. Fenner R. Frederick S. McCanne October 1996 ASCII 30079 16 RTP-JPEG Real Time Transport Protocol Joint Photographic Experts Group

This memo describes the RTP payload format for JPEG video streams. The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. [STANDARDS-TRACK]

RFC2435 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2035
RFC2036 Observations on the use of Components of the Class A Address Space within the Internet G. Huston October 1996 ASCII 20743 9 Internet Assigned Numbers Authority IANA

This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of the Class A address space to registries, for deployment within the Internet as class-less address blocks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL IETF cidrd 10.17487/RFC2036
RFC2037 Entity MIB using SMIv2 K. McCloghrie A. Bierman October 1996 ASCII 74362 35 ENTITY-MIB Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]

RFC2737 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib 10.17487/RFC2037
RFC2038 RTP Payload Format for MPEG1/MPEG2 Video D. Hoffman G. Fernando V. Goyal October 1996 ASCII 23266 11 Real Time Transport Protocol

This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. [STANDARDS-TRACK]

RFC2250 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2038
RFC2039 Applicability of Standards Track MIBs to Management of World Wide Web Servers C. Kalbfleisch November 1996 ASCII 31966 14 Management Information Base HTTP

This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2039
RFC2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms R. Baldwin R. Rivest October 1996 ASCII 54598 29 RC5 Cipher Block Chaining CBC

This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2040 10.17487/RFC2040
RFC2041 Mobile Network Tracing B. Noble G. Nguyen M. Satyanarayanan R. Katz October 1996 ASCII 64688 27 IP Internet Protocol

This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2041
RFC2042 Registering New BGP Attribute Types B. Manning January 1997 ASCII 4001 3 Border Gateway Protocol

This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2042 10.17487/RFC2042
RFC2043 The PPP SNA Control Protocol (SNACP) A. Fuqua October 1996 ASCII 13719 7 PPP-SNACP Point-to-point protocol systems network architecture

This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2043
RFC2044 UTF-8, a transformation format of Unicode and ISO 10646 F. Yergeau October 1996 ASCII 11932 6 UCS Transformation Format

The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2279 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2044
RFC2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies N. Freed N. Borenstein November 1996 ASCII 72932 31 MIME media types headers

This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]

RFC1521 RFC1522 RFC1590 RFC2184 RFC2231 RFC5335 RFC6532 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2045 10.17487/RFC2045
RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types N. Freed N. Borenstein November 1996 ASCII 105854 44 MIME-MEDIA headers structure

This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]

RFC1521 RFC1522 RFC1590 RFC2646 RFC3798 RFC5147 RFC6657 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2046 10.17487/RFC2046
RFC2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text K. Moore November 1996 ASCII 33262 15 MIME-MSG media type

This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. [STANDARDS-TRACK]

RFC1521 RFC1522 RFC1590 RFC2184 RFC2231 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2047 10.17487/RFC2047
RFC2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed J. Klensin J. Postel November 1996 ASCII 45033 21 media types external body access content-transfer-encodings

This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fourth document, RFC 2048, specifies various IANA registration procedures for some MIME facilities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1521 RFC1522 RFC1590 RFC4288 RFC4289 RFC3023 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app 822ext 10.17487/RFC2048
RFC2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples N. Freed N. Borenstein November 1996 ASCII 51207 24 MIME-CONF media type message formats

This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. [STANDARDS-TRACK]

RFC1521 RFC1522 RFC1590 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2049 10.17487/RFC2049
RFC2050 Internet Registry IP Allocation Guidelines K. Hubbard M. Kosters D. Conrad D. Karrenberg J. Postel November 1996 ASCII 28975 13 Internet Addresses Network Numbers

This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1466 RFC7020 HISTORIC BEST CURRENT PRACTICE Legacy 10.17487/RFC2050
RFC2051 Definitions of Managed Objects for APPC using SMIv2 M. Allen B. Clouston Z. Kielczewski W. Kwan B. Moore October 1996 ASCII 239359 124 SNANAU-APP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2051
RFC2052 A DNS RR for specifying the location of services (DNS SRV) A. Gulbrandsen P. Vixie October 1996 ASCII 19257 10 DNS-SRV Domain Name System

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). This memo defines an Experimental Protocol for the Internet community.

RFC2782 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2052
RFC2053 The AM (Armenia) Domain E. Der-Danieliantz October 1996 ASCII 4128 3 Top Level Domain Country Code

The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2053
RFC2054 WebNFS Client Specification B. Callaghan October 1996 ASCII 36354 16 Network Fil System

This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2054
RFC2055 WebNFS Server Specification B. Callaghan October 1996 ASCII 20498 10 Network Fil System

This document describes the specifications for a server of WebNFS clients. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2055
RFC2056 Uniform Resource Locators for Z39.50 R. Denenberg J. Kunze D. Lynch November 1996 ASCII 14204 7 URLZ39.50 URL information retrieval

Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2056
RFC2057 Source Directed Access Control on the Internet S. Bradner November 1996 ASCII 56664 20 content regulation deposition

This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2057
RFC2058 Remote Authentication Dial In User Service (RADIUS) C. Rigney A. Rubens W. Simpson S. Willens January 1997 ASCII 118880 64 encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

RFC2138 PROPOSED STANDARD PROPOSED STANDARD IETF ops nasreq 10.17487/RFC2058
RFC2059 RADIUS Accounting C. Rigney January 1997 ASCII 44237 25 remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2139 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2059
RFC2060 Internet Message Access Protocol - Version 4rev1 M. Crispin December 1996 ASCII 166513 82 IMAPV4 IMAP electronic mail Internet Message Access Protocol

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK]

RFC1730 RFC3501 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2060 10.17487/RFC2060
RFC2061 IMAP4 Compatibility with IMAP2bis M. Crispin December 1996 ASCII 5867 3 IMAP electronic mail Internet Message Access Protocol

This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1730 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2061
RFC2062 Internet Message Access Protocol - Obsolete Syntax M. Crispin December 1996 ASCII 14222 8 IMAP electronic mail

This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2062
RFC2063 Traffic Flow Measurement: Architecture N. Brownlee C. Mills G. Ruth January 1997 ASCII 89092 37 TFM-ARCH network data

This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. This memo defines an Experimental Protocol for the Internet community.

RFC2722 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2063
RFC2064 Traffic Flow Measurement: Meter MIB N. Brownlee January 1997 ASCII 67520 38 METER-MIB Management Information Base Network Data

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters. This memo defines an Experimental Protocol for the Internet community.

RFC2720 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2064
RFC2065 Domain Name System Security Extensions D. Eastlake 3rd C. Kaufman January 1997 ASCII 97718 41 DNS-SEC DNS authentication encryption

The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. [STANDARDS-TRACK]

RFC2535 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2065
RFC2066 TELNET CHARSET Option R. Gellens January 1997 ASCII 26088 12 TOPT-CHARSET character set application

This document specifies a mechanism for passing character set and translation information between a TELNET client and server. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2066
RFC2067 IP over HIPPI J. Renwick January 1997 ASCII 66702 30 IP-HIPPI ANSI High-Performance Parallel Interface Internet Protocol

ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track. [STANDARDS-TRACK]

DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2067
RFC2068 Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding J. Gettys J. Mogul H. Frystyk T. Berners-Lee January 1997 ASCII 378114 162 HTTP-1.1 World Wide Web WWW hypermedia

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]

RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app http 10.17487/RFC2068
RFC2069 An Extension to HTTP : Digest Access Authentication J. Franks P. Hallam-Baker J. Hostetler P. Leach A. Luotonen E. Sink L. Stewart January 1997 ASCII 41733 18 DAA Hypertext Transfer Protocol

The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". [STANDARDS-TRACK]

RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2069 10.17487/RFC2069
RFC2070 Internationalization of the Hypertext Markup Language F. Yergeau G. Nicol G. Adams M. Duerst January 1997 ASCII 91887 43 HTML-INT HTML WWW World Wide Web

This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. [STANDARDS-TRACK]

RFC2854 HISTORIC PROPOSED STANDARD IETF app html 10.17487/RFC2070
RFC2071 Network Renumbering Overview: Why would I want it and what is it anyway? P. Ferguson H. Berkowitz January 1997 ASCII 33218 14 Internet Enterprise Connecting Routers

This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC2071
RFC2072 Router Renumbering Guide H. Berkowitz January 1997 ASCII 110591 48 Internet Enterprise Connecting Routers

Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC4192 INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC2072
RFC2073 An IPv6 Provider-Based Unicast Address Format Y. Rekhter P. Lothberg R. Hinden S. Deering J. Postel January 1997 ASCII 15549 7 IPV6-UNI

This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]

RFC2374 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2073
RFC2074 Remote Network Monitoring MIB Protocol Identifiers A. Bierman R. Iddon January 1997 ASCII 81262 43 RMON-MIB RMON Management Information Base

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK]

RFC2895 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2074
RFC2075 IP Echo Host Service C. Partridge January 1997 ASCII 12536 5 IP-Echo Internet Protocol datagram

This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2075
RFC2076 Common Internet Message Headers J. Palme February 1997 ASCII 47639 27 email

This memo contains a table of commonly occurring headers in headings of e-mail messages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app mailext 10.17487/RFC2076
RFC2077 The Model Primary Content Type for Multipurpose Internet Mail Extensions S. Nelson C. Parks Mitra January 1997 ASCII 30158 13 MIME-MODEL MIME Media Type Content Type

The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2077
RFC2078 Generic Security Service Application Program Interface, Version 2 J. Linn January 1997 ASCII 185990 85 GSSAP Authentication Cryptology Data integrity

The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]

RFC1508 RFC2743 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2078
RFC2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) M. Smith January 1997 ASCII 8757 5 URI-ATT URL Universal Resource Locators Directory

This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2079
RFC2080 RIPng for IPv6 G. Malkin R. Minnear January 1997 ASCII 47534 19 RIPNG-IPV6 Routing Information Protocol Internet

This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg rip 10.17487/RFC2080
RFC2081 RIPng Protocol Applicability Statement G. Malkin January 1997 ASCII 6821 4 Routing Information Protocol Internet

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg rip 10.17487/RFC2081
RFC2082 RIP-2 MD5 Authentication F. Baker R. Atkinson January 1997 ASCII 25436 12 RIP2-MD5 Routing Information Protocol Encryption

Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK]

RFC4822 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC2082
RFC2083 PNG (Portable Network Graphics) Specification Version 1.0 T. Boutell March 1997 ASCII 242528 102 PNG file format bitmap

This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2083
RFC2084 Considerations for Web Transaction Security G. Bossert S. Cooper W. Drummond January 1997 ASCII 9022 6 authentication encryption World Wide Web WWW

This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF sec wts 10.17487/RFC2084
RFC2085 HMAC-MD5 IP Authentication with Replay Prevention M. Oehler R. Glenn February 1997 ASCII 13399 6 HMAC-MD5 ipsec Message Digest Security Internet Protocol Encryption

This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2085
RFC2086 IMAP4 ACL extension J. Myers January 1997 ASCII 13925 8 IMAP4-ACL Internet Message Access Protocol Control List

The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

RFC4314 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2086
RFC2087 IMAP4 QUOTA extension J. Myers January 1997 ASCII 8542 5 IMAP4-QUO Internet Message Access Protocol

The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2087
RFC2088 IMAP4 non-synchronizing literals J. Myers January 1997 ASCII 4052 2 IMAP4-LIT Internet Message Access Protocol

The Internet Message Access Protocol [STANDARDS-TRACK]

RFC4466 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2088
RFC2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent B. Wijnen D. Levi January 1997 ASCII 23814 12

The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2576 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2089
RFC2090 TFTP Multicast Option A. Emberson February 1997 ASCII 11857 6 TFTP-MULTI Trivial File Transfer Protocol

This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2090
RFC2091 Triggered Extensions to RIP to Support Demand Circuits G. Meyer S. Sherry January 1997 ASCII 44835 22 RIP-TRIG

This document defines a modification which can be applied to Bellman- Ford (distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg rip 10.17487/RFC2091
RFC2092 Protocol Analysis for Triggered RIP S. Sherry G. Meyer January 1997 ASCII 10865 6

As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg rip http://www.rfc-editor.org/errata_search.php?rfc=2092 10.17487/RFC2092
RFC2093 Group Key Management Protocol (GKMP) Specification H. Harney C. Muckenhirn July 1997 ASCII 48678 23 GKMP-SPEC

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2093
RFC2094 Group Key Management Protocol (GKMP) Architecture H. Harney C. Muckenhirn July 1997 ASCII 53097 22 GKMP-ARCH

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2094
RFC2095 IMAP/POP AUTHorize Extension for Simple Challenge/Response J. Klensin R. Catoe P. Krumviede January 1997 ASCII 10446 5 Post Office Protocol Internet Message Access

This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]

RFC2195 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2095
RFC2096 IP Forwarding Table MIB F. Baker January 1997 ASCII 35930 21 TABLE-MIB Management Information Base Internet Protocol

This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]

RFC1354 RFC4292 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC2096
RFC2097 The PPP NetBIOS Frames Control Protocol (NBFCP) G. Pall January 1997 ASCII 27104 13 PPP-NBFCP Point-to-Point Protocol

This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2097
RFC2098 Toshiba's Router Architecture Extensions for ATM : Overview Y. Katsube K. Nagami H. Esaki February 1997 ASCII 43622 18 Asynchronis Transfer Mode datagram IP Internet Protocol

This memo describes a new internetworking architecture which makes better use of the property of ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2098
RFC2099 Request for Comments Summary RFC Numbers 2000-2099 J. Elliott March 1997 ASCII 40763 21 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2099 RFC2100 The Naming of Hosts J. Ashworth April 1 1997 ASCII 4077 3 April Fool's

This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2100
RFC2101 IPv4 Address Behaviour Today B. Carpenter J. Crowcroft Y. Rekhter February 1997 ASCII 31407 13 Internet Protocol Internet Architecture Board

The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2101
RFC2102 Multicast Support for Nimrod : Requirements and Solution Approaches R. Ramanathan February 1997 ASCII 50963 23 scalable routing architecture

Nimrod does not specify a particular solution for multicasting. Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC2102
RFC2103 Mobility Support for Nimrod : Challenges and Solution Approaches R. Ramanathan February 1997 ASCII 41352 17 IP Internet Protocol routing addressing

We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support. We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC2103
RFC2104 HMAC: Keyed-Hashing for Message Authentication H. Krawczyk M. Bellare R. Canetti February 1997 ASCII 22297 11 ipsec Message Digest Internet Protocol Security encryption

This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind

RFC6151 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2104 10.17487/RFC2104
RFC2105 Cisco Systems' Tag Switching Architecture Overview Y. Rekhter B. Davie D. Katz E. Rosen G. Swallow February 1997 ASCII 33013 13 network layer packet ATM switches

This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2105
RFC2106 Data Link Switching Remote Access Protocol S. Chiang J. Lee H. Yasuda February 1997 ASCII 40819 19 DLSRAP NetBios DLSW

This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2114 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2106
RFC2107 Ascend Tunnel Management Protocol - ATMP K. Hamzeh February 1997 ASCII 44300 21 RADIUS authentication

This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2107
RFC2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 K. de Graaf D. Romascanu D. McMaster K. McCloghrie February 1997 ASCII 166336 82 802.3-MIB MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10 &

RFC1516 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2108
RFC2109 HTTP State Management Mechanism D. Kristol L. Montulli February 1997 ASCII 43469 21 HTTP-STATE Hypertext Transfer Protocol cookie

This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK]

RFC2965 HISTORIC PROPOSED STANDARD IETF app http 10.17487/RFC2109
RFC2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) J. Palme A. Hopmann March 1997 ASCII 41961 19 MHTML Hyper Text Markup Language Multipurpose Internet Mail Extensions

This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. [STANDARDS-TRACK]

RFC2557 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2110
RFC2111 Content-ID and Message-ID Uniform Resource Locators E. Levinson March 1997 ASCII 9099 5 Hyper Text Markup Language URL MIME

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]

RFC2392 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2111
RFC2112 The MIME Multipart/Related Content-type E. Levinson March 1997 ASCII 17052 9 Hyper Text Markup Language Multipurpose Internet,Mail Extensions

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]

RFC1872 RFC2387 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2112
RFC2113 IP Router Alert Option D. Katz February 1997 ASCII 7924 4 ROUT-ALERT

This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]

RFC5350 RFC6398 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2113
RFC2114 Data Link Switching Client Access Protocol S. Chiang J. Lee H. Yasuda February 1997 ASCII 50872 22 DLSCAP

This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2106 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2114
RFC2115 Management Information Base for Frame Relay DTEs Using SMIv2 C. Brown F. Baker September 1997 ASCII 59950 32 FRAME-MIB MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing Frame Relay interfaces on DTEs. [STANDARDS-TRACK]

RFC1315 DRAFT STANDARD DRAFT STANDARD IETF int ion 10.17487/RFC2115
RFC2116 X.500 Implementations Catalog-96 C. Apple K. Rossen April 1997 ASCII 243994 164 Directory Services DSA DUA Agent Interfaces

This document is a revision to [RFC 1632]: A Revised Catalog of Available X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. [RFC 1632] is a revision of [RFC 1292]. This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1632 FYI0011 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2116
RFC2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification D. Estrin D. Farinacci A. Helmy D. Thaler S. Deering M. Handley V. Jacobson C. Liu P. Sharma L. Wei June 1997 ASCII 151886 66

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community.

RFC2362 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC2117
RFC2118 Microsoft Point-To-Point Compression (MPPC) Protocol G. Pall March 1997 ASCII 17443 9 Point-to-Point Protocol PPP

This document describes the use of the Microsoft Point to Point Compression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2118
RFC2119 Key words for use in RFCs to Indicate Requirement Levels S. Bradner March 1997 ASCII 4723 3 Standards Track Documents

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0014 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=2119 10.17487/RFC2119
RFC2120 Managing the X.500 Root Naming Context D. Chadwick March 1997 ASCII 30773 14 X.500-NAME ISO International Standards Organization

This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app ids 10.17487/RFC2120
RFC2121 Issues affecting MARS Cluster Size G. Armitage March 1997 ASCII 26781 12 ATM Asynchronous Transfer Mode Multicast IP Internet Protocol

This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2121
RFC2122 VEMMI URL Specification D. Mavrakis H. Layec K. Kartmann March 1997 ASCII 25043 11 VEMMI-URL Uniform Resource Locator Enhanced Man-Machine Interface Videotex

A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2122
RFC2123 Traffic Flow Measurement: Experiences with NeTraMet N. Brownlee March 1997 ASCII 81874 34 Meter Reader Network

This memo records experiences in implementing and using the Traffic Flow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2123
RFC2124 Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0 P. Amsden J. Amweg P. Calato S. Bensley G. Lyons March 1997 ASCII 47912 21 LFAP

This document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2124
RFC2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) C. Richards K. Smith March 1997 ASCII 49213 24 BAP-BACP Point-to-Point datagram multilink

This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2125
RFC2126 ISO Transport Service on top of TCP (ITOT) Y. Pouffary A. Young March 1997 ASCII 51032 25 ITOT International Standards Organization Transmission Control Protocol

This document is a revision to STD35, RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. [STANDARDS-TRACK]

RFC1006 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2126 10.17487/RFC2126
RFC2127 ISDN Management Information Base using SMIv2 G. Roeck Editor March 1997 ASCII 95994 49 ISDN-MIB MIB ISDN Integrated Services Digital Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a minimal set of managed objects for SNMP-based management of ISDN terminal interfaces. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int isdnmib http://www.rfc-editor.org/errata_search.php?rfc=2127 10.17487/RFC2127
RFC2128 Dial Control Management Information Base using SMIv2 G. Roeck Editor March 1997 ASCII 66153 34 DC-MIB MIB ISDN Integrated Services Digital Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing demand access circuits, including ISDN. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int isdnmib 10.17487/RFC2128
RFC2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification K. Nagami Y. Katsube Y. Shobatake A. Mogi S. Matsuzawa T. Jinmei H. Esaki April 1997 ASCII 41137 19 packet flow datalink mapping

This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2129
RFC2130 The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 C. Weider C. Preston K. Simonsen H. Alvestrand R. Atkinson M. Crispin P. Svanberg April 1997 ASCII 63443 31 Internet Architecture Board interoperability

This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC6055 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2130
RFC2131 Dynamic Host Configuration Protocol R. Droms March 1997 ASCII 113738 45 DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]

RFC1541 RFC3396 RFC4361 RFC5494 RFC6842 DRAFT STANDARD DRAFT STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2131 10.17487/RFC2131
RFC2132 DHCP Options and BOOTP Vendor Extensions S. Alexander R. Droms March 1997 ASCII 63670 34 DHCP-BOOTP Dynamic Host Configuration Protocol Bootstrap

This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]

RFC1533 RFC3442 RFC3942 RFC4361 RFC4833 RFC5494 DRAFT STANDARD DRAFT STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2132 10.17487/RFC2132
RFC2133 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound W. Stevens April 1997 ASCII 69737 32 application program interface API Internet Protocol addresses

This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2553 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2133
RFC2134 Articles of Incorporation of Internet Society ISOC Board of Trustees April 1997 ASCII 9131 5 ISOC

These are the articles of incorporation of the Internet Society. They are published for the information of the IETF community at the request of the poisson working group. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2134
RFC2135 Internet Society By-Laws ISOC Board of Trustees April 1997 ASCII 20467 9 ISOC

These are the by-laws of the Internet Society, as amended, as of June 1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2135
RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE) P. Vixie Editor S. Thomson Y. Rekhter J. Bound April 1997 ASCII 56354 26 DNS-UPDATE database opcode zone

Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]

RFC1035 RFC3007 RFC4035 RFC4033 RFC4034 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2136 10.17487/RFC2136
RFC2137 Secure Domain Name System Dynamic Update D. Eastlake 3rd April 1997 ASCII 24824 11 SDNSDU DNS digital signatures cryptographic

This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. [STANDARDS-TRACK]

RFC3007 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2137
RFC2138 Remote Authentication Dial In User Service (RADIUS) C. Rigney A. Rubens W. Simpson S. Willens April 1997 ASCII 120407 65 RADIUS encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

RFC2058 RFC2865 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2138
RFC2139 RADIUS Accounting C. Rigney April 1997 ASCII 44919 25 RADIUS-ACC remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2059 RFC2866 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2139
RFC2140 TCP Control Block Interdependence J. Touch April 1997 ASCII 26032 11

This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2140
RFC2141 URN Syntax R. Moats May 1997 ASCII 14077 8 URN-SYNTAX Uniform Resource Names

Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2141 10.17487/RFC2141
RFC2142 Mailbox Names for Common Services, Roles and Functions D. Crocker May 1997 ASCII 12195 6 MAIL-SERV email internet addresses

This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2142 10.17487/RFC2142
RFC2143 Encapsulating IP with the Small Computer System Interface B. Elliston May 1997 ASCII 10749 5 IP-SCSI SCSI

This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2143
RFC2144 The CAST-128 Encryption Algorithm C. Adams May 1997 ASCII 37532 15 CAST-128

There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2144
RFC2145 Use and Interpretation of HTTP Version Numbers J. C. Mogul R. Fielding J. Gettys H. Frystyk May 1997 ASCII 13659 7

HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC7230 INFORMATIONAL INFORMATIONAL IETF app http 10.17487/RFC2145
RFC2146 U.S. Government Internet Domain Names Federal Networking Council May 1997 ASCII 26564 12 Gov FED.US

This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain ".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1816 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2146
RFC2147 TCP and UDP over IPv6 Jumbograms D. Borman May 1997 ASCII 1883 3 IPv6-Jumbo User Datagram Protocol Terminal Control Internet

IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK]

RFC2675 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2147
RFC2148 Deployment of the Internet White Pages Service H. Alvestrand P. Jurg September 1997 ASCII 31539 15 X. 500 data structure naming scheme IWPS

This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0015 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ids 10.17487/RFC2148
RFC2149 Multicast Server Architectures for MARS-based ATM multicasting R. Talpade M. Ammar May 1997 ASCII 42007 18

This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2149
RFC2150 Humanities and Arts: Sharing Center Stage on the Internet J. Max W. Stickle October 1997 ASCII 154037 62 informational infrastructure guide introduction

The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

FYI0031 INFORMATIONAL INFORMATIONAL IETF harts 10.17487/RFC2150
RFC2151 A Primer On Internet and TCP/IP Tools and Utilities G. Kessler S. Shepard June 1997 ASCII 114130 52 resource guide user

This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1739 FYI0030 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2151
RFC2152 UTF-7 A Mail-Safe Transformation Format of Unicode D. Goldsmith M. Davis May 1997 ASCII 28065 15 UTF-7

This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641, "Using Unicode with MIME". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1642 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2152 10.17487/RFC2152
RFC2153 PPP Vendor Extensions W. Simpson May 1997 ASCII 10780 6 PPP-EXT Point-to-Point Protocol

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC1661 RFC1962 RFC5342 RFC7042 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2153
RFC2154 OSPF with Digital Signatures S. Murphy M. Badger B. Wellington June 1997 ASCII 72701 29 OSPF-DIG

This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co-existence with, standard OSPF V2 is described. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2154 10.17487/RFC2154
RFC2155 Definitions of Managed Objects for APPN using SMIv2 B. Clouston B. Moore June 1997 ASCII 213809 124 APPN-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]

RFC2455 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2155
RFC2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME S. Kille January 1998 ASCII 280385 144 MIXER multipurpose internet mail extensions message transfer protocol

This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK]

RFC0987 RFC1026 RFC1138 RFC1148 RFC1327 RFC1495 RFC0822 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2156
RFC2157 Mapping between X.400 and RFC-822/MIME Message Bodies H. Alvestrand January 1998 ASCII 92554 49 mixer multipurpose internet mail extensions

This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mixer http://www.rfc-editor.org/errata_search.php?rfc=2157 10.17487/RFC2157
RFC2158 X.400 Image Body Parts H. Alvestrand January 1998 ASCII 5547 4 mixer multipurpose internet mail extensions

This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2158
RFC2159 A MIME Body Part for FAX H. Alvestrand January 1998 ASCII 11471 7 mixer multipurpose internet mail extensions

This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2159
RFC2160 Carrying PostScript in X.400 and MIME H. Alvestrand January 1998 ASCII 7059 5 mixer multipurpose internet mail extensions

This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2160
RFC2161 A MIME Body Part for ODA H. Alvestrand January 1998 ASCII 8009 5 MIME-ODA mixer multipurpose internet mail extensions

This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app mixer 10.17487/RFC2161
RFC2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail C. Allocchio January 1998 ASCII 58553 34 MAP-MAIL mixer multipurpose internet mail extensions mime

The standard referred shortly into this document as "X.400" relates to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS). This document covers the Inter Personal Messaging System (IPMS) only. This memo defines an Experimental Protocol for the Internet community.

RFC1405 EXPERIMENTAL EXPERIMENTAL IETF app mixer 10.17487/RFC2162
RFC2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) C. Allocchio January 1998 ASCII 58789 26 DNS-MCGAM mime internet enhanced Relay Multipurpose internet mail extensions x.400 mixer

This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. [STANDARDS-TRACK]

RFC1664 RFC3597 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2163
RFC2164 Use of an X.500/LDAP directory to support MIXER address mapping S. Kille January 1998 ASCII 16701 10 lightweight directory access protocol mime internet x,.400 enhanced relay

This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK]

RFC1838 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2164
RFC2165 Service Location Protocol J. Veizades E. Guttman C. Perkins S. Kaplan June 1997 ASCII 169889 72 SLP

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]

RFC2608 RFC2609 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc 10.17487/RFC2165
RFC2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements D. Bryant P. Brittain June 1997 ASCII 75527 34

This document specifies a set of extensions to RFC 1795 designed to improve the scalability of DLSw clarifications to RFC 1795 in the light of the implementation experience to-date. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2166
RFC2167 Referral Whois (RWhois) Protocol V1.5 S. Williamson M. Kosters D. Blacka J. Singh K. Zeilstra June 1997 ASCII 136355 69 RWHOIS

This memo describes Version 1.5 of the client/server interaction of RWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1714 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2167
RFC2168 Resolution of Uniform Resource Identifiers using the Domain Name System R. Daniel M. Mealling June 1997 ASCII 46528 20

The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community.

RFC3401 RFC3402 RFC3403 RFC3404 RFC2915 EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2168
RFC2169 A Trivial Convention for using HTTP in URN Resolution R. Daniel June 1997 ASCII 17763 9

This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2169
RFC2170 Application REQuested IP over ATM (AREQUIPA) W. Almesberger J. Le Boudec P. Oechslin July 1997 ASCII 22874 10 Internet Protocol

This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2170
RFC2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1 K. Murakami M. Maruyama June 1997 ASCII 17480 9 MAPOS-SONET

This memo documents a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2171
RFC2172 MAPOS Version 1 Assigned Numbers M. Maruyama K. Murakami June 1997 ASCII 4857 3

This memo documents the parameters used in the Multiple Access Protocol over SONET/SDH Version 1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2172
RFC2173 A MAPOS version 1 Extension - Node Switch Protocol K. Murakami M. Maruyama June 1997 ASCII 12251 6

This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2173
RFC2174 A MAPOS version 1 Extension - Switch-Switch Protocol K. Murakami M. Maruyama June 1997 ASCII 47967 22

This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH) version 1 extension, Switch Switch Protocol which provides dynamic routing for unicast, broadcast, and multicast. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2174
RFC2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing K. Murakami M. Maruyama June 1997 ASCII 11677 6

This memo documents MAPOS 16, a multiple access protocol for transmission of network-protocol datagrams, encapsulated in HDLC frames with 16 bit addressing, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2175
RFC2176 IPv4 over MAPOS Version 1 K. Murakami M. Maruyama June 1997 ASCII 12305 6 IPV4-MAPOS

This memo documents a mechanism for supporting Version 4 of the Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC5494 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2176
RFC2177 IMAP4 IDLE command B. Leiba June 1997 ASCII 6770 4 IMAP4-IDLE

This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2177
RFC2178 OSPF Version 2 J. Moy July 1997 ASCII 495866 211 Open Shortest Path First routing Autonomous system AS

This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree.

OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. [STANDARDS-TRACK]

RFC1583 RFC2328 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC2178
RFC2179 Network Security For Trade Shows A. Gwinn July 1997 ASCII 20690 10 network system attacks

This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2179
RFC2180 IMAP4 Multi-Accessed Mailbox Practice M. Gahrns July 1997 ASCII 24750 14 Internet Message Access Protocol Client Server

The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2180
RFC2181 Clarifications to the DNS Specification R. Elz R. Bush July 1997 ASCII 36989 14 DNS-CLAR Domain Name System

This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]

RFC1034 RFC1035 RFC1123 RFC4035 RFC2535 RFC4343 RFC4033 RFC4034 RFC5452 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2181
RFC2182 Selection and Operation of Secondary DNS Servers R. Elz R. Bush S. Bradner M. Patton July 1997 ASCII 27456 11 Domain Name System delegated zone

This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

BCP0016 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind 10.17487/RFC2182
RFC2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field R. Troost S. Dorner K. Moore Editor August 1997 ASCII 23150 12 inline attachment MIME Mail Multimedia EMail

This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). [STANDARDS-TRACK]

RFC1806 RFC2184 RFC2231 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2183 10.17487/RFC2183
RFC2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations N. Freed K. Moore August 1997 ASCII 17635 9 mail Multimedia EMail

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]

RFC2231 RFC2045 RFC2047 RFC2183 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2184 10.17487/RFC2184
RFC2185 Routing Aspects of IPv6 Transition R. Callon D. Haskin September 1997 ASCII 31281 13 address network tunneling

This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document "Transition Mechanisms for IPv6 Hosts and Routers." Readers should be familiar with the transition mechanisms before reading this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2185
RFC2186 Internet Cache Protocol (ICP), version 2 D. Wessels K. Claffy September 1997 ASCII 18808 9 ICP www web http hypertext transfer protocol

This document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2186
RFC2187 Application of Internet Cache Protocol (ICP), version 2 D. Wessels K. Claffy September 1997 ASCII 51662 24 web www url uniform resource identifier

This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2187
RFC2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2 M. Banan M. Taylor J. Cheng September 1997 ASCII 118374 57 ESRO RPC Remote Procedure Call Wireless

This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2188
RFC2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification -- A. Ballardie September 1997 ASCII 52043 23 Inter-Domain-Protocol IDMR

This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing. This memo defines an Experimental Protocol for the Internet community.

HISTORIC EXPERIMENTAL IETF rtg idmr 10.17487/RFC2189
RFC2190 RTP Payload Format for H.263 Video Streams C. Zhu September 1997 ASCII 26409 12 real-time transfer

This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rai avt 10.17487/RFC2190
RFC2191 VENUS - Very Extensive Non-Unicast Service G. Armitage September 1997 ASCII 31316 12 multicast IP ATM

This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed "Very Extensive NonUnicast Service" (VENUS), and shows how complex such a service would be. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2191
RFC2192 IMAP URL Scheme C. Newman September 1997 ASCII 31426 16 IMAP-URL Internet Message Access Protocol Uniform Resource Identifiers

This document defines a URL scheme for referencing objects on an IMAP server. [STANDARDS-TRACK]

RFC5092 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2192 10.17487/RFC2192
RFC2193 IMAP4 Mailbox Referrals M. Gahrns September 1997 ASCII 16248 9 IMAP4MAIL Internet Mail Access Protocol messages

Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2193
RFC2194 Review of Roaming Implementations B. Aboba J. Lu J. Alsop J. Ding W. Wang September 1997 ASCII 81533 35 ISP Internet Server Provider

This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2194
RFC2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response J. Klensin R. Catoe P. Krumviede September 1997 ASCII 10468 5 IMAPPOPAU Post Office Protocol Internet Message Access

This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]

RFC2095 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2195
RFC2196 Site Security Handbook B. Fraser September 1997 ASCII 191772 75

This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC1244 FYI0008 INFORMATIONAL INFORMATIONAL IETF ssh http://www.rfc-editor.org/errata_search.php?rfc=2196 10.17487/RFC2196
RFC2197 SMTP Service Extension for Command Pipelining N. Freed September 1997 ASCII 15003 8 SMTP-Pipe simple mail transfer TCP transmission control protocol

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]

RFC1854 RFC2920 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2197
RFC2198 RTP Payload for Redundant Audio Data C. Perkins I. Kouvelas O. Hodson V. Hardman M. Handley J.C. Bolot A. Vega-Garcia S. Fosse-Parisis September 1997 ASCII 25166 11 RTP-RAD

This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]

RFC6354 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2198
RFC2199 Request for Comments Summary RFC Numbers 2100-2199 A. Ramos January 1998 ASCII 47664 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2199 RFC2200 Internet Official Protocol Standards J. Postel June 1997 ASCII 94506 39 IAB official protocol standards

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

RFC1250 RFC2000 RFC2300 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2200
RFC2201 Core Based Trees (CBT) Multicast Routing Architecture A. Ballardie September 1997 ASCII 38040 15 IP Internet Protocol IDMR Inter-Domain

CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. This memo defines an Experimental Protocol for the Internet community.

HISTORIC EXPERIMENTAL IETF rtg idmr 10.17487/RFC2201
RFC2202 Test Cases for HMAC-MD5 and HMAC-SHA-1 P. Cheng R. Glenn September 1997 ASCII 11945 9 Hash Message Authentications Codes message digest secure

This document provides two sets of test cases for HMAC-MD5 and HMAC- SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2202 10.17487/RFC2202
RFC2203 RPCSEC_GSS Protocol Specification M. Eisler A. Chiu L. Ling September 1997 ASCII 50937 23 RPCSEC-GSS Remote Procedure Call Generic Security Services API Application Programming Interface

This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). [STANDARDS-TRACK]

RFC5403 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc http://www.rfc-editor.org/errata_search.php?rfc=2203 10.17487/RFC2203
RFC2204 ODETTE File Transfer Protocol D. Nash September 1997 ASCII 151857 74 ODETTE FTP Internet Motor Industry data exchange

This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC5024 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2204
RFC2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification R. Braden Editor L. Zhang S. Berson S. Herzog S. Jamin September 1997 ASCII 223974 112 RSVP integrated services multicast unicast QoS signaling

This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]

RFC2750 RFC3936 RFC4495 RFC5946 RFC6437 RFC6780 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2205
RFC2206 RSVP Management Information Base using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII 112937 64 RSVP-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2206
RFC2207 RSVP Extensions for IPSEC Data Flows L. Berger T. O'Malley September 1997 ASCII 30473 14 RSVP-IPSEC resource reservation QoS IP Security

This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2207
RFC2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment A. Mankin Editor F. Baker B. Braden S. Bradner M. O'Dell A. Romanow A. Weinrib L. Zhang September 1997 ASCII 14289 6 RSVP

This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv rsvp 10.17487/RFC2208
RFC2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules R. Braden L. Zhang September 1997 ASCII 51690 25 RSVP-MPR QoS implementation algorithms

This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2209 10.17487/RFC2209
RFC2210 The Use of RSVP with IETF Integrated Services J. Wroclawski September 1997 ASCII 77613 33 RSVP-IS Resource Reservation Controlled Load QOS: Quality of Service

This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2210
RFC2211 Specification of the Controlled-Load Network Element Service J. Wroclawski September 1997 ASCII 46523 19 QOS: Quality of Service integrated services

This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2211
RFC2212 Specification of Guaranteed Quality of Service S. Shenker C. Partridge R. Guerin September 1997 ASCII 52330 20 GQOS QOS quality of service integrated services

This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2212
RFC2213 Integrated Services Management Information Base using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII 36147 21 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv http://www.rfc-editor.org/errata_search.php?rfc=2213 10.17487/RFC2213
RFC2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII 15971 9 MIB attributes interface network protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2214
RFC2215 General Characterization Parameters for Integrated Service Network Elements S. Shenker J. Wroclawski September 1997 ASCII 39552 16 QOS Quality of service

This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2215
RFC2216 Network Element Service Specification Template S. Shenker J. Wroclawski September 1997 ASCII 53655 22 QOS Quality of Service Control

This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv intserv 10.17487/RFC2216
RFC2217 Telnet Com Port Control Option G. Clark October 1997 ASCII 31664 14 TOPT-COMPORT remote login host

This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2217 10.17487/RFC2217
RFC2218 A Common Schema for the Internet White Pages Service T. Genovese B. Jennings October 1997 ASCII 16258 8 IWPS information user

This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app ids 10.17487/RFC2218
RFC2219 Use of DNS Aliases for Network Services M. Hamilton R. Wright October 1997 ASCII 17858 8 domain name system symbolic

It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC- 1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0017 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ids 10.17487/RFC2219
RFC2220 The Application/MARC Content-type R. Guenther October 1997 ASCII 7025 4 APP-MARC media-type machine readable cataloging records

This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2220
RFC2221 IMAP4 Login Referrals M. Gahrns October 1997 ASCII 9251 5 IMAP4LOGIN Internet Message Access Protocol server

When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2221
RFC2222 Simple Authentication and Security Layer (SASL) J. Myers October 1997 ASCII 35010 16 SASL encryption protocol specific

This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]

RFC4422 RFC4752 RFC2444 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2222 10.17487/RFC2222
RFC2223 Instructions to RFC Authors J. Postel J. Reynolds October 1997 ASCII 37948 20 Request For Comment

This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1543 RFC1111 RFC0825 RFC7322 RFC5741 RFC6949 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2223
RFC2224 NFS URL Scheme B. Callaghan October 1997 ASCII 22726 11 NFS-URL Universal Resource Locators Network File System syntax directories

A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, "Uniform Resource Locators (URL)". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2224
RFC2225 Classical IP and ARP over ATM M. Laubach J. Halpern April 1998 ASCII 65779 28 IP-ATM Internet protocol address resolution asynchronous,transfer mode

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]

RFC1626 RFC1577 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2225
RFC2226 IP Broadcast over ATM Networks T. Smith G. Armitage October 1997 ASCII 30661 14 Internet Protocol Asynchronous Transfer Mode

This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2226
RFC2227 Simple Hit-Metering and Usage-Limiting for HTTP J. Mogul P. Leach October 1997 ASCII 85127 37 Hypertext Transfer Protocol extension

This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app http 10.17487/RFC2227
RFC2228 FTP Security Extensions M. Horowitz S. Lunt October 1997 ASCII 58733 27 FTPSECEXT file transfer protocol authentication encoding

This document defines extensions to the FTP specification STD 9, RFC

RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2228
RFC2229 A Dictionary Server Protocol R. Faith B. Martin October 1997 ASCII 59551 30 DSP DICT TCP Transmission Control Protocol database definitions

The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2229 10.17487/RFC2229
RFC2230 Key Exchange Delegation Record for the DNS R. Atkinson November 1997 ASCII 25563 11 KEYX-DNS Domain Name System RR Resource Record KX

This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2230
RFC2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations N. Freed K. Moore November 1997 ASCII 19280 10 MIME-EXT Mail Multimedia EMail

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]

RFC2184 RFC2045 RFC2047 RFC2183 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2231 10.17487/RFC2231
RFC2232 Definitions of Managed Objects for DLUR using SMIv2 B. Clouston Editor B. Moore Editor November 1997 ASCII 37955 21 DLUR-MIB Management Information Base MIB Dependent LU Requester APPN Advanced Peek to Peek Networking

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2232
RFC2233 The Interfaces Group MIB using SMIv2 K. McCloghrie F. Kastenholz November 1997 ASCII 148033 66 INTERGRMIB Management Information Base Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANDARDS-TRACK]

RFC1573 RFC2863 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2233
RFC2234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell November 1997 ASCII 24265 14 ABNF Augmented Backus-Naur Form electronic mail

In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]

RFC4234 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2234 10.17487/RFC2234
RFC2235 Hobbes' Internet Timeline R. Zakon November 1997 ASCII 43060 22 events technologies history

This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

FYI0032 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2235
RFC2236 Internet Group Management Protocol, Version 2 W. Fenner November 1997 ASCII 51048 24 IGMP IGMP multicast routing IP Internet Protocol

This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. [STANDARDS-TRACK]

RFC1112 RFC3376 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=2236 10.17487/RFC2236
RFC2237 Japanese Character Encoding for Internet Messages K. Tamaru November 1997 ASCII 11628 6 eletronic mail character set scheme

This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2237
RFC2238 Definitions of Managed Objects for HPR using SMIv2 B. Clouston Editor B. Moore Editor November 1997 ASCII 65498 35 HPR-MIB MIB Management Information Base high performance routing

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2238
RFC2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 K. de Graaf D. Romascanu D. McMaster K. McCloghrie S. Roberts November 1997 ASCII 80651 43 MAUS-MIB

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing 10 and 100 Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30, "10 & 100 Mb/s Management," October 26, 1995. [STANDARDS-TRACK]

RFC2668 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2239
RFC2240 A Legal Basis for Domain Name Allocation O. Vaughan November 1997 ASCII 13602 7 DNS

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2352 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2240
RFC2241 DHCP Options for Novell Directory Services D. Provan November 1997 ASCII 8419 5 DHCP-NDS NDS

This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2241 10.17487/RFC2241
RFC2242 NetWare/IP Domain Name and Information R. Droms K. Fong November 1997 ASCII 10653 6 NETWAREIP DHCP

This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2242
RFC2243 OTP Extended Responses C. Metz November 1997 ASCII 19730 10 OTP-ER One Time Password

This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC2243
RFC2244 ACAP -- Application Configuration Access Protocol C. Newman J. G. Myers November 1997 ASCII 154610 71 ACAP URL Uniform Resource Locator

The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. [STANDARDS-TRACK]

RFC6075 PROPOSED STANDARD PROPOSED STANDARD IETF app acap http://www.rfc-editor.org/errata_search.php?rfc=2244 10.17487/RFC2244
RFC2245 Anonymous SASL Mechanism C. Newman November 1997 ASCII 9974 5 SASL-ANON Simple Authentication Security Layer

As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. [STANDARDS-TRACK]

RFC4505 PROPOSED STANDARD PROPOSED STANDARD IETF app acap 10.17487/RFC2245
RFC2246 The TLS Protocol Version 1.0 T. Dierks C. Allen January 1999 ASCII 170401 80 transport protocol layer authentication privacy

This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

RFC4346 RFC3546 RFC5746 RFC6176 RFC7465 RFC7507 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2246 10.17487/RFC2246
RFC2247 Using Domains in LDAP/X.500 Distinguished Names S. Kille M. Wahl A. Grimstad R. Huber S. Sataluri January 1998 ASCII 12411 7 lightweight directory access protocol DNS Domain name system

This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]

RFC4519 RFC4524 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2247
RFC2248 Network Services Monitoring MIB N. Freed S. Kille January 1998 ASCII 34106 19 NSM-MIB Management Information Base SNMP Simple Network Management Protocol

This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK]

RFC1565 RFC2788 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2248
RFC2249 Mail Monitoring MIB N. Freed S. Kille January 1998 ASCII 52334 28 MAIL-MIB Management Information Base Message Transfer Agents

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [STANDARDS-TRACK]

RFC1566 RFC2789 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2249
RFC2250 RTP Payload Format for MPEG1/MPEG2 Video D. Hoffman G. Fernando V. Goyal M. Civanlar January 1998 ASCII 34293 16 RTP-MPEG Real-Time Transport Protocol Audio System Streams

This memo describes a packetization scheme for MPEG video and audio streams. [STANDARDS-TRACK] The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2038 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=2250 10.17487/RFC2250
RFC2251 Lightweight Directory Access Protocol (v3) M. Wahl T. Howes S. Kille December 1997 ASCII 114488 50 LDAPV3 LDAv3 x.500

The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]

RFC4510 RFC4511 RFC4513 RFC4512 RFC3377 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2251
RFC2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions M. Wahl A. Coulbeck T. Howes S. Kille December 1997 ASCII 60204 32 LDAP3-ATD LDAv3 x.500 syntax

This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK]

RFC4510 RFC4517 RFC4523 RFC4512 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2252 10.17487/RFC2252
RFC2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names M. Wahl S. Kille T. Howes December 1997 ASCII 18226 10 LDAP3-UTF8 LDAPv3 x.500 ASN.1 string format

This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]

RFC1779 RFC4510 RFC4514 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2253 10.17487/RFC2253
RFC2254 The String Representation of LDAP Search Filters T. Howes December 1997 ASCII 13511 8 STR-LDAP LDAPv3 x.500 ASN.1 string format

This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]

RFC1960 RFC4510 RFC4515 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2254 10.17487/RFC2254
RFC2255 The LDAP URL Format T. Howes M. Smith December 1997 ASCII 20685 10 LDAP-URL Lightweight Directory Access Protocol Universal Resource Locator

This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK]

RFC1959 RFC4510 RFC4516 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2255
RFC2256 A Summary of the X.500(96) User Schema for use with LDAPv3 M. Wahl December 1997 ASCII 32377 20 Lightweight Directory Access Protocol syntax

This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS-TRACK]

RFC4517 RFC4519 RFC4523 RFC4512 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2256
RFC2257 Agent Extensibility (AgentX) Protocol Version 1 M. Daniele B. Wijnen D. Francisco January 1998 ASCII 177452 80 AGENTX SNMP Simple Network Management Protocol MIB Information Base

This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK]

RFC2741 PROPOSED STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2257
RFC2258 Internet Nomenclator Project J. Ordille January 1998 ASCII 34871 15 Database Server CCSO Computer Communications Services Office

The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world. This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet Nomenclator Project, and how to use the Nomenclator search engine to find people on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2258
RFC2259 Simple Nomenclator Query Protocol (SNQP) J. Elliott J. Ordille January 1998 ASCII 58508 30 SNQP Data Repositories Client Server

The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2259
RFC2260 Scalable Support for Multi-homed Multi-provider Connectivity T. Bates Y. Rekhter January 1998 ASCII 28085 12 ISP Internet Service Provider Routing

This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2260 10.17487/RFC2260
RFC2261 An Architecture for Describing SNMP Management Frameworks D. Harrington R. Presuhn B. Wijnen January 1998 ASCII 128036 56 Simple Network Management Protocol Message Network Management Protocol security access control snmpv3

This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]

RFC2271 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2261
RFC2262 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen January 1998 ASCII 88254 39 architecture SNMPv3 multiple versions

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

RFC2272 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2262
RFC2263 SNMPv3 Applications D. Levi P. Meyer B. Stewart January 1998 ASCII 143493 70 Simple Network Management Protocol operations notification filtering proxy forwarding

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]

RFC2273 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2263
RFC2264 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen January 1998 ASCII 168759 76 architecture message level

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

RFC2274 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2264
RFC2265 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie January 1998 ASCII 77807 36 SNMPV3 Architecture

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

RFC2275 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2265
RFC2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices J. Flick January 1998 ASCII 134027 56 MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network repeaters based on IEEE 802.12. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2266
RFC2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing P. Ferguson D. Senie January 1998 ASCII 21032 10 ISP Internet Service Provider Internet Protocol DOS

This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2827 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2267
RFC2268 A Description of the RC2(r) Encryption Algorithm R. Rivest March 1998 ASCII 19048 11 RC2-ENCRP encryption secre key rsa

This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2268 10.17487/RFC2268
RFC2269 Using the MARS Model in non-ATM NBMA Networks G. Armitage January 1998 ASCII 12094 6 Asynchronous Transfer Mode Multicast Address Resolution Server IP Internet Protocol

This document is intended to state the obvious equivalences, and explain the less obvious implications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2269
RFC2270 Using a Dedicated AS for Sites Homed to a Single Provider J. Stewart T. Bates R. Chandra E. Chen January 1998 ASCII 12063 6 Autonomous System BGP4 Border Gateway Protocol ISP Internet Service

With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC2270
RFC2271 An Architecture for Describing SNMP Management Frameworks D. Harrington R. Presuhn B. Wijnen January 1998 ASCII 128227 56 Simple Network Management Protocol Message Network Management Protocol security access control snmpv3

This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]

RFC2261 RFC2571 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2271
RFC2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen January 1998 ASCII 88445 39 SNMPv3 architecture SNMPv3 multiple versions

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

RFC2262 RFC2572 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2272
RFC2273 SNMPv3 Applications D. Levi P. Meyer B. Stewart January 1998 ASCII 143754 70 Simple Network Management Protocol operations notification filtering proxy forwarding

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]

RFC2263 RFC2573 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2273
RFC2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen January 1998 ASCII 168950 76 architecture message level

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

RFC2264 RFC2574 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2274
RFC2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie January 1998 ASCII 77998 36 SNMPV3 Architecture

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

RFC2265 RFC2575 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2275
RFC2276 Architectural Principles of Uniform Resource Name Resolution K. Sollins January 1998 ASCII 64811 24 URCs URN URLs Uniform Resource Locators Characteristics

This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC3401 INFORMATIONAL INFORMATIONAL IETF app urn 10.17487/RFC2276
RFC2277 IETF Policy on Character Sets and Languages H. Alvestrand January 1998 ASCII 16622 9 charset

This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0018 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=2277 10.17487/RFC2277
RFC2278 IANA Charset Registration Procedures N. Freed J. Postel January 1998 ASCII 18881 10 character set mime multipurpose internet mail extensions

MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2978 INFORMATIONAL BEST CURRENT PRACTICE Legacy 10.17487/RFC2278
RFC2279 UTF-8, a transformation format of ISO 10646 F. Yergeau January 1998 ASCII 21634 10 UTF-8 UCS Transformation Format

UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. [STANDARDS-TRACK]

RFC2044 RFC3629 DRAFT STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2279
RFC2280 Routing Policy Specification Language (RPSL) C. Alaettinoglu T. Bates E. Gerich D. Karrenberg D. Meyer M. Terpstra C. Villamizar January 1998 ASCII 114985 53 RPSL network operator AS autonomous system database

This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]

RFC2622 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2280
RFC2281 Cisco Hot Standby Router Protocol (HSRP) T. Li B. Cole P. Morton D. Li March 1998 ASCII 35161 17 HSRP

The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2281 10.17487/RFC2281
RFC2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin February 1998 ASCII 29852 14 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2027 RFC2727 INFORMATIONAL BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC2282
RFC2283 Multiprotocol Extensions for BGP-4 T. Bates R. Chandra D. Katz Y. Rekhter February 1998 ASCII 18946 9 MEXT-BGP4 Border gateway protocol router network layer

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]

RFC2858 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2283
RFC2284 PPP Extensible Authentication Protocol (EAP) L. Blunk J. Vollbrecht March 1998 ASCII 29452 15 PPP-EAP point-to-point authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. [STANDARDS-TRACK]

RFC3748 RFC2484 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2284
RFC2285 Benchmarking Terminology for LAN Switching Devices R. Mandeville February 1998 ASCII 43130 25 local area network MAC Medium Access Control layer

This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2285
RFC2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128 J. Kapp February 1998 ASCII 11849 7 has authentication message IP Internet Protocol codes

This document provides two sets of test cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2286 10.17487/RFC2286
RFC2287 Definitions of System-Level Managed Objects for Applications C. Krupczak J. Saperia February 1998 ASCII 98210 44 SLM-APP mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2287
RFC2288 Using Existing Bibliographic Identifiers as Uniform Resource Names C. Lynch C. Preston R. Daniel February 1998 ASCII 21628 10 URNs Syntax framework

This document discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2288 10.17487/RFC2288
RFC2289 A One-Time Password System N. Haller C. Metz P. Nesser M. Straw February 1998 ASCII 56495 25 ONE-PASS authentication OTP replay attach

This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS-TRACK]

RFC1938 STD0061 INTERNET STANDARD DRAFT STANDARD IETF sec otp 10.17487/RFC2289
RFC2290 Mobile-IPv4 Configuration Option for PPP IPCP J. Solomon S. Glass February 1998 ASCII 39421 17 Internet protocol point-to-point control address

Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. [STANDARDS-TRACK]

RFC2002 RFC2794 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2290
RFC2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web J. Slein F. Vitali E. Whitehead D. Durand February 1998 ASCII 44036 21 WWW remote editing locking mechanism

This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app webdav 10.17487/RFC2291
RFC2292 Advanced Sockets API for IPv6 W. Stevens M. Thomas February 1998 ASCII 152077 67 application program interface

The current document defines some the "advanced" features of the sockets API that are required for applications to take advantage of additional features of IPv6. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC3542 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2292
RFC2293 Representing Tables and Subtrees in the X.500 Directory S. Kille March 1998 ASCII 12539 8 SUBTABLE mapping distinguished name

This document defines techniques for representing two types of information mapping in the OSI Directory: Mapping from a key to a value (or set of values), as might be done in a table lookup, and mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. [STANDARDS-TRCK]

RFC1837 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2293
RFC2294 Representing the O/R Address hierarchy in the X.500 Directory Information Tree S. Kille March 1998 ASCII 22059 13 OR-ADD routing mapping dit

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. [STANDARDS-TRACK]

RFC1836 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2294
RFC2295 Transparent Content Negotiation in HTTP K. Holtman A. Mutz March 1998 ASCII 125130 58 TCN-HTTP Hyper Text Transfer protocol URL Uniform Resource Locators

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF app http 10.17487/RFC2295
RFC2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0 K. Holtman A. Mutz March 1998 ASCII 26932 13 HTTP-RVSA Hyper Text Transfer protocol URL Uniform Resource Locators

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF app http 10.17487/RFC2296
RFC2297 Ipsilon's General Switch Management Protocol Specification Version 2.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall March 1998 ASCII 280484 109 GSMP gsmp atm asynchronous transfer mode

This memo specifies enhancements to the General Switch Management Protocol (GSMP) [RFC1987]. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC1987 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2297
RFC2298 An Extensible Message Format for Message Disposition Notifications R. Fajman March 1998 ASCII 62059 28 EMF-MDN MDN media-type MIME multipurpose internet mail extensions

This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. [STANDARDS-TRACK]

RFC3798 PROPOSED STANDARD PROPOSED STANDARD IETF app receipt 10.17487/RFC2298
RFC2299 Request for Comments Summary A. Ramos January 1999 ASCII 51234 24 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2299 RFC2300 Internet Official Protocol Standards J. Postel May 1998 ASCII 128322 59 IAB official protocol standards

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

RFC2200 RFC2400 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2300
RFC2301 File Format for Internet Fax L. McIntyre S. Zilles R. Buckley D. Venable G. Parsons J. Rafferty March 1998 ASCII 200525 77 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. [STANDARDS-TRACK]

RFC3949 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2301
RFC2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration G. Parsons J. Rafferty S. Zilles March 1998 ASCII 14375 8 TIFF Multipurpose Internet Mail extensions

This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]

RFC3302 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2302
RFC2303 Minimal PSTN address format in Internet Mail C. Allocchio March 1998 ASCII 14625 8 MIN-PSTN e-mail service

This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK]

RFC3191 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2303
RFC2304 Minimal FAX address format in Internet Mail C. Allocchio March 1998 ASCII 13236 8 MINFAX-IM encoding facsimile e-mail

This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS-TRACK]

RFC3192 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2304
RFC2305 A Simple Mode of Facsimile Using Internet Mail K. Toyoda H. Ohno J. Murai D. Wing March 1998 ASCII 24624 13 SMFAX-IM data file format e-mail

This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK]

RFC3965 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2305
RFC2306 Tag Image File Format (TIFF) - F Profile for Facsimile G. Parsons J. Rafferty March 1998 ASCII 59358 25 file format storage

This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2306
RFC2307 An Approach for Using LDAP as a Network Information Service L. Howard March 1998 ASCII 41396 21 LDAP-NIS lightweight directory access protocol unix mapping

This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2307 10.17487/RFC2307
RFC2308 Negative Caching of DNS Queries (DNS NCACHE) M. Andrews March 1998 ASCII 41428 19 DNS-NCACHE Domain Name System negative

RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]

RFC1034 RFC1035 RFC4035 RFC4033 RFC4034 RFC6604 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2308 10.17487/RFC2308
RFC2309 Recommendations on Queue Management and Congestion Avoidance in the Internet B. Braden D. Clark J. Crowcroft B. Davie S. Deering D. Estrin S. Floyd V. Jacobson G. Minshall C. Partridge L. Peterson K. Ramakrishnan S. Shenker J. Wroclawski L. Zhang April 1998 ASCII 38079 17 performance router deployment

This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC7567 RFC7141 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2309
RFC2310 The Safe Response Header Field K. Holtman April 1998 ASCII 8091 5 http hyper text transfer protocol

This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF app http 10.17487/RFC2310
RFC2311 S/MIME Version 2 Message Specification S. Dusse P. Hoffman B. Ramsdell L. Lundblade L. Repka March 1998 ASCII 70901 37 SMIME-MSG secure multipurpose internet mail extensions

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC2311
RFC2312 S/MIME Version 2 Certificate Handling S. Dusse P. Hoffman B. Ramsdell J. Weinstein March 1998 ASCII 39829 20 SMIME-CERT secure multipurpose internet mail extensions

This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC2312
RFC2313 PKCS #1: RSA Encryption Version 1.5 B. Kaliski March 1998 ASCII 37777 19 PKCS-1 data public key cryptosystem

This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2437 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2313
RFC2314 PKCS #10: Certification Request Syntax Version 1.5 B. Kaliski March 1998 ASCII 15814 8 PKCS-10 public key distinguished name encryption data

This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2986 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2314
RFC2315 PKCS #7: Cryptographic Message Syntax Version 1.5 B. Kaliski March 1998 ASCII 69679 32 PKCS-7 data authentication PEM privacy enhanced mail

This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2315
RFC2316 Report of the IAB Security Architecture Workshop S. Bellovin April 1998 ASCII 19733 9 Internet Board protocols tools

On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2316
RFC2317 Classless IN-ADDR.ARPA delegation H. Eidnes G. de Groot P. Vixie March 1998 ASCII 17744 10 routing mapping addresses zone files

This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0020 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2317 10.17487/RFC2317
RFC2318 The text/css Media Type H. Lie B. Bos C. Lilley March 1998 ASCII 7819 5 TEXT-CSS MIME multipurpose Internet mail extension

This memo provides information about the text/css Media Type. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2318
RFC2319 Ukrainian Character Set KOI8-U KOI8-U Working Group April 1998 ASCII 18042 9 KOI8-U encoding mail information resources

This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2319 10.17487/RFC2319
RFC2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB) M. Greene J. Luciani K. White T. Kuo April 1998 ASCII 102116 52 IPOA-MIB management information base internet protocol address resolution asynchronous transfer mode

The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2320
RFC2321 RITA -- The Reliable Internetwork Troubleshooting Agent A. Bressen April 1 1998 ASCII 12302 6 networking environments

A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2321
RFC2322 Management of IP numbers by peg-dhcp K. van den Hout A. Koopal R. van Mook April 1 1998 ASCII 12665 7 Internet Protocol HIP Hacking in progress

This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2322
RFC2323 IETF Identification and Security Guidelines A. Ramos April 1 1998 ASCII 9257 5 facial hairius extremis FHE

This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2323
RFC2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) L. Masinter April 1 1998 ASCII 19610 10 controlling monitoring diagnosing

This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC7168 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2324 10.17487/RFC2324
RFC2325 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2 M. Slavitch April 1 1998 ASCII 12726 8 MIB management information base coffee brewing

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2325 10.17487/RFC2325
RFC2326 Real Time Streaming Protocol (RTSP) H. Schulzrinne A. Rao R. Lanphier April 1998 ASCII 195010 92 RTSP audio video data delivery application level,

The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=2326 10.17487/RFC2326
RFC2327 SDP: Session Description Protocol M. Handley V. Jacobson April 1998 ASCII 87096 42 SDP mbone internet multicast backbone multimedia

This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]

RFC4566 RFC3266 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=2327 10.17487/RFC2327
RFC2328 OSPF Version 2 J. Moy April 1998 ASCII 447367 244 OSPF2 Open Shortest Path First routing Autonomous system AS

This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]

RFC2178 RFC5709 RFC6549 RFC6845 RFC6860 RFC7474 STD0054 INTERNET STANDARD INTERNET STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2328 10.17487/RFC2328
RFC2329 OSPF Standardization Report J. Moy April 1998 ASCII 15130 9 open shortest path first

This memo documents how the requirements for advancing a routing protocol to Full Standard have been met for OSPFv2. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC2329
RFC2330 Framework for IP Performance Metrics V. Paxson G. Almes J. Mahdavi M. Mathis May 1998 ASCII 94387 40 Internet Protocol measurement statistics

The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC7312 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC2330
RFC2331 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update M. Maher April 1998 ASCII 61119 26 UNI-SIG asynchronous transfer mode internet protocol

This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 to support IP over ATM environments as described in RFC 2225 and in RFC 2332. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2331
RFC2332 NBMA Next Hop Resolution Protocol (NHRP) J. Luciani D. Katz D. Piscitello B. Cole N. Doraswamy April 1998 ASCII 126978 52 NHRP internetworking layer address subnetwork multiprotocol non-broadcast multiple access

This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2332
RFC2333 NHRP Protocol Applicability Statement D. Cansever April 1998 ASCII 20164 9 next hop resolution protocol routing internet protocol

As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2333
RFC2334 Server Cache Synchronization Protocol (SCSP) J. Luciani G. Armitage J. Halpern N. Doraswamy April 1998 ASCII 98161 40 SCSP cache synchronization replication NBMA non broadcast multiple access

This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion http://www.rfc-editor.org/errata_search.php?rfc=2334 10.17487/RFC2334
RFC2335 A Distributed NHRP Service Using SCSP J. Luciani April 1998 ASCII 14007 7 NHRP-SCSP next hop resolution protocol server cache sychronization protocol

This document describes a method for distributing an NHRP service within a LIS. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2335
RFC2336 Classical IP and ARP over ATM to NHRP Transition J. Luciani July 1998 ASCII 10500 5

This document describes methods and procedures for the graceful transition from an ATMARP LIS to an NHRP LIS network model over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2336
RFC2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM D. Farinacci D. Meyer Y. Rekhter April 1998 ASCII 16357 8 internet protocol asynchronous transfer mode

This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2337
RFC2338 Virtual Router Redundancy Protocol S. Knight D. Weaver D. Whipple R. Hinden D. Mitzel P. Hunt P. Higginson M. Shand A. Lindem April 1998 ASCII 59871 27 VRRP vrrp lan local area network ip internet protocol

This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. [STANDARDS-TRACK]

RFC3768 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp 10.17487/RFC2338
RFC2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols The Internet Society Sun Microsystems May 1998 ASCII 10745 5 ISOC network file system internet engineering task force

This Request for Comments records an agreement between Sun Microsystems, Inc. and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2339
RFC2340 Nortel's Virtual Network Switching (VNS) Overview B. Jamoussi D. Jamieson D. Williston S. Gabe May 1998 ASCII 30731 14 routing packet switching multi-protocol

This document provides an overview of Virtual Network Switching (VNS). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2340
RFC2341 Cisco Layer Two Forwarding (Protocol) "L2F" A. Valencia M. Littlewood T. Kolar May 1998 ASCII 66592 29 L2F tunneling dial-up network

This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind.

HISTORIC HISTORIC Legacy 10.17487/RFC2341
RFC2342 IMAP4 Namespace M. Gahrns C. Newman May 1998 ASCII 19489 10 IMAP4NAME internet message access protocol mailbox

This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS-TRACK]

RFC4466 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2342
RFC2343 RTP Payload Format for Bundled MPEG M. Civanlar G. Cash B. Haskell May 1998 ASCII 16557 8 RTP-MPEG real-time transport protocol audio video

This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC2343
RFC2344 Reverse Tunneling for Mobile IP G. Montenegro Editor May 1998 ASCII 39468 19 MOBILIPREV internet protocol extensions home foreign agent encapsulating delivery style

This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. [STANDARDS-TRACK]

RFC3024 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2344
RFC2345 Domain Names and Company Name Retrieval J. Klensin T. Wolf G. Oglesby May 1998 ASCII 29707 14 URL mapping service whois dns

This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2345
RFC2346 Making Postscript and PDF International J. Palme May 1998 ASCII 12382 6 portable document format document

Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable Document Format (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world. North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2346
RFC2347 TFTP Option Extension G. Malkin A. Harkin May 1998 ASCII 13060 7 TFTP-Ext trivial file transfer booting client server

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. [STANDARDS-TRACK]

RFC1782 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2347 10.17487/RFC2347
RFC2348 TFTP Blocksize Option G. Malkin A. Harkin May 1998 ASCII 9515 5 TFTP-Blk trivial file transfer booting client server extension

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]

RFC1783 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2348
RFC2349 TFTP Timeout Interval and Transfer Size Options G. Malkin A. Harkin May 1998 ASCII 7848 5 TFTP-Opt trivial file transfer booting client server extension

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes two TFTP options. [STANDARDS-TRACK]

RFC1784 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2349
RFC2350 Expectations for Computer Security Incident Response N. Brownlee E. Guttman June 1998 ASCII 86545 38 CSIRT guidelines user BCP0021 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip http://www.rfc-editor.org/errata_search.php?rfc=2350 10.17487/RFC2350 RFC2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP A. Robert May 1998 ASCII 43440 23 internet protocol encapsulation transactional traffic messaging

This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2351
RFC2352 A Convention For Using Legal Names as Domain Names O. Vaughan May 1998 ASCII 16354 8 DNS

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2240 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2352
RFC2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document G. Dudley May 1998 ASCII 116972 48 internet protocol advanced peer-to-peer networking high performance routing

This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2353
RFC2354 Options for Repair of Streaming Media C. Perkins O. Hodson June 1998 ASCII 28876 12 packets UDP user datagram protocol

This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC2354
RFC2355 TN3270 Enhancements B. Kelly June 1998 ASCII 89394 38 TN3270E Telnet option client

This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. [STANDARDS-TRACK]

RFC1647 RFC6270 DRAFT STANDARD DRAFT STANDARD IETF app tn3270e 10.17487/RFC2355
RFC2356 Sun's SKIP Firewall Traversal for Mobile IP G. Montenegro V. Gupta June 1998 ASCII 53198 24 Internet Protocol security traffic

The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int mobileip 10.17487/RFC2356
RFC2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols A. Mankin A. Romanow S. Bradner V. Paxson June 1998 ASCII 24130 11 internet engineering task force rmtp procedures

This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2357
RFC2358 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick J. Johnson June 1998 ASCII 87891 39 MIB Management Information Base 802.3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1650 "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. [STANDARDS-TRACK]

RFC1650 RFC2665 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2358
RFC2359 IMAP4 UIDPLUS extension J. Myers June 1998 ASCII 10862 6 IMAP4UIDPL internet message access protocol disconnected operation

The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]

RFC4315 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2359
RFC2360 Guide for Internet Standards Writers G. Scott June 1998 ASCII 47280 20 specification multiple implementations

This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0022 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF stdguide 10.17487/RFC2360
RFC2361 WAVE and AVI Codec Registries E. Fleischman June 1998 ASCII 97796 71 multimedia parameter audio video microsoft

The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2361 10.17487/RFC2361
RFC2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification D. Estrin D. Farinacci A. Helmy D. Thaler S. Deering M. Handley V. Jacobson C. Liu P. Sharma L. Wei June 1998 ASCII 159833 66 PIM-SM] routing message type timers flags

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

RFC2117 RFC4601 RFC5059 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=2362 10.17487/RFC2362
RFC2363 PPP Over FUNI G. Gross M. Kaycee A. Li A. Malis J. Stephens July 1998 ASCII 22576 12 PPP-FUNI point-to-point protocol atm synchronous transfer mode frame user network interface

This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2363
RFC2364 PPP Over AAL5 G. Gross M. Kaycee A. Li A. Malis J. Stephens July 1998 ASCII 23539 12 PPP-AAL point-to-point protocol link control network-layer authentication compression

This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2364
RFC2365 Administratively Scoped IP Multicast D. Meyer July 1998 ASCII 17770 8 internet protocol IPv4 ipv6 address classes

This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0023 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC2365
RFC2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks C. Chung M. Greene July 1998 ASCII 134312 76 MIB management information base asynchronous transfer mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks'. [STANDARDS-TRACK]

RFC2417 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2366
RFC2367 PF_KEY Key Management API, Version 2 D. McDonald C. Metz B. Phan July 1998 ASCII 146754 68 IP internet protocol security application programming interface

A generic key management API that can be used not only for IP Security but also for other network security services is presented in this document. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2367
RFC2368 The mailto URL scheme P. Hoffman L. Masinter J. Zawinski July 1998 ASCII 16502 10 URLMAILTO uniform resource locator electronic mail addresses

This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK]

RFC6068 RFC1738 RFC1808 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2368
RFC2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields G. Neufeld J. Baer July 1998 ASCII 30853 15 uniform resource locator email header fields

The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2369
RFC2370 The OSPF Opaque LSA Option R. Coltun July 1998 ASCII 33789 15 OSPF-LSA] open shortest path first link state advertisement

This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]

RFC5250 RFC3630 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC2370
RFC2371 Transaction Internet Protocol Version 3.0 J. Lyon K. Evans J. Klein July 1998 ASCII 71399 31 TIPV3 TIP commit protocol electronic commerce

In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app tip 10.17487/RFC2371
RFC2372 Transaction Internet Protocol - Requirements and Supplemental Information K. Evans J. Klein J. Lyon July 1998 ASCII 53699 24 TIP commit protocol electronic commerce

This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app tip 10.17487/RFC2372
RFC2373 IP Version 6 Addressing Architecture R. Hinden S. Deering July 1998 ASCII 52526 26 internet protocol unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]

RFC1884 RFC3513 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2373 10.17487/RFC2373
RFC2374 An IPv6 Aggregatable Global Unicast Address Format R. Hinden M. O'Dell S. Deering July 1998 ASCII 25068 12 internet protocol architecture routing

This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]

RFC2073 RFC3587 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2374
RFC2375 IPv6 Multicast Address Assignments R. Hinden S. Deering July 1998 ASCII 14356 8 internet protocol multicast scope value

This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2375
RFC2376 XML Media Types E. Whitehead M. Murata July 1998 ASCII 32143 15 extensible markup language web authority hypertext transfer protocol

This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC3023 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2376
RFC2377 Naming Plan for Internet Directory-Enabled Applications A. Grimstad R. Huber S. Sataluri M. Wahl September 1998 ASCII 38274 18 x.500 applications iwps white pages service

Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC4519 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2377
RFC2378 The CCSO Nameserver (Ph) Architecture R. Hedberg P. Pomes September 1998 ASCII 38960 22 computing communications services office database

The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2378
RFC2379 RSVP over ATM Implementation Guidelines L. Berger August 1998 ASCII 15174 8 asynchronous transfer mode resource reservation protocol switched circuits

This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0024 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv issll 10.17487/RFC2379
RFC2380 RSVP over ATM Implementation Requirements L. Berger August 1998 ASCII 31234 14 resource reservation protocol asynchronous transfer mode switched circuits

This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2380
RFC2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM M. Garrett M. Borden August 1998 ASCII 107299 43 asynchronous transfer mode mapping traffic parameters

This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2381
RFC2382 A Framework for Integrated Services and RSVP over ATM E. Crawley Editor L. Berger S. Berson F. Baker M. Borden J. Krawczyk August 1998 ASCII 73865 30

This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2382
RFC2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version M. Suzuki August 1998 ASCII 99889 50 asynchronous transfer mode stream resource reservation

This document specifies an ATM-based protocol for communication between ST2+ agents. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2383
RFC2384 POP URL Scheme R. Gellens August 1998 ASCII 13649 8 POP-URL post office protocol uniform resource identifier string encapsulation

This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2384 10.17487/RFC2384
RFC2385 Protection of BGP Sessions via the TCP MD5 Signature Option A. Heffernan August 1998 ASCII 12315 6 border gateway protocol transmission control message digest algorithm

This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]

RFC5925 RFC6691 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2385
RFC2386 A Framework for QoS-based Routing in the Internet E. Crawley R. Nair B. Rajagopalan H. Sandick August 1998 ASCII 93459 37 quality of service interdomain intradomain

This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg qosr 10.17487/RFC2386
RFC2387 The MIME Multipart/Related Content-type E. Levinson August 1998 ASCII 18864 10 MIME-RELAT multipurpose internet mail extensions body parts media-type

This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]

RFC2112 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2387 10.17487/RFC2387
RFC2388 Returning Values from Forms: multipart/form-data L. Masinter August 1998 ASCII 16531 9 media-type multipurpose internet mail extensions

This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]

RFC7578 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2388 10.17487/RFC2388
RFC2389 Feature negotiation mechanism for the File Transfer Protocol P. Hethmon R. Elz August 1998 ASCII 18536 9 FTP catalogue

This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. [STANDARDS-TRACK]

RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext 10.17487/RFC2389
RFC2390 Inverse Address Resolution Protocol T. Bradley C. Brown A. Malis September 1998 ASCII 20849 10 IARP iarp hardware frame relay

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

RFC1293 DRAFT STANDARD DRAFT STANDARD IETF int ion 10.17487/RFC2390
RFC2391 Load Sharing using IP Network Address Translation (LSNAT) P. Srisuresh D. Gan August 1998 ASCII 44884 18 internet protocol datagram server

In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2391 10.17487/RFC2391
RFC2392 Content-ID and Message-ID Uniform Resource Locators E. Levinson August 1998 ASCII 11141 6 CIDMID-URL Hyper Text Markup Language URL MIME

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]

RFC2111 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2392 10.17487/RFC2392
RFC2393 IP Payload Compression Protocol (IPComp) A. Shacham R. Monsour R. Pereira M. Thomas December 1998 ASCII 20757 10 IPCOMP internet protocol datagram lossless

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]

RFC3173 PROPOSED STANDARD PROPOSED STANDARD IETF int ippcp 10.17487/RFC2393
RFC2394 IP Payload Compression Using DEFLATE R. Pereira December 1998 ASCII 11053 6 internet protocol algorithm datagram format

This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ippcp 10.17487/RFC2394
RFC2395 IP Payload Compression Using LZS R. Friend R. Monsour December 1998 ASCII 14882 9 internet protocol algorithm datagram lossless

This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ippcp http://www.rfc-editor.org/errata_search.php?rfc=2395 10.17487/RFC2395
RFC2396 Uniform Resource Identifiers (URI): Generic Syntax T. Berners-Lee R. Fielding L. Masinter August 1998 ASCII 83639 40 URI-GEN characters string absolute relative

This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. [STANDARDS-TRACK]

RFC3986 RFC1808 RFC1738 RFC2732 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2396 10.17487/RFC2396
RFC2397 The "data" URL scheme L. Masinter August 1998 ASCII 9514 5 DATA-URL uniform resource identifiers media type

A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2397 10.17487/RFC2397
RFC2398 Some Testing Tools for TCP Implementors S. Parker C. Schmechel August 1998 ASCII 24107 15 transmission control protocol catalogue

This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

FYI0033 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2398
RFC2399 Request for Comments Summary A. Ramos January 1999 ASCII 45853 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2399 RFC2400 Internet Official Protocol Standards J. Postel J. Reynolds September 1998 ASCII 110969 47 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK]

RFC2300 RFC2500 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2400
RFC2401 Security Architecture for the Internet Protocol S. Kent R. Atkinson November 1998 ASCII 168162 66 IPSEC ipsec authentication encapsulation IP IPv4 IPv6 IP-layer

This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]

RFC1825 RFC4301 RFC3168 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2401
RFC2402 IP Authentication Header S. Kent R. Atkinson November 1998 ASCII 52831 22 IP-AUTH ipsec Internet Protocol AH security IPv4 IPv6

The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK]

RFC1826 RFC4302 RFC4305 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2402
RFC2403 The Use of HMAC-MD5-96 within ESP and AH C. Madson R. Glenn November 1998 ASCII 13578 7 ipsec authentication mechanism header security architecture

This memo describes the use of the HMAC algorithm in conjunction with the MD5 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2403
RFC2404 The Use of HMAC-SHA-1-96 within ESP and AH C. Madson R. Glenn November 1998 ASCII 13089 7 ipsec authentication mechanism header security architecture payload

This memo describes the use of the HMAC algorithm in conjunction with the SHA-1 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2404
RFC2405 The ESP DES-CBC Cipher Algorithm With Explicit IV C. Madson N. Doraswamy November 1998 ASCII 20208 10 ESPDES-CBC ipsec payload security architecture encryption

This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2405
RFC2406 IP Encapsulating Security Payload (ESP) S. Kent R. Atkinson November 1998 ASCII 54202 22 ESP ipsec internet protocol encapsulating security ipv4 ipv6

The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]

RFC1827 RFC4303 RFC4305 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2406
RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP D. Piper November 1998 ASCII 67878 32 ISAKMPSEC ipsec internet protocol security association key management

This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK]

RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2407 10.17487/RFC2407
RFC2408 Internet Security Association and Key Management Protocol (ISAKMP) D. Maughan M. Schertler M. Schneider J. Turner November 1998 ASCII 209175 86 ISAKMP ipsec cryptography authentication

This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. [STANDARDS-TRACK]

RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2408
RFC2409 The Internet Key Exchange (IKE) D. Harkins D. Carrel November 1998 ASCII 94949 41 IKE ipsec oakley authentication isakmp internet security key management

This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]

RFC4306 RFC4109 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2409
RFC2410 The NULL Encryption Algorithm and Its Use With IPsec R. Glenn S. Kent November 1998 ASCII 11239 6 ipsec internet protocol security esp encapsulating payload

This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2410 10.17487/RFC2410
RFC2411 IP Security Document Roadmap R. Thayer N. Doraswamy R. Glenn November 1998 ASCII 22983 11 ipsec internet protocol privacy authentication

This document is intended to provide guidelines for the development of collateral specifications describing the use of new encryption and authentication algorithms with the ESP protocol, described in and new authentication algorithms used with the AH protocol. This memo provides information for the Internet community.

RFC6071 INFORMATIONAL INFORMATIONAL IETF sec ipsec 10.17487/RFC2411
RFC2412 The OAKLEY Key Determination Protocol H. Orman November 1998 ASCII 118649 55 ipsec authentication crytographic secure scalable

This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2412 10.17487/RFC2412
RFC2413 Dublin Core Metadata for Resource Discovery S. Weibel J. Kunze C. Lagoze M. Wolf September 1998 ASCII 15501 8 workshop electronic librarians network

This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community.

RFC5013 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2413
RFC2414 Increasing TCP's Initial Window M. Allman S. Floyd C. Partridge September 1998 ASCII 32019 14 TCP-WIN transmission control protocol

This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This memo defines an Experimental Protocol for the Internet community.

RFC3390 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpimpl 10.17487/RFC2414
RFC2415 Simulation Studies of Increased Initial TCP Window Size K. Poduri K. Nichols September 1998 ASCII 24205 11 transmission control protocol file transfer

This document covers some simulation studies of the effects of increasing the initial window size of TCP. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2415
RFC2416 When TCP Starts Up With Four Packets Into Only Three Buffers T. Shepard C. Partridge September 1998 ASCII 12663 7 transmission control protocol performance

This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2416
RFC2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks C. Chung M. Greene September 1998 ASCII 134862 76 MIB management information base asynchronous transfer mode

This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. [STANDARDS-TRACK]

RFC2366 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2417 10.17487/RFC2417
RFC2418 IETF Working Group Guidelines and Procedures S. Bradner September 1998 ASCII 62857 26 BCP WG escape clause procedures

This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1603 RFC3934 RFC7475 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson http://www.rfc-editor.org/errata_search.php?rfc=2418 10.17487/RFC2418
RFC2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis) K. Sklower G. Meyer September 1998 ASCII 24414 12 DESE-bis point-to-point protocol ecp control

This document provides specific details for the use of the DES standard for encrypting PPP encapsulated packets. [STANDARDS-TRACK]

RFC1969 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2419
RFC2420 The PPP Triple-DES Encryption Protocol (3DESE) H. Kummert September 1998 ASCII 16729 8 3DESE point-to-point protocol ecp control

This document provides specific details for the use of the Triple-DES standard (3DES) for encrypting PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2420
RFC2421 Voice Profile for Internet Mail - version 2 G. Vaudreuil G. Parsons September 1998 ASCII 123663 56 MIME-VP2 vpim messaging

This document profiles Internet mail for voice messaging. [STANDARDS-TRACK]

RFC1911 RFC3801 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2421 10.17487/RFC2421
RFC2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration G. Vaudreuil G. Parsons September 1998 ASCII 10157 6 MIME-ADPCM multipurpose internet mail extensions audio

This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]

RFC1911 RFC3802 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2422
RFC2423 VPIM Voice Message MIME Sub-type Registration G. Vaudreuil G. Parsons September 1998 ASCII 10729 6 MIME-VPIM multipurpose internet mail extensions profiles

This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]

RFC1911 RFC3801 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2423
RFC2424 Content Duration MIME Header Definition G. Vaudreuil G. Parsons September 1998 ASCII 7116 4 CONT-DUR multipurpose internet mail extensions time media

This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]

RFC3803 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2424
RFC2425 A MIME Content-Type for Directory Information T. Howes M. Smith F. Dawson September 1998 ASCII 64478 33 TXT-DIR multipurpose internet mail extensions profiles

This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]

RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2425
RFC2426 vCard MIME Directory Profile F. Dawson T. Howes September 1998 ASCII 74646 42 MIME-VCARD multipurpose internet mail extensions white-pages electronic business card

This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK]

RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2426 10.17487/RFC2426
RFC2427 Multiprotocol Interconnect over Frame Relay C. Brown A. Malis September 1998 ASCII 74671 34 IP-FR standard standards IP over

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]

RFC1490 RFC1294 STD0055 INTERNET STANDARD INTERNET STANDARD IETF int ion 10.17487/RFC2427
RFC2428 FTP Extensions for IPv6 and NATs M. Allman S. Ostermann C. Metz September 1998 ASCII 16028 8 file transfer protocol internet network address translators

This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext 10.17487/RFC2428
RFC2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) C. Bormann L. Cline G. Deisher T. Gardos C. Maciocco D. Newell J. Ott G. Sullivan S. Wenger C. Zhu October 1998 ASCII 43166 17 real time transport protocol multicast unicast

This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK]

RFC4629 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2429
RFC2430 A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) T. Li Y. Rekhter October 1998 ASCII 40148 16 isp internet service provider packet flow multiprotocol label switching mpls resource reservation protocol rsvp

This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2430
RFC2431 RTP Payload Format for BT.656 Video Encoding D. Tynan October 1998 ASCII 22323 10 real time transport protocol itu multicast unicast

This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2431
RFC2432 Terminology for IP Multicast Benchmarking K. Dubray October 1998 ASCII 29758 16 internet protocol network forwarding devices

The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2432
RFC2433 Microsoft PPP CHAP Extensions G. Zorn S. Cobb October 1998 ASCII 34502 20 point to point protocol challenge handshake authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2433
RFC2434 Guidelines for Writing an IANA Considerations Section in RFCs T. Narten H. Alvestrand October 1998 ASCII 25092 11 internet assigned numbers authority values implementations

This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC5226 RFC3692 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2434
RFC2435 RTP Payload Format for JPEG-compressed Video L. Berc W. Fenner R. Frederick S. McCanne P. Stewart October 1998 ASCII 54173 27 Real Time Transport Protocol Joint Photographic Experts Group

This memo describes the RTP payload format for JPEG video streams. [STANDARDS-TRACK]

RFC2035 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=2435 10.17487/RFC2435
RFC2436 Collaboration between ISOC/IETF and ITU-T R. Brett S. Bradner G. Parsons October 1998 ASCII 31154 14 internet society engineering task force

This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community.

RFC3356 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2436
RFC2437 PKCS #1: RSA Cryptography Specifications Version 2.0 B. Kaliski J. Staddon October 1998 ASCII 73529 39 data public key cryptosystem

This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community.

RFC2313 RFC3447 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2437
RFC2438 Advancement of MIB specifications on the IETF Standards Track M. O'Dell H. Alvestrand B. Wijnen S. Bradner October 1998 ASCII 13633 7 management information base internet engineering task force

This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0027 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2438
RFC2439 BGP Route Flap Damping C. Villamizar R. Chandra R. Govindan November 1998 ASCII 86376 37 Border Gateway Protocol IDRP Internet-Domain Routing

A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2439 10.17487/RFC2439
RFC2440 OpenPGP Message Format J. Callas L. Donnerhacke H. Finney R. Thayer November 1998 ASCII 141371 65 pretty good privacy encryption authentication

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK]

RFC4880 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp 10.17487/RFC2440
RFC2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998 D. Cohen November 1998 ASCII 11992 6 Jonathan B Postel

This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2441
RFC2442 The Batch SMTP Media Type N. Freed D. Newman J. Belissent M. Hoy November 1998 ASCII 18384 9 simple transfer protocol mime multipurpose internet mail extensions tunneling

This document defines a MIME content type suitable for tunneling an ESMTP transaction through any MIME-capable transport. This memo provides information for the Internet community

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2442
RFC2443 A Distributed MARS Service Using SCSP J. Luciani A. Gallo November 1998 ASCII 41451 18 MARS-SCSP server cache syncronization protocol atm asynchronous transfer mode

This document describes a method for distributing a MARS service within a LIS. This method uses the Server Cache Synchronization Protocol (SCSP) to synchronize the MARS Server databases within a LIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG). [STANDARDS-TRACK]

EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2443
RFC2444 The One-Time-Password SASL Mechanism C. Newman October 1998 ASCII 13408 7 OTP-SASL otp simple authentication security layer

OTP provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL mechanism so it can be easily and formally integrated into many application protocols. [STANDARDS-TRACK]

RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC2444
RFC2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar) F. Dawson D. Stenerson November 1998 ASCII 291838 148 ICALENDAR internet interoperable mime multipurpose mail extensions

This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [STANDARDS-TRACK]

RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch http://www.rfc-editor.org/errata_search.php?rfc=2445 10.17487/RFC2445
RFC2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries S. Silverberg S. Mansour F. Dawson R. Hopson November 1998 ASCII 225964 109 ITIP internet systems interoperability

This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. [STANDARDS-TRACK]

RFC5546 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch http://www.rfc-editor.org/errata_search.php?rfc=2446 10.17487/RFC2446
RFC2447 iCalendar Message-Based Interoperability Protocol (iMIP) F. Dawson S. Mansour S. Silverberg November 1998 ASCII 33480 18 IMIP internet electronic mail transport

This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. [STANDARDS-TRACK]

RFC6047 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch 10.17487/RFC2447
RFC2448 AT&T's Error Resilient Video Transmission Technique M. Civanlar G. Cash B. Haskell November 1998 ASCII 14655 7 packets network bitstreams

This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2448
RFC2449 POP3 Extension Mechanism R. Gellens C. Newman L. Lundblade November 1998 ASCII 36017 19 POP3-EXT post office protocol server

This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]

RFC1939 RFC5034 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2449
RFC2450 Proposed TLA and NLA Assignment Rule R. Hinden December 1998 ASCII 24486 11 top-level aggregation identifiers next-level ipv6 internet protocols addresses

This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2450
RFC2451 The ESP CBC-Mode Cipher Algorithms R. Pereira R. Adams November 1998 ASCII 26400 14 ipsec encapsulating security payload

This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2451
RFC2452 IP Version 6 Management Information Base for the Transmission Control Protocol M. Daniele December 1998 ASCII 19066 10 mib internet protocol tcp ipv6

This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). [STANDARDS-TRACK]

RFC4022 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2452
RFC2453 RIP Version 2 G. Malkin November 1998 ASCII 98462 39 RIP2 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]

RFC1723 RFC4822 STD0056 INTERNET STANDARD INTERNET STANDARD IETF rtg ripv2 http://www.rfc-editor.org/errata_search.php?rfc=2453 10.17487/RFC2453
RFC2454 IP Version 6 Management Information Base for the User Datagram Protocol M. Daniele December 1998 ASCII 15862 9 mib internet protocol udp ipv6

This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). [STANDARDS-TRACK]

RFC4113 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2454
RFC2455 Definitions of Managed Objects for APPN B. Clouston B. Moore November 1998 ASCII 251061 140 APPN-MIB mib management information base advanced peer-to-peer networking

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]

RFC2155 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2455
RFC2456 Definitions of Managed Objects for APPN TRAPS B. Clouston B. Moore November 1998 ASCII 44023 21 mib management information base advanced peer-to-peer networking

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2456
RFC2457 Definitions of Managed Objects for Extended Border Node B. Clouston B. Moore November 1998 ASCII 54380 28 EBN-MIB mib management information base ebn

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2457
RFC2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations H. Lu M. Krishnaswamy L. Conroy S. Bellovin F. Burg A. DeSimone K. Tewani P. Davidson H. Schulzrinne K. Vishwanathan November 1998 ASCII 139100 60

This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF tsv pint 10.17487/RFC2458
RFC2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile R. Housley W. Ford W. Polk D. Solo January 1999 ASCII 278438 129 digital signatures encryption authentication

This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]

RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2459 10.17487/RFC2459
RFC2460 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden December 1998 ASCII 85490 39 IPV6 internet protocol next generation ipng

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]

RFC1883 RFC5095 RFC5722 RFC5871 RFC6437 RFC6564 RFC6935 RFC6946 RFC7045 RFC7112 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2460 10.17487/RFC2460
RFC2461 Neighbor Discovery for IP Version 6 (IPv6) T. Narten E. Nordmark W. Simpson December 1998 ASCII 222516 93 IPV6-ND internet protocol link-layer

This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]

RFC1970 RFC4861 RFC4311 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg 10.17487/RFC2461
RFC2462 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten December 1998 ASCII 61210 25 IPV6-AUTO internet protocol host link-local

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]

RFC1971 RFC4862 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2462 10.17487/RFC2462
RFC2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification A. Conta S. Deering December 1998 ASCII 34190 18 ICMPv6 internet protocol link-local autoconfigured addresses

This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

RFC1885 RFC4443 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg 10.17487/RFC2463
RFC2464 Transmission of IPv6 Packets over Ethernet Networks M. Crawford December 1998 ASCII 12725 7 internet protocol link-local autoconfigured addresses

This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]

RFC1972 RFC6085 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2464 10.17487/RFC2464
RFC2465 Management Information Base for IP Version 6: Textual Conventions and General Group D. Haskin S. Onishi December 1998 ASCII 77339 38 mib internet protocol ipv6

This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. [STANDARDS-TRACK]

RFC4293 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2465
RFC2466 Management Information Base for IP Version 6: ICMPv6 Group D. Haskin S. Onishi December 1998 ASCII 27547 16 ICMPv6-MIB mib internet protocol ipv6

This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. [STANDARDS-TRACK]

RFC4293 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2466
RFC2467 Transmission of IPv6 Packets over FDDI Networks M. Crawford December 1998 ASCII 16028 9 internet protocol link-local addresses autoconfiguration

This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS-TRACK]

RFC2019 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2467
RFC2468 I REMEMBER IANA V. Cerf October 1998 ASCII 8543 4 jonathan b postel

A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2468
RFC2469 A Caution On The Canonical Ordering Of Link-Layer Addresses T. Narten C. Burton December 1998 ASCII 9948 5 address resolution protocol data fields

Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2469
RFC2470 Transmission of IPv6 Packets over Token Ring Networks M. Crawford T. Narten S. Thomas December 1998 ASCII 21677 11 internet protocol frame format link-local addresses

This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2470
RFC2471 IPv6 Testing Address Allocation R. Hinden R. Fink J. Postel December 1998 ASCII 8031 5 internet protocol protocotype software architecture

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community.

RFC1897 RFC3701 HISTORIC EXPERIMENTAL IETF int ipngwg 10.17487/RFC2471
RFC2472 IP Version 6 over PPP D. Haskin E. Allen December 1998 ASCII 29696 14 IPv6-PPP internet protocol point-to-point ipv6

This document defines the method for transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. [STANDARDS-TRACK]

draft-ietf-ipngwg-ipv6-over-ppp-06 RFC2023 RFC5072 RFC5172 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2472
RFC2473 Generic Packet Tunneling in IPv6 Specification A. Conta S. Deering December 1998 ASCII 77956 36 internet protocol encapsulation

This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2473
RFC2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers K. Nichols S. Blake F. Baker D. Black December 1998 ASCII 50576 20 internet protocol network nodes

This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]

RFC1455 RFC1349 RFC0791 RFC3168 RFC3260 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2474 10.17487/RFC2474
RFC2475 An Architecture for Differentiated Services S. Blake D. Black M. Carlson E. Davies Z. Wang W. Weiss December 1998 ASCII 94786 36 DIFFSRV] scalability IP internet protocol

This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.

RFC3260 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC2475
RFC2476 Message Submission R. Gellens J. Klensin December 1998 ASCII 30050 15 smtp simple mail transfer protocol user agent

This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK]

RFC4409 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2476
RFC2477 Criteria for Evaluating Roaming Protocols B. Aboba G. Zorn January 1999 ASCII 23530 12 ISP internet service providers operations

This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2477
RFC2478 The Simple and Protected GSS-API Negotiation Mechanism E. Baize D. Pinkas December 1998 ASCII 35581 18 generic service application security program interface

This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS-TRACK]

RFC4178 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2478
RFC2479 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) C. Adams December 1998 ASCII 156070 70 data unit authentication

The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF sec cat 10.17487/RFC2479
RFC2480 Gateways and MIME Security Multiparts N. Freed January 1999 ASCII 11751 6 mutltipurpose internet mail extensions

This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2480
RFC2481 A Proposal to add Explicit Congestion Notification (ECN) to IP K. Ramakrishnan S. Floyd January 1999 ASCII 64559 25 ECN-IP internet protocol tcp transmission control transport

This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. This memo defines an Experimental Protocol for the Internet community.

RFC3168 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2481
RFC2482 Language Tagging in Unicode Plain Text K. Whistler G. Adams January 1999 ASCII 27800 14 characters strings ASCII

This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.

RFC6082 HISTORIC INFORMATIONAL Legacy 10.17487/RFC2482
RFC2483 URI Resolution Services Necessary for URN Resolution M. Mealling R. Daniel January 1999 ASCII 30518 16 uniform resource identifier names locators characteristics

Retrieving the resource identified by a Uniform Resource Identifier (URI) is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2483
RFC2484 PPP LCP Internationalization Configuration Option G. Zorn January 1999 ASCII 8330 5 point-to-point protocol link control authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK]

RFC2284 RFC1994 RFC1570 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2484
RFC2485 DHCP Option for The Open Group's User Authentication Protocol S. Drach January 1999 ASCII 7205 4 dynamic host configuration UAP

This document defines a DHCP option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2485
RFC2486 The Network Access Identifier B. Aboba M. Beadles January 1999 ASCII 14261 8 NAI tunneling roaming

This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]

RFC4282 PROPOSED STANDARD PROPOSED STANDARD IETF ops roamops http://www.rfc-editor.org/errata_search.php?rfc=2486 10.17487/RFC2486
RFC2487 SMTP Service Extension for Secure SMTP over TLS P. Hoffman January 1999 ASCII 15120 8 simple mail transfer protocol transport layer security ssl

This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]

RFC3207 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2487
RFC2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms M. Allman D. Glover L. Sanchez January 1999 ASCII 47857 19 transmission control protocol network

The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0028 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpsat 10.17487/RFC2488
RFC2489 Procedure for Defining New DHCP Options R. Droms January 1999 ASCII 10484 5 mutipurpose internet mail extensions

This document describes the procedure for defining new DHCP options. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2939 BCP0029 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2489 10.17487/RFC2489
RFC2490 A Simulation Model for IP Multicast with RSVP M. Pullen R. Malghan L. Lavu G. Duan J. Ma H. Nah January 1999 ASCII 74936 31 PS 1956365 PDF 135368 internet protocol resource reservation ipv4

This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package, with protocol procedures defined in the C language. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2490
RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks G. Armitage P. Schulter M. Jork G. Harter January 1999 ASCII 100782 44 IPv6-NBMA internet protocol routing host

This document describes a general architecture for IPv6 over NBMA networks. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2491
RFC2492 IPv6 over ATM Networks G. Armitage P. Schulter M. Jork January 1999 ASCII 21199 12 IPv6ATMNET internet protocol asynchronous transfer mode host

This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks". It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion http://www.rfc-editor.org/errata_search.php?rfc=2492 10.17487/RFC2492
RFC2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals K. Tesink Editor January 1999 ASCII 18749 9 management information base data

This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. [STANDARDS-TRACK]

RFC3593 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2493
RFC2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type D. Fowler Editor January 1999 ASCII 47208 25 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS0 and DS0 Bundle interfaces. This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2494
RFC2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types D. Fowler Editor January 1999 ASCII 155560 75 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]

RFC1406 RFC3895 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2495
RFC2496 Definitions of Managed Object for the DS3/E3 Interface Type D. Fowler Editor January 1999 ASCII 124251 60 DS3-E3-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS1/E1/DS2/E2 (RFC 2495), and the work in progress SONET/SDH Interface Types. [STANDARDS-TRACK]

RFC1407 RFC3896 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2496
RFC2497 Transmission of IPv6 Packets over ARCnet Networks I. Souvatzis January 1999 ASCII 10304 6 internet protocol frame format link-local

This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK]

draft-souvatzis-ipv6-arcnet-05 RFC1201 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2497
RFC2498 IPPM Metrics for Measuring Connectivity J. Mahdavi V. Paxson January 1999 ASCII 17869 10 IPPM-MET internet protocol performance metrics

This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community.

RFC2678 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2498
RFC2499 Request for Comments Summary A. Ramos July 1999 ASCII 43431 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2499 RFC2500 Internet Official Protocol Standards J. Reynolds R. Braden June 1999 ASCII 78845 28 IAB official protocol standards

This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]

RFC2400 RFC2600 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2500
RFC2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations S. Corson J. Macker January 1999 ASCII 28912 12 MANET packet network hardwire wireless

This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC2501
RFC2502 Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment M. Pullen M. Myjak C. Bouwens February 1999 ASCII 28190 11 IP DIS distributed applications

This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF app lsma 10.17487/RFC2502
RFC2503 MIME Types for Use with the ISO ILL Protocol R. Moulton M. Needleman February 1999 ASCII 9078 6 multipurpose mail internet extensions media type interlibrary loan

This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2503
RFC2504 Users' Security Handbook E. Guttman L. Leong G. Malkin February 1999 ASCII 74036 33 encryption networks systems

The Users' Security Handbook is the companion to the Site Security Handbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure. This memo provides information for the Internet community.

FYI0034 INFORMATIONAL INFORMATIONAL IETF ssh 10.17487/RFC2504
RFC2505 Anti-Spam Recommendations for SMTP MTAs G. Lindberg February 1999 ASCII 53597 24 simple mail transfer protocol agents sendmail

This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail,) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-lindberg-anti-spam-mta-08 BCP0030 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2505
RFC2506 Media Feature Tag Registration Procedure K. Holtman A. Mutz T. Hardie March 1999 ASCII 24892 12 data formats vocabulary negotiation mechanism

This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-conneg-feature-reg-03 BCP0031 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app conneg 10.17487/RFC2506
RFC2507 IP Header Compression M. Degermark B. Nordgren S. Pink February 1999 ASCII 106292 47 internet protocol tcp transmission control bandwidth

This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2507
RFC2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links S. Casner V. Jacobson February 1999 ASCII 60474 24 internet protocol user datagram real-timetransport interoperability

This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2508
RFC2509 IP Header Compression over PPP M. Engan S. Casner C. Bormann February 1999 ASCII 18676 10 IPCOM-PPP internet protocol point-to-point datagrams

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol. It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]

RFC3544 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2509
RFC2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols C. Adams S. Farrell March 1999 ASCII 158178 72 PKICMP pki security cryptographic authentication

This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. [STANDARDS-TRACK]

draft-ietf-pkix-ipki3cmp-09 RFC4210 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2510
RFC2511 Internet X.509 Certificate Request Message Format M. Myers C. Adams D. Solo D. Kemp March 1999 ASCII 48278 25 X.509-CRMF crmf security encryption authenticaion

This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]

draft-ietf-pkix-crmf-01 RFC4211 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2511
RFC2512 Accounting Information for ATM Networks K. McCloghrie J. Heinanen W. Greene A. Prasad February 1999 ASCII 29119 15 mib management information base autonomous transfer mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK]

draft-ietf-atommib-atmacct-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2512
RFC2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks K. McCloghrie J. Heinanen W. Greene A. Prasad February 1999 ASCII 60789 29 mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK]

draft-ietf-atommib-acct-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2513
RFC2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management M. Noto E. Spiegel K. Tesink February 1999 ASCII 37583 20 ATM-TC-OID asynchronous transfer mode MIB management information base

This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

draft-ietf-atommib-atm2TC-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2514
RFC2515 Definitions of Managed Objects for ATM Management K. Tesink Ed February 1999 ASCII 179993 87 ATM-MIBMAN asynchronous transfer mode MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

draft-ietf-atommib-atm1ng-06 RFC1695 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2515
RFC2516 A Method for Transmitting PPP Over Ethernet (PPPoE) L. Mamakos K. Lidl J. Evarts D. Carrel D. Simone R. Wheeler February 1999 ASCII 32537 17 PPPOE point-to-point protocol link control network layer

This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2516 10.17487/RFC2516
RFC2517 Building Directories from DNS: Experiences from WWWSeeker R. Moats R. Huber February 1999 ASCII 14001 7 domain name system internet world wide web

This memo discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2517
RFC2518 HTTP Extensions for Distributed Authoring -- WEBDAV Y. Goland E. Whitehead A. Faizi S. Carter D. Jensen February 1999 ASCII 202829 94 WEBDAV hypertext transfer protocol web content

This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK]

RFC4918 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=2518 10.17487/RFC2518
RFC2519 A Framework for Inter-Domain Route Aggregation E. Chen J. Stewart February 1999 ASCII 25394 13 IDRA bgp border gateway protocol address ip internet

This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This memo provides information for the Internet community

draft-ietf-idr-aggregation-framework-04 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC2519
RFC2520 NHRP with Mobile NHCs J. Luciani H. Suzuki N. Doraswamy D. Horton February 1999 ASCII 16763 8 NHRP-MNHCS next hop resolution protocol authentication extension

is document describes an extension to NHRP which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ion-nhrp-mobile-nhc-01 EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2520
RFC2521 ICMP Security Failures Messages P. Karn W. Simpson March 1999 ASCII 14637 9 ICMP-SEC internet control message protocol ip

This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). This document defines an Experimental Protocol for the Internet community.

draft-simpson-icmp-ipsec-fail-02 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2521
RFC2522 Photuris: Session-Key Management Protocol P. Karn W. Simpson March 1999 ASCII 157224 80 PHOTURIS-S ip internet protocol ah esp

This document defines the basic protocol mechanisms. This document defines an Experimental Protocol for the Internet community.

draft-simpson-photuris-18 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2522
RFC2523 Photuris: Extended Schemes and Attributes P. Karn W. Simpson March 1999 ASCII 38166 21 PHOTURIS-E ip internet protocol security

Photuris is a session-key management protocol. Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol. This document defines an Experimental Protocol for the Internet community.

draft-simpson-photuris-schemes-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2523
RFC2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3 M. Banan February 1999 ASCII 153171 83 EMSD wireless IP internet protocol

This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2524
RFC2525 Known TCP Implementation Problems V. Paxson M. Allman S. Dawson W. Fenner J. Griner I. Heavens K. Lahey J. Semke B. Volz March 1999 ASCII 137201 61 transmission control protocol

This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community.

draft-ietf-tcpimpl-prob-05 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2525
RFC2526 Reserved IPv6 Subnet Anycast Addresses D. Johnson S. Deering March 1999 ASCII 14555 7 internet protocol routing architecture

This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. [STANDARDS-TRACK]

draft-ietf-ipngwg-resv-anycast-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2526
RFC2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework S. Chokhani W. Ford March 1999 ASCII 91860 45 pkix encryption security authentication

This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. This memo provides information for the Internet community.

draft-ietf-pkix-ipki-part4-03 RFC3647 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2527 10.17487/RFC2527
RFC2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates R. Housley W. Polk March 1999 ASCII 18273 9 security authentication cryptology

This specification contains guidance on the use of the Internet Public Key Infrastructure certificates to convey Key Exchange Algorithm (KEA) keys. This memo provides information for the Internet community.

draft-ietf-pkix-ipki-kea-02 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC2528
RFC2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels B. Carpenter C. Jung March 1999 ASCII 21049 10 link-local link local addresses internet protocol ip

This memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK]

draft-ietf-ipngwg-6over4-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2529
RFC2530 Indicating Supported Media Features Using Extensions to DSN and MDN D. Wing March 1999 ASCII 7824 5 message disposition notification delivery status

This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]

draft-ietf-fax-reporting-extensions-05 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2530
RFC2531 Content Feature Schema for Internet Fax G. Klyne L. McIntyre March 1999 ASCII 88295 51 media features mechanism

This document defines a content feature schema that is a profile of the media feature registration mechanisms for use in performing capability identification between extended Internet fax systems. [STANDARDS-TRACK]

draft-ietf-fax-feature-schema-05 RFC2879 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2531
RFC2532 Extended Facsimile Using Internet Mail L. Masinter D. Wing March 1999 ASCII 22717 12 mail user fax

This document describes extensions to "Simple Mode of Facsimile Using Internet Mail", and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. [STANDARDS-TRACK]

draft-ietf-fax-eifax-12 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2532
RFC2533 A Syntax for Describing Media Feature Sets G. Klyne March 1999 ASCII 79057 37 message senders recipients file format

This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. [STANDARDS-TRACK]

draft-ietf-conneg-feature-syntax-04 RFC2738 RFC2938 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2533
RFC2534 Media Features for Display, Print, and Fax L. Masinter D. Wing A. Mutz K. Holtman March 1999 ASCII 15466 9 data format vocabulary negotiation mechanisms

This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. [STANDARDS-TRACK]

draft-ietf-conneg-media-features-05 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2534
RFC2535 Domain Name System Security Extensions D. Eastlake 3rd March 1999 ASCII 110958 47 DNS-SECEXT dns authentication

This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK]

draft-ietf-dnssec-secext2-07 RFC2065 RFC4033 RFC4034 RFC4035 RFC2181 RFC1035 RFC1034 RFC2931 RFC3007 RFC3008 RFC3090 RFC3226 RFC3445 RFC3597 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2535
RFC2536 DSA KEYs and SIGs in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII 11121 6 digital signature algorithm signatures cryptology

A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]

draft-ietf-dnssec-dss-03 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2536
RFC2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII 10810 6 message digest signatures cryptology security

A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]

draft-ietf-dnssec-rsa-01 RFC3110 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2537
RFC2538 Storing Certificates in the Domain Name System (DNS) D. Eastlake 3rd O. Gudmundsson March 1999 ASCII 19857 10 SC-DNS cryptology authenticity

Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]

draft-ietf-dnssec-certs-04 RFC4398 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2538
RFC2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII 21049 7 DHK-DNS cryptology authentication security signatures digital

A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. [STANDARDS-TRACK]

draft-ietf-dnssec-dhk-03 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2539
RFC2540 Detached Domain Name System (DNS) Information D. Eastlake 3rd March 1999 ASCII 12546 6 DNS-INFO security digital signatures authentication

A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dnssec-ddi-06 EXPERIMENTAL EXPERIMENTAL IETF sec dnssec 10.17487/RFC2540
RFC2541 DNS Security Operational Considerations D. Eastlake 3rd March 1999 ASCII 14498 7 DNS-SOC domain name system cryptology resource records rrs

This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. This memo provides information for the Internet community.

draft-ietf-dnssec-secops-02 RFC4641 INFORMATIONAL INFORMATIONAL IETF sec dnssec 10.17487/RFC2541
RFC2542 Terminology and Goals for Internet Fax L. Masinter March 1999 ASCII 46372 20 real-time real time session store forward

This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. This memo provides information for the Internet community.

draft-ietf-fax-goals-04 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2542
RFC2543 SIP: Session Initiation Protocol M. Handley H. Schulzrinne E. Schooler J. Rosenberg March 1999 ASCII 338861 151 SIP application-layer application layer multimedia multicast unicast

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. [STANDARDS-TRACK]

draft-ietf-mmusic-sip-12 RFC3261 RFC3262 RFC3263 RFC3264 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC2543
RFC2544 Benchmarking Methodology for Network Interconnect Devices S. Bradner J. McQuaid March 1999 ASCII 66688 31 testing performance

This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community.

RFC1944 RFC6201 RFC6815 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2544 10.17487/RFC2544
RFC2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing P. Marques F. Dupont March 1999 ASCII 10209 5 border gateway protocol idr internet routing

BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2545
RFC2546 6Bone Routing Practice A. Durand B. Buclin March 1999 ASCII 17844 10 IPv6 internet protocol

This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community.

draft-ietf-ngtrans-6bone-routing-01 RFC2772 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2546
RFC2547 BGP/MPLS VPNs E. Rosen Y. Rekhter March 1999 ASCII 63270 25 border gateway protocol multiprotocol label switching architecture virtual private networks

This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. This memo provides information for the Internet community.

RFC4364 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2547
RFC2548 Microsoft Vendor-specific RADIUS Attributes G. Zorn March 1999 ASCII 80763 41 attributes remote access dialin user service dial-in

This document describes the set of Microsoft vendor-specific RADIUS attributes. This memo provides information for the Internet community.

draft-ietf-radius-ms-vsa-01 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2548 10.17487/RFC2548
RFC2549 IP over Avian Carriers with Quality of Service D. Waitzman April 1 1999 ASCII 9519 6 avian carrier april fools qos

This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. This is an experimental, not recommended standard. This memo defines an Experimental Protocol for the Internet community.

RFC1149 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2549 10.17487/RFC2549
RFC2550 Y10K and Beyond S. Glassman M. Manasse J. Mogul April 1 1999 ASCII 28011 14 years dates formats april fools

This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2550
RFC2551 The Roman Standards Process -- Revision III S. Bradner April 1 1999 ASCII 28054 37 numerals protocols procedures april fools

This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2551
RFC2552 Architecture for the Information Brokerage in the ACTS Project GAIA M. Blinov M. Bessonov C. Clissmann April 1999 ASCII 65172 30 electronic systems products

This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2552
RFC2553 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound W. Stevens March 1999 ASCII 89215 41 internet protocol api application program interface tcp transmission control

TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. This memo provides information for the Internet community.

draft-ietf-ipngwg-bsd-api-new-06 RFC2133 RFC3493 RFC3152 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2553
RFC2554 SMTP Service Extension for Authentication J. Myers March 1999 ASCII 20534 11 simple mail transfer protocol security layer sasl

This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]

draft-myers-smtp-auth-12 RFC4954 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2554
RFC2555 30 Years of RFCs RFC Editor et al. April 1999 ASCII 42902 18 request for comments series documents publication

The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2555
RFC2556 OSI connectionless transport services on top of UDP Applicability Statement for Historic Status S. Bradner March 1999 ASCII 5864 4 user datagram protocol ISO international organization for standardization

RFC 1240, "OSI connectionless transport services on top of UDP", was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility This memo provides information for the Internet community.

draft-bradner-1240.his-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2556
RFC2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) J. Palme A. Hopmann N. Shelness March 1999 ASCII 61854 28 MHTML multipurpose internet mail extensions multimedia uri uniform resource identifiers

This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. [STANDARDS-TRACK]

draft-ietf-mhtml-rev-07 RFC2110 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2557 10.17487/RFC2557
RFC2558 Definitions of Managed Objects for the SONET/SDH Interface Type K. Tesink March 1999 ASCII 138550 74 MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK]

draft-ietf-atommib-sonetng-05 RFC1595 RFC3592 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2558
RFC2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 S. Boeyen T. Howes P. Richard April 1999 ASCII 22889 13 X.500 LDAP lightweight directory protocol

Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK]

draft-ietf-pkix-ipki2opp-08 RFC3494 RFC1778 HISTORIC PROPOSED STANDARD IETF sec pkix 10.17487/RFC2559
RFC2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP M. Myers R. Ankney A. Malpani S. Galperin C. Adams June 1999 ASCII 43243 23 PKIX digital security

This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]

draft-ietf-pkix-ocsp-07 RFC6960 RFC6277 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2560 10.17487/RFC2560
RFC2561 Base Definitions of Managed Objects for TN3270E Using SMIv2 K. White R. Moore April 1999 ASCII 113705 56 MIB management information base structure telnet

This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. [STANDARDS-TRACK]

draft-ietf-tn3270e-tn3270-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC2561
RFC2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) K. White R. Moore April 1999 ASCII 110633 49 TN2370E-RT-MIB MIB management information base structure telnet

This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. [STANDARDS-TRACK]

draft-ietf-tn3270e-rt-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC2562
RFC2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients R. Troll May 1999 ASCII 17838 9 dynamic host configuration protocol internet address

This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. [STANDARDS-TRACK]

draft-ietf-dhc-autoconfig-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2563
RFC2564 Application Management MIB C. Kalbfleisch C. Krupczak R. Presuhn J. Saperia May 1999 ASCII 183314 86 APP-MIB management information base

This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. [STANDARDS-TRACK]

draft-ietf-applmib-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2564
RFC2565 Internet Printing Protocol/1.0: Encoding and Transport R. Herriot Editor S. Butler P. Moore R. Turner April 1999 ASCII 80439 37 IPP-E-T IPP application media-type media type

This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines an Experimental protocol for the Internet community.

draft-ietf-ipp-protocol-07 RFC2910 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2565
RFC2566 Internet Printing Protocol/1.0: Model and Semantics R. deBry T. Hastings R. Herriot S. Isaacson P. Powell April 1999 ASCII 438887 173 IPP-M-S IPP application media-type job

This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. This document also addresses security, internationalization, and directory issues. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipp-model-11 RFC2911 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2566
RFC2567 Design Goals for an Internet Printing Protocol F. Wright April 1999 ASCII 90260 43 IPP-DG IPP application media-type media type

This document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipp-req-03 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2567
RFC2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol S. Zilles April 1999 ASCII 23547 10 IPP-RAT IPP application media-type media type

This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipp-rat-04 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2568
RFC2569 Mapping between LPD and IPP Protocols R. Herriot Editor T. Hastings N. Jacobs J. Martin April 1999 ASCII 57886 28 application media-type media type internet printing protocol line printer daemon

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipp-lpd-ipp-map-05 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2569
RFC2570 Introduction to Version 3 of the Internet-standard Network Management Framework J. Case R. Mundy D. Partain B. Stewart April 1999 ASCII 50381 23 snmp simple protocol

The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This memo provides information for the Internet community.

draft-ietf-snmpv3-intro-04 RFC3410 INFORMATIONAL INFORMATIONAL IETF ops snmpv3 10.17487/RFC2570
RFC2571 An Architecture for Describing SNMP Management Frameworks B. Wijnen D. Harrington R. Presuhn April 1999 ASCII 139260 62 ARCH-SNMP simple protocol network management

This document describes an architecture for describing SNMP Management Frameworks. [STANDARDS-TRACK]

draft-ietf-snmpv3-arch-05 RFC2271 RFC3411 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2571
RFC2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen April 1999 ASCII 96035 44 MPD-SNMP processing models multiple

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

RFC2272 RFC3412 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2572
RFC2573 SNMP Applications D. Levi P. Meyer B. Stewart April 1999 ASCII 150427 72 SNMP-APP simple network management protocol proxy operations command

This memo describes five types of SNMP applications which make use of an SNMP engine. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy fowarding. [STANDARDS-TRACK]

draft-ietf-snmpv3-appl-v2-03 RFC2273 RFC3413 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2573
RFC2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen April 1999 ASCII 190755 86 USM-SNMPV3 message level mib information base

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

draft-ietf-snmpv3-usm-v2-05 RFC2274 RFC3414 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2574
RFC2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie April 1999 ASCII 79642 38 VACM-SNMP mib information base

This document describes the View-based Access Control Model for use in the SNMP architecture (RFC2571). It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

draft-ietf-snmpv3-vacm-04 RFC2275 RFC3415 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2575
RFC2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework R. Frye D. Levi S. Routhier B. Wijnen March 2000 ASCII 98589 44 SNMP simple network management protocol mib information base

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

draft-ietf-snmpv3-coex-08 RFC1908 RFC2089 RFC3584 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=2576 10.17487/RFC2576
RFC2577 FTP Security Considerations M. Allman S. Ostermann May 1999 ASCII 17870 8 FTP-SEC file transfer protocol bounce attack password server

This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. This memo provides information for the Internet community.

draft-ietf-ftpext-sec-consider-02 INFORMATIONAL INFORMATIONAL IETF app ftpext 10.17487/RFC2577
RFC2578 Structure of Management Information Version 2 (SMIv2) K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII 89712 42 SMIv2 Simple Network Management Protocol Version 2

It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

draft-ops-smiv2-smi-01 RFC1902 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2578
RFC2579 Textual Conventions for SMIv2 K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII 59039 25 CONV-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

draft-ops-smiv2-tc-01 RFC1903 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2579 10.17487/RFC2579
RFC2580 Conformance Statements for SMIv2 K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII 54253 29 CONF-MIB simple Network Management Protocol Version 2

Collections of related objects are defined in MIB modules. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

draft-ops-smiv2-conf-01 RFC1904 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2580
RFC2581 TCP Congestion Control M. Allman V. Paxson W. Stevens April 1999 ASCII 31351 14 TCP-CC

This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. [STANDARDS-TRACK]

draft-ietf-tcpimpl-cong-control-05 RFC2001 RFC5681 RFC3390 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpimpl http://www.rfc-editor.org/errata_search.php?rfc=2581 10.17487/RFC2581
RFC2582 The NewReno Modification to TCP's Fast Recovery Algorithm S. Floyd T. Henderson April 1999 ASCII 29393 12 Transmission Control Protocol

This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tcpimpl-newreno-02 RFC3782 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpimpl 10.17487/RFC2582
RFC2583 Guidelines for Next Hop Client (NHC) Developers R. Carlson L. Winkler May 1999 ASCII 21338 9 NHRP resolution protocol IP internet

This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community.

draft-carlson-nhrp-03 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2583
RFC2584 Definitions of Managed Objects for APPN/HPR in IP Networks B. Clouston B. Moore May 1999 ASCII 40187 21 internet protocol MIB management information base high performance routing

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. [STANDARDS-TRACK]

draft-ietf-snanau-hpripmib-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2584
RFC2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP R. Housley P. Hoffman May 1999 ASCII 14813 8 file transfer hypertext PKI

The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. [STANDARDS-TRACK]

draft-ietf-pkix-opp-ftp-http-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2585 10.17487/RFC2585
RFC2586 The Audio/L16 MIME content type J. Salsman H. Alvestrand May 1999 ASCII 8694 5 AUDIO/L16 media-type application multipurpose internet mail extensions

This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community.

draft-alvestrand-audio-l16-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2586
RFC2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema S. Boeyen T. Howes P. Richard June 1999 ASCII 15102 8 lightweight directory access protocol pkix

The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK]

draft-ietf-pkix-ldapv2-schema-02 RFC4523 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2587
RFC2588 IP Multicast and Firewalls R. Finlayson May 1999 ASCII 28622 12 Internet Protocol security gateway traffic

In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community.

draft-ietf-mboned-mcast-firewall-02 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC2588
RFC2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services Y. Yaacovi M. Wahl T. Genovese May 1999 ASCII 26855 12 LDAPv3 request response operations

This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK]

draft-ietf-asid-ldapv3-dynamic-08 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2589
RFC2590 Transmission of IPv6 Packets over Frame Relay Networks Specification A. Conta A. Malis M. Mueller May 1999 ASCII 41817 19 internet Protocol format link-local

This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. [STANDARDS-TRACK]

draft-ietf-ion-ipv6-fr-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2590
RFC2591 Definitions of Managed Objects for Scheduling Management Operations D. Levi J. Schoenwaelder May 1999 ASCII 52920 25 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-disman-schedule-mib-06 RFC3231 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2591
RFC2592 Definitions of Managed Objects for the Delegation of Management Script D. Levi J. Schoenwaelder May 1999 ASCII 110629 53 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]

draft-ietf-disman-script-mib-08 RFC3165 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2592
RFC2593 Script MIB Extensibility Protocol Version 1.0 J. Schoenwaelder J. Quittek May 1999 ASCII 49663 22 management information base smx language specific

The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. This memo defines an Experimental Protocol for the Internet community.

draft-schoenw-smx-00 RFC3179 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2593
RFC2594 Definitions of Managed Objects for WWW Services H. Hazewinkel C. Kalbfleisch J. Schoenwaelder May 1999 ASCII 88876 43 management information base mib world wide web

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular it describes a set of objects for managing World Wide Web (WWW) services. [STANDARDS-TRACK]

draft-ietf-applmib-wwwmib-11 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2594
RFC2595 Using TLS with IMAP, POP3 and ACAP C. Newman June 1999 ASCII 32440 15 application configuration access protocol post office internet message transport layer security

Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK]

draft-newman-tls-imappop-09 RFC4616 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2595 10.17487/RFC2595
RFC2596 Use of Language Codes in LDAP M. Wahl T. Howes May 1999 ASCII 17413 9 lightweight directory access protocol servers

This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK]

draft-ietf-ldapext-lang-01 RFC3866 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2596
RFC2597 Assured Forwarding PHB Group J. Heinanen F. Baker W. Weiss J. Wroclawski June 1999 ASCII 24068 11 per-hop-behaviour differentiated services af assumed forwarding

This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]

draft-ietf-diffserv-af-06 RFC3260 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2597 10.17487/RFC2597
RFC2598 An Expedited Forwarding PHB V. Jacobson K. Nichols K. Poduri June 1999 ASCII 23656 11 per-hop-forwarding behavior differentiated services ef

The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. [STANDARDS-TRACK]

draft-ietf-diffserv-phb-ef-02 RFC3246 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2598 10.17487/RFC2598
RFC2599 Request for Comments Summary RFC Numbers 2500-2599 A. DeLaCruz March 2000 ASCII 45845 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2599 RFC2600 Internet Official Protocol Standards J. Reynolds R. Braden March 2000 ASCII 86139 31 IAB official protocol standards

This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK]

RFC2500 RFC2700 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2600
RFC2601 ILMI-Based Server Discovery for ATMARP M. Davison June 1999 ASCII 11820 6 integrated local management interface asynchronous transfer mode address resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers. [STANDARDS-TRACK]

draft-ietf-ion-discov-atmarp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2601
RFC2602 ILMI-Based Server Discovery for MARS M. Davison June 1999 ASCII 12031 6 integrated local management interface asynchronous transfer mode address resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers. [STANDARDS-TRACK]

draft-ietf-ion-discov-mars-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2602
RFC2603 ILMI-Based Server Discovery for NHRP M. Davison June 1999 ASCII 11865 6 integrated local management interface next hop resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers. [STANDARDS-TRACK]

draft-ietf-ion-discov-nhrp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2603
RFC2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP R. Gellens June 1999 ASCII 65329 29 over-the-air ota application configuration access protocol

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.

draft-gellens-otasp-acap-01 RFC2636 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2604
RFC2605 Directory Server Monitoring MIB G. Mansfield S. Kille June 1999 ASCII 49166 26 management information base network services

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-madman-dsa-mib-1 RFC1567 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2605
RFC2606 Reserved Top Level DNS Names D. Eastlake 3rd A. Panitz June 1999 ASCII 8008 5 domain name system private

To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsind-test-tlds-13 RFC6761 BCP0032 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind 10.17487/RFC2606
RFC2607 Proxy Chaining and Policy Implementation in Roaming B. Aboba J. Vollbrecht June 1999 ASCII 33271 15 network access server identifier radius

This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community.

draft-ietf-roamops-auth-10 INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2607
RFC2608 Service Location Protocol, Version 2 E. Guttman C. Perkins J. Veizades M. Day June 1999 ASCII 129475 54 SLP network services

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]

draft-ietf-svrloc-protocol-v2-15 RFC2165 RFC3224 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc http://www.rfc-editor.org/errata_search.php?rfc=2608 10.17487/RFC2608
RFC2609 Service Templates and Service: Schemes E. Guttman C. Perkins J. Kempf June 1999 ASCII 72842 33 service location protocol slp url universal resource locator

This document describes a formal procedure for defining and standardizing new service types and attributes for use with the "service:" scheme. [STANDARDS-TRACK]

draft-ietf-svrloc-service-scheme-14 RFC2165 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc 10.17487/RFC2609
RFC2610 DHCP Options for Service Location Protocol C. Perkins E. Guttman June 1999 ASCII 10859 6 slp dynamic host configuration protocol

The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. [STANDARDS-TRACK]

draft-ietf-dhc-slp-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2610
RFC2611 URN Namespace Definition Mechanisms L. Daigle D. van Gulik R. Iannella P. Falstrom June 1999 ASCII 26916 14 uniform resource names namespaces syntax

This document lays out general definitions of and mechanisms for establishing URN "namespaces". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-urn-nid-req-08 RFC3406 BCP0033 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn 10.17487/RFC2611
RFC2612 The CAST-256 Encryption Algorithm C. Adams J. Gilchrist June 1999 ASCII 37468 19 security cryptology

This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A). This memo provides information for the Internet community.

draft-adams-cast-256-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2612
RFC2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0 R. Waterman B. Lahaye D. Romascanu S. Waldbusser June 1999 ASCII 88701 44 smon management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices in switched networks environments. [STANDARDS-TRACK]

draft-ietf-rmonmib-smon-07 DRAFT STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2613
RFC2614 An API for Service Location J. Kempf E. Guttman June 1999 ASCII 164002 91 slp application program interface

This document describes standardized APIs for SLP in C and Java. This memo provides information for the Internet community.

draft-ietf-svrloc-api-09 INFORMATIONAL INFORMATIONAL IETF int svrloc 10.17487/RFC2614
RFC2615 PPP over SONET/SDH A. Malis W. Simpson June 1999 ASCII 18708 10 point-to-point protocol synchronous optical network digital heirarchy

This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. [STANDARDS-TRACK]

draft-ietf-pppext-pppoversonet-update-04 RFC1619 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2615
RFC2616 Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding J. Gettys J. Mogul H. Frystyk L. Masinter P. Leach T. Berners-Lee June 1999 ASCII 422317 176 PS 5529857 PDF 550558 HTTP World Wide Web WWW hypermedia

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK]

draft-ietf-http-v11-spec-rev-06 RFC2068 RFC7230 RFC7231 RFC7232 RFC7233 RFC7234 RFC7235 RFC2817 RFC5785 RFC6266 RFC6585 DRAFT STANDARD DRAFT STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2616 10.17487/RFC2616
RFC2617 HTTP Authentication: Basic and Digest Access Authentication J. Franks P. Hallam-Baker J. Hostetler S. Lawrence P. Leach A. Luotonen L. Stewart June 1999 ASCII 77638 34 security encryption hypertext transfer protocol

This document provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". [STANDARDS-TRACK]

draft-ietf-http-authentication-03 RFC2069 RFC7235 DRAFT STANDARD DRAFT STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2617 10.17487/RFC2617
RFC2618 RADIUS Authentication Client MIB B. Aboba G. Zorn June 1999 ASCII 26889 14 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS authentication client functions. [STANDARDS-TRACK]

draft-ietf-radius-auth-clientmib-05 RFC4668 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2618
RFC2619 RADIUS Authentication Server MIB G. Zorn B. Aboba June 1999 ASCII 30464 16 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS authentication server functions. [STANDARDS-TRACK]

draft-ietf-radius-auth-servmib-05 RFC4669 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2619
RFC2620 RADIUS Accounting Client MIB B. Aboba G. Zorn June 1999 ASCII 23960 13 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS accounting client functions. This memo provides information for the Internet community.

draft-ietf-radius-acc-clientmib-05 RFC4670 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2620
RFC2621 RADIUS Accounting Server MIB G. Zorn B. Aboba June 1999 ASCII 27768 15 management information base security remote access,dialin user service

This memo defines a set of extensions which instrument RADIUS accounting server functions. This memo provides information for the Internet community.

draft-ietf-radius-acc-servmib-05 RFC4671 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2621
RFC2622 Routing Policy Specification Language (RPSL) C. Alaettinoglu C. Villamizar E. Gerich D. Kessens D. Meyer T. Bates D. Karrenberg M. Terpstra June 1999 ASCII 140811 69 RPSL internet policy hierarchy network configuration

RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]

draft-ietf-rps-rpsl-v2-03 RFC2280 RFC4012 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2622
RFC2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 M. Eisler June 1999 ASCII 42521 19 network file system remote procedure call architecture

This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. [STANDARDS-TRACK]

draft-ietf-nfsv4-nfssec-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC2623
RFC2624 NFS Version 4 Design Considerations S. Shepler June 1999 ASCII 52891 22 network file system

This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. This memo provides information for the Internet community.

draft-ietf-nfsv4-designconsider-03 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC2624
RFC2625 IP and ARP over Fibre Channel M. Rajagopal R. Bhagwat W. Rickard June 1999 ASCII 137741 63 internet protocal address resolution

The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. [STANDARDS-TRACK]

draft-ietf-ipfc-fibre-channel-06 RFC4338 PROPOSED STANDARD PROPOSED STANDARD IETF int ipfc http://www.rfc-editor.org/errata_search.php?rfc=2625 10.17487/RFC2625
RFC2626 The Internet and the Millennium Problem (Year 2000) P. Nesser II June 1999 ASCII 547560 275 Y2K

The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. This memo provides information for the Internet community.

draft-ietf-2000-issue-06 INFORMATIONAL INFORMATIONAL IETF ops 2000 http://www.rfc-editor.org/errata_search.php?rfc=2626 10.17487/RFC2626
RFC2627 Key Management for Multicast: Issues and Architectures D. Wallner E. Harder R. Agee June 1999 ASCII 59263 23 communication sessions net key rekey

This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. This memo provides information for the Internet community.

draft-wallner-key-arch-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2627
RFC2628 Simple Cryptographic Program Interface (Crypto API) V. Smyslov June 1999 ASCII 60070 30 application security

This document describes a simple Application Program Interface to cryptographic functions. This memo provides information for the Internet community.

draft-smyslov-crypto-api-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2628
RFC2629 Writing I-Ds and RFCs using XML M. Rose June 1999 ASCII 48677 31 internet-drafts extensible markup language source format

This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.

draft-mrose-writing-rfcs-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2629
RFC2630 Cryptographic Message Syntax R. Housley June 1999 ASCII 128599 60 encryption certificate key management

This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK]

draft-ietf-smime-cms-13 RFC3369 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2630 10.17487/RFC2630
RFC2631 Diffie-Hellman Key Agreement Method E. Rescorla June 1999 ASCII 25932 13 encryption management certificate

This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]

draft-ietf-smime-x942-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2631 10.17487/RFC2631
RFC2632 S/MIME Version 3 Certificate Handling B. Ramsdell Editor June 1999 ASCII 27925 13 encryption certificate multipurpose internet mail extensions secure

S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK]

draft-ietf-smime-cert-08 RFC3850 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2632
RFC2633 S/MIME Version 3 Message Specification B. Ramsdell Editor June 1999 ASCII 67870 32 secure multipurpose internet mail extensions encryption

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]

draft-ietf-smime-msg-08 RFC3851 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2633 10.17487/RFC2633
RFC2634 Enhanced Security Services for S/MIME P. Hoffman Editor June 1999 ASCII 131153 58 secure multipurpose internet mail extensions encryption

This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]

draft-ietf-smime-ess-12 RFC5035 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2634
RFC2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) S. Hambridge A. Lunde June 1999 ASCII 44669 18 electronic mail email users administrators managers

This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. This memo provides information for the Internet community.

draft-ietf-run-spew-08 FYI0035 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC2635
RFC2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP R. Gellens July 1999 ASCII 65288 29 PS 1120860 PDF 173655 over-the-air ota application configuration access protocol

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.

RFC2604 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2636
RFC2637 Point-to-Point Tunneling Protocol (PPTP) K. Hamzeh G. Pall W. Verthein J. Taarud W. Little G. Zorn July 1999 ASCII 132565 57 IP tunnel encapsulation

This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community.

draft-ietf-pppext-pptp-10 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2637
RFC2638 A Two-bit Differentiated Services Architecture for the Internet K. Nichols V. Jacobson L. Zhang July 1999 ASCII 72785 26 PS 1610846 PDF 315195 IP internet protocol header packets

This document presents a differentiated services architecture for the internet. This memo provides information for the Internet community.

draft-nichols-diff-svc-arch-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2638
RFC2639 Internet Printing Protocol/1.0: Implementer's Guide T. Hastings C. Manros July 1999 ASCII 145086 64 IPP client object

This document contains information that supplements the IPP Model and Semantics and the IPP Transport and Encoding documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. This memo provides information for the Internet community.

draft-ietf-ipp-implementers-guide-01 RFC3196 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC2639
RFC2640 Internationalization of the File Transfer Protocol B. Curtin July 1999 ASCII 57204 27 ftp character sets languages

This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support. [STANDARDS-TRACK]

draft-ietf-ftpext-intl-ftp-06 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext 10.17487/RFC2640
RFC2641 Cabletron's VlanHello Protocol Specification Version 4 D. Hamilton D. Ruffen August 1999 ASCII 34686 17 ISMP inter switch message protocol switches

The VlanHello protocol is part of the InterSwitch Message Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2641
RFC2642 Cabletron's VLS Protocol Specification L. Kane August 1999 ASCII 204347 95 Virtual LAN link ISMP inter switch message routing

VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2642
RFC2643 Cabletron's SecureFast VLAN Operational Model D. Ruffen T. Len J. Yanacek August 1999 ASCII 121786 60 SFVLAN switching data packets vitrual LANs

Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC2643
RFC2644 Changing the Default for Directed Broadcasts in Routers D. Senie August 1999 ASCII 6820 4 smurf amplifiers denial of service

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.

draft-senie-directed-broadcast-03 RFC1812 BCP0034 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2644
RFC2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses R. Gellens August 1999 ASCII 16302 9 ODMR-SMTP simple mail transfer protocol internet

This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]

draft-gellens-on-demand-07 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2645 10.17487/RFC2645
RFC2646 The Text/Plain Format Parameter R. Gellens Editor August 1999 ASCII 29175 14 media type mime multipurpose internet mail extension

This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]

draft-gellens-format-06 RFC3676 RFC2046 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2646
RFC2647 Benchmarking Terminology for Firewall Performance D. Newman August 1999 ASCII 45374 26 routers switches measurement

This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK]

draft-ietf-bmwg-secperf-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2647
RFC2648 A URN Namespace for IETF Documents R. Moats August 1999 ASCII 46826 30 uniform resource names internet engineering task force

This document proposes the "ietf" namespace, which consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor and the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences. [STANDARDS-TRACK]

draft-ietf-urn-ietf-09 RFC6924 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2648 10.17487/RFC2648
RFC2649 An LDAP Control and Schema for Holding Operation Signatures B. Greenblatt P. Richard August 1999 ASCII 20470 10 lightweight directory access protocol client server

This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines an LDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ldapext-sigops-04 EXPERIMENTAL EXPERIMENTAL IETF app ldapext 10.17487/RFC2649
RFC2650 Using RPSL in Practice D. Meyer J. Schmitz C. Orange M. Prior C. Alaettinoglu August 1999 ASCII 55272 26 routing policy specification language IRR internet routing registry configurations

This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). This memo provides information for the Internet community.

draft-ietf-rps-appl-rpsl-06 INFORMATIONAL INFORMATIONAL IETF ops rps 10.17487/RFC2650
RFC2651 The Architecture of the Common Indexing Protocol (CIP) J. Allen M. Mealling August 1999 ASCII 41933 19 CIP query routing database servers

This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. [STANDARDS-TRACK]

draft-ietf-find-cip-arch-02 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2651
RFC2652 MIME Object Definitions for the Common Indexing Protocol (CIP) J. Allen M. Mealling August 1999 ASCII 42464 22 multipurpose internet mail extensions database

This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. [STANDARDS-TRACK]

draft-ietf-find-cip-mime-03 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2652
RFC2653 CIP Transport Protocols J. Allen P. Leach R. Hedberg August 1999 ASCII 22999 11 common indexing message formats

This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. [STANDARDS-TRACK]

draft-ietf-find-cip-trans-01 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2653
RFC2654 A Tagged Index Object for use in the Common Indexing Protocol R. Hedberg B. Greenblatt R. Moats M. Wahl August 1999 ASCII 46739 24 CIP information servers database

This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-find-cip-tagged-07 EXPERIMENTAL EXPERIMENTAL IETF app find 10.17487/RFC2654
RFC2655 CIP Index Object Format for SOIF Objects T. Hardie M. Bowman D. Hardy M. Schwartz D. Wessels August 1999 ASCII 34285 17 summary object interchange format common indexing protocol

This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-find-cip-soif-02 EXPERIMENTAL EXPERIMENTAL IETF app find http://www.rfc-editor.org/errata_search.php?rfc=2655 10.17487/RFC2655
RFC2656 Registration Procedures for SOIF Template Types T. Hardie August 1999 ASCII 17409 9 summary object interchange format stream

The registration procedure described in this document is specific to SOIF template types. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-find-soif-registry-00 EXPERIMENTAL EXPERIMENTAL IETF app find http://www.rfc-editor.org/errata_search.php?rfc=2656 10.17487/RFC2656
RFC2657 LDAPv2 Client vs. the Index Mesh R. Hedberg August 1999 ASCII 19251 12 lightweight directory access protocol CIP common indexing

LDAPv2 clients as implemented according to RFC 1777 have no notion on referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-find-cip-ldapv2-02 EXPERIMENTAL EXPERIMENTAL IETF app find 10.17487/RFC2657
RFC2658 RTP Payload Format for PureVoice(tm) Audio K. McKay August 1999 ASCII 21895 10 real-time transport protocol packet end-to-end

This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]

draft-mckay-qcelp-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2658
RFC2659 Security Extensions For HTML E. Rescorla A. Schiffman August 1999 ASCII 8134 4 hyper-text markup language cryptology

This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-wts-shtml-05 EXPERIMENTAL EXPERIMENTAL IETF sec wts 10.17487/RFC2659
RFC2660 The Secure HyperText Transfer Protocol E. Rescorla A. Schiffman August 1999 ASCII 95645 45 WWW world wide web http authentication

This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-wts-shttp-06 EXPERIMENTAL EXPERIMENTAL IETF sec wts 10.17487/RFC2660
RFC2661 Layer Two Tunneling Protocol "L2TP" W. Townsley A. Valencia A. Rubens G. Pall G. Zorn B. Palter August 1999 ASCII 168150 80 L2TP ppp point-to-point protocol packets

This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]

draft-ietf-pppext-l2tp-16 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2661 10.17487/RFC2661
RFC2662 Definitions of Managed Objects for the ADSL Lines G. Bathrick F. Ly August 1999 ASCII 247122 115 MIB management information base

This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]

draft-ietf-adslmib-adsllinemib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC2662
RFC2663 IP Network Address Translator (NAT) Terminology and Considerations P. Srisuresh M. Holdrege August 1999 ASCII 72265 30 network address translator IP internet protocol addresses

This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. This memo provides information for the Internet community.

draft-ietf-nat-terminology-03 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=2663 10.17487/RFC2663
RFC2664 FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions R. Plzak A. Wells E. Krol August 1999 ASCII 23640 11 documentation help information FAQ

This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. This memo provides information for the Internet community.

draft-ietf-uswg-fyi4-bis-01 RFC1594 FYI0004 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC2664
RFC2665 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick J. Johnson August 1999 ASCII 110038 47 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-hubmib-etherif-mib-v2-04 RFC2358 RFC3635 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2665
RFC2666 Definitions of Object Identifiers for Identifying Ethernet Chip Sets J. Flick August 1999 ASCII 37699 18 mib management information base

This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. This memo provides information for the Internet community.

draft-ietf-hubmib-ether-chipsets-02 INFORMATIONAL INFORMATIONAL IETF ops hubmib 10.17487/RFC2666
RFC2667 IP Tunnel MIB D. Thaler August 1999 ASCII 32770 16 internet protocol management information base

This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK]

draft-ietf-ifmib-tunnel-mib-06 RFC4087 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2667
RFC2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) A. Smith J. Flick K. de Graaf D. Romascanu D. McMaster K. McCloghrie S. Roberts August 1999 ASCII 121843 56 MAU-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-hubmib-mau-mib-v2-04 RFC2239 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2668
RFC2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems M. St. Johns Editor August 1999 ASCII 112880 55 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]

draft-ietf-ipcdn-cable-device-mib-08 RFC4639 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC2669
RFC2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces M. St. Johns Editor August 1999 ASCII 141077 72 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. [STANDARDS-TRACK]

draft-ietf-ipcdn-rf-interface-mib-07 RFC4546 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC2670
RFC2671 Extension Mechanisms for DNS (EDNS0) P. Vixie August 1999 ASCII 15257 7 EDNS0 domain name system resource records opt

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK]

draft-ietf-dnsind-edns0-02 RFC6891 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2671
RFC2672 Non-Terminal DNS Name Redirection M. Crawford August 1999 ASCII 18321 9 domain name system dname resource records

This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK]

draft-ietf-dnsind-dname-03 RFC6672 RFC4592 RFC6604 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2672
RFC2673 Binary Labels in the Domain Name System M. Crawford August 1999 ASCII 12379 7 DNS data

This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK]

draft-ietf-dnsind-binary-labels-05 RFC6891 RFC1035 RFC3363 RFC3364 HISTORIC PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2673 10.17487/RFC2673
RFC2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions E. Bell A. Smith P. Langille A. Rijhsinghani K. McCloghrie August 1999 ASCII 159971 86 MIB management information base local area network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. [STANDARDS-TRACK]

draft-ietf-bridge-bridgemib-06 RFC4363 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC2674
RFC2675 IPv6 Jumbograms D. Borman S. Deering R. Hinden August 1999 ASCII 17320 9 internet protocol packet payload link

This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS-TRACK]

draft-ietf-ipngwg-jumbograms-01 RFC2147 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2675 10.17487/RFC2675
RFC2676 QoS Routing Mechanisms and OSPF Extensions G. Apostolopoulos S. Kama D. Williams R. Guerin A. Orda T. Przygienda August 1999 ASCII 124563 50 quality of service open shortest path first routing

This memo describes extensions to the OSPF protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. This memo defines an Experimental Protocol for the Internet community.

draft-guerin-qos-routing-ospf-05 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2676 10.17487/RFC2676
RFC2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) M. Greene J. Cucchiara J. Luciani August 1999 ASCII 129699 67 NHRP-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-ion-nhrp-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2677
RFC2678 IPPM Metrics for Measuring Connectivity J. Mahdavi V. Paxson September 1999 ASCII 18087 10 IPPM-MET internet protocol performance metrics

This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]

RFC2498 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2678
RFC2679 A One-way Delay Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII 43542 20 internet protocol performance metrics packets

This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]

draft-ietf-ippm-delay-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2679 10.17487/RFC2679
RFC2680 A One-way Packet Loss Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII 32266 15 internet protocol performance metrics

This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]

draft-ietf-ippm-loss-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2680 10.17487/RFC2680
RFC2681 A Round-trip Delay Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII 44357 20 internet protocol performance metrics packets

This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]

draft-ietf-ippm-rt-delay-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2681 10.17487/RFC2681
RFC2682 Performance Issues in VC-Merge Capable ATM LSRs I. Widjaja A. Elwalid September 1999 ASCII 29491 12 asynchronous transfer mode routing

This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. This memo provides information for the Internet community.

draft-widjaja-mpls-vc-merge-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2682
RFC2683 IMAP4 Implementation Recommendations B. Leiba September 1999 ASCII 56300 23 internet message access protocol clients servers

The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community.

draft-leiba-imap-implement-guide-10 RFC7162 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2683 10.17487/RFC2683
RFC2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 D. Grossman J. Heinanen September 1999 ASCII 51390 23 asynchronous,transfer mode multiplexing

This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. [STANDARDS-TRACK]

draft-ietf-ion-multiprotocol-atm-04 RFC1483 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2684
RFC2685 Virtual Private Networks Identifier B. Fox B. Gleeson September 1999 ASCII 11168 6 VPNI IP internet protocol VPN

This document proposes a format for a globally unique VPN identifier. [STANDARDS-TRACK]

draft-ietf-ion-vpn-id-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2685
RFC2686 The Multi-Class Extension to Multi-Link PPP C. Bormann September 1999 ASCII 24192 11 point-to-point protocol encapsulation

This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]

draft-ietf-issll-isslow-mcml-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2686
RFC2687 PPP in a Real-time Oriented HDLC-like Framing C. Bormann September 1999 ASCII 28699 13 point-to-point protocol encapsulation high-level data link control

This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]

draft-ietf-issll-isslow-rtf-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2687
RFC2688 Integrated Services Mappings for Low Speed Networks S. Jackowski D. Putzolu E. Crawley B. Davie September 1999 ASCII 36685 16 controlled load guaranteed services

This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load and guaranteed services. [STANDARDS-TRACK]

draft-ietf-issll-isslow-svcmap-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2688
RFC2689 Providing Integrated Services over Low-bitrate Links C. Bormann September 1999 ASCII 34345 14 asynchronous synchronous real-time

This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links. This memo provides information for the Internet community.

draft-ietf-issll-isslow-06 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2689
RFC2690 A Proposal for an MOU-Based ICANN Protocol Support Organization S. Bradner September 1999 ASCII 14221 8 pso memorandum of understanding internet corporation for assigned names and numbers

This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community.

draft-ietf-poisson-mou-pso-00 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2690
RFC2691 A Memorandum of Understanding for an ICANN Protocol Support Organization S. Bradner September 1999 ASCII 18940 9 mou pso internet corporation for assigned names and numbers

This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers (ICANN). This memo provides information for the Internet community.

draft-ietf-poisson-pso-mou-01 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2691
RFC2692 SPKI Requirements C. Ellison September 1999 ASCII 29569 14 SPKI simple public key infrastructure authentication

The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-spki-cert-req-03 EXPERIMENTAL EXPERIMENTAL IETF sec spki 10.17487/RFC2692
RFC2693 SPKI Certificate Theory C. Ellison B. Frantz B. Lampson R. Rivest B. Thomas T. Ylonen September 1999 ASCII 96699 43 SPKI simple public key infrastructure authentication

This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-spki-cert-theory-05 EXPERIMENTAL EXPERIMENTAL IETF sec spki 10.17487/RFC2693
RFC2694 DNS extensions to Network Address Translators (DNS_ALG) P. Srisuresh G. Tsirtsis P. Akkiraju A. Heffernan September 1999 ASCII 67720 29 domain name system NATs mapping

This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need. This memo provides information for the Internet community.

draft-ietf-nat-dns-alg-04 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC2694
RFC2695 Authentication Mechanisms for ONC RPC A. Chiu September 1999 ASCII 39286 18 remote procedure call open network computing

This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community.

draft-ietf-oncrpc-auth-06 INFORMATIONAL INFORMATIONAL IETF tsv oncrpc 10.17487/RFC2695
RFC2696 LDAP Control Extension for Simple Paged Results Manipulation C. Weider A. Herron A. Anantha T. Howes September 1999 ASCII 12809 7 lightweight directory access protocol client server

This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community.

draft-ietf-asid-ldapv3-simplepaged-03 INFORMATIONAL INFORMATIONAL IETF app ldapext 10.17487/RFC2696
RFC2697 A Single Rate Three Color Marker J. Heinanen R. Guerin September 1999 ASCII 10309 6 srtcm stream ip internet protocol packet

This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community.

draft-heinanen-diffserv-srtcm-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2697
RFC2698 A Two Rate Three Color Marker J. Heinanen R. Guerin September 1999 ASCII 9368 5 trTCM stream ip internet protocol packet

This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community.

draft-heinanen-diffserv-trtcm-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2698
RFC2699 Request for Comments Summary RFC Numbers 2600-2699 S. Ginoza May 2000 ASCII 42462 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2699 RFC2700 Internet Official Protocol Standards J. Reynolds R. Braden August 2000 ASCII 90213 32

This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering Task Force (IETF). [STANDARDS-TRACK]

RFC2600 RFC2800 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2700 10.17487/RFC2700
RFC2701 Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol G. Malkin September 1999 ASCII 17571 9 point-to-point POP presence RAS remote access server

This document specifies a standard way for Multi-link PPP to operate across multiple nodes. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2701
RFC2702 Requirements for Traffic Engineering Over MPLS D. Awduche J. Malcolm J. Agogbua M. O'Dell J. McManus September 1999 ASCII 68386 29 multiprotocol label switching

This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community.

draft-ietf-mpls-traffic-eng-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=2702 10.17487/RFC2702
RFC2703 Protocol-independent Content Negotiation Framework G. Klyne September 1999 ASCII 42071 20 feature resource media syntax

This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. This memo provides information for the Internet community.

draft-ietf-conneg-requirements-02 INFORMATIONAL INFORMATIONAL IETF app conneg 10.17487/RFC2703
RFC2704 The KeyNote Trust-Management System Version 2 M. Blaze J. Feigenbaum J. Ioannidis A. Keromytis September 1999 ASCII 79998 37 security policy maker system credentials

This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. This memo provides information for the Internet community.

draft-blaze-ietf-trustmgt-keynote-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2704
RFC2705 Media Gateway Control Protocol (MGCP) Version 1.0 M. Arango A. Dugan I. Elliott C. Huitema S. Pickett October 1999 ASCII 304056 134 voice IP internet VoIP

This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements. This memo provides information for the Internet community.

draft-huitema-megaco-mgcp-v1-00 RFC3435 RFC3660 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2705
RFC2706 ECML v1: Field Names for E-Commerce D. Eastlake 3rd T. Goldstein October 1999 ASCII 26135 13 electronic commerce modeling language merchant site. web

A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. This memo provides information for the Internet community.

draft-eastlake-ecom-fields-01 RFC3106 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2706
RFC2707 Job Monitoring MIB - V1.0 R. Bergman T. Hastings S. Isaacson H. Lewis November 1999 ASCII 255685 114 management information base

This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This memo provides information for the Internet community.

draft-ietf-printmib-job-monitor-08 INFORMATIONAL INFORMATIONAL IETF app printmib 10.17487/RFC2707
RFC2708 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB R. Bergman November 1999 ASCII 57489 26 management information base

This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. This memo provides information for the Internet community.

draft-ietf-printmib-job-protomap-04 INFORMATIONAL INFORMATIONAL IETF app printmib 10.17487/RFC2708
RFC2709 Security Model with Tunnel-mode IPsec for NAT Domains P. Srisuresh October 1999 ASCII 24552 11 internet protocol network address translator

This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. This memo provides information for the Internet community.

draft-ietf-nat-security-02 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC2709
RFC2710 Multicast Listener Discovery (MLD) for IPv6 S. Deering W. Fenner B. Haberman October 1999 ASCII 46838 22 MLD-IPv6 internet protocol routher packets

This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK]

draft-ietf-ipngwg-mld-02 RFC3590 RFC3810 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2710
RFC2711 IPv6 Router Alert Option C. Partridge A. Jackson October 1999 ASCII 11973 6 internet protocol datagram routher hop-by-hop

This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]

draft-ietf-ipngwg-ipv6router-alert-06 RFC6398 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2711
RFC2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) A. Medvinsky M. Hur October 1999 ASCII 13763 7 TLS authentication cryptography

This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS-TRACK]

draft-ietf-tls-kerb-cipher-suites-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC2712
RFC2713 Schema for Representing Java(tm) Objects in an LDAP Directory V. Ryan S. Seligman R. Lee October 1999 ASCII 40745 21 lightweight directory access protocol

This document defines the schema for representing Java(tm) objects in an LDAP directory. This memo provides information for the Internet community.

draft-ryan-java-schema-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2713
RFC2714 Schema for Representing CORBA Object References in an LDAP Directory V. Ryan R. Lee S. Seligman October 1999 ASCII 14709 10 lightweight directory access protocol

This document defines the schema for representing CORBA object references in an LDAP directory. This memo provides information for the Internet community.

draft-ryan-corba-schema-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2714
RFC2715 Interoperability Rules for Multicast Routing Protocols D. Thaler October 1999 ASCII 49638 22 border router MBRs autonomous

The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. This memo provides information for the Internet community.

draft-thaler-multicast-interop-03 INFORMATIONAL INFORMATIONAL IETF rtg idmr 10.17487/RFC2715
RFC2716 PPP EAP TLS Authentication Protocol B. Aboba D. Simon October 1999 ASCII 50108 24 point-to-point link control compression extensible transport level security

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pppext-eaptls-06 RFC5216 EXPERIMENTAL EXPERIMENTAL IETF int pppext 10.17487/RFC2716
RFC2717 Registration Procedures for URL Scheme Names R. Petke I. King November 1999 ASCII 19780 10 uniform resource locator syntax semantics

This document defines the process by which new URL scheme names are registered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-urlreg-procedures-08 RFC4395 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urlreg 10.17487/RFC2717
RFC2718 Guidelines for new URL Schemes L. Masinter H. Alvestrand D. Zigmond R. Petke November 1999 ASCII 19208 10 uniform resource locator syntax semantics

This document provides guidelines for the definition of new URL schemes. This memo provides information for the Internet community.

draft-ietf-urlreg-guide-05 RFC4395 INFORMATIONAL INFORMATIONAL IETF app urlreg 10.17487/RFC2718
RFC2719 Framework Architecture for Signaling Transport L. Ong I. Rytina M. Garcia H. Schwarzbauer L. Coene H. Lin I. Juhasz M. Holdrege C. Sharp October 1999 ASCII 48646 24 IP Internet Protocol gateway media circuit

This document defines an architecture framework and functional requirements for transport of signaling information over IP. This memo provides information for the Internet community.

draft-ietf-sigtran-framework-arch-03 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC2719
RFC2720 Traffic Flow Measurement: Meter MIB N. Brownlee October 1999 ASCII 103781 55 management information base

This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. [STANDARDS-TRACK]

draft-ietf-rtfm-meter-mib-11 RFC2064 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rtfm 10.17487/RFC2720
RFC2721 RTFM: Applicability Statement N. Brownlee October 1999 ASCII 21200 10 real-time traffic flow measurement

This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations. This memo provides information for the Internet community.

draft-ietf-rtfm-applicability-statement-04 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2721
RFC2722 Traffic Flow Measurement: Architecture N. Brownlee C. Mills G. Ruth October 1999 ASCII 114064 48 network meters data

This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet. This memo provides information for the Internet community.

draft-ietf-rtfm-architecture-08 RFC2063 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2722
RFC2723 SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups N. Brownlee October 1999 ASCII 44406 22 simple ruleset RTFM real-time network measurement

This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. This memo provides information for the Internet community.

draft-ietf-rtfm-ruleset-language-07 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2723
RFC2724 RTFM: New Attributes for Traffic Flow Measurement S. Handelman S. Stibler N. Brownlee G. Ruth October 1999 ASCII 37951 18 real-time network

This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rtfm-new-traffic-flow-10 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2724
RFC2725 Routing Policy System Security C. Villamizar C. Alaettinoglu D. Meyer S. Murphy December 1999 ASCII 101649 41 RPSL database registry authentication

The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. [STANDARDS-TRACK]

draft-ietf-rps-auth-04 RFC4012 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2725
RFC2726 PGP Authentication for RIPE Database Updates J. Zsako December 1999 ASCII 22594 11 pretty good privacy security digital signatures

This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. [STANDARDS-TRACK]

draft-ietf-rps-dbsec-pgp-authent-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2726
RFC2727 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin February 2000 ASCII 33396 15 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-poisson-nomcom-v2-01 RFC2282 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC2727
RFC2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal R. Panabaker S. Wegerif D. Zigmond November 1999 ASCII 49099 23 internet protocol IPVBI

This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS-TRACK]

draft-ietf-ipvbi-nabts-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ipvbi 10.17487/RFC2728
RFC2729 Taxonomy of Communication Requirements for Large-scale Multicast Applications P. Bagnall R. Briscoe A. Poppitt December 1999 ASCII 53322 27 LSMA dynamic protocol mapping

The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). This memo provides information for the Internet community.

draft-ietf-lsma-requirements-04 INFORMATIONAL INFORMATIONAL IETF app lsma 10.17487/RFC2729
RFC2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP) S. Hanna B. Patel M. Shah December 1999 ASCII 120341 53 MADCAP client server scope zone host

This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS-TRACK]

draft-ietf-malloc-madcap-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC2730
RFC2731 Encoding Dublin Core Metadata in HTML J. Kunze December 1999 ASCII 42450 23 hypertext markup language xml extensible

The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community.

draft-kunze-dchtml-02 RFC5791 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2731 10.17487/RFC2731
RFC2732 Format for Literal IPv6 Addresses in URL's R. Hinden B. Carpenter L. Masinter December 1999 ASCII 7984 5 Internet protocol uniform resource identifier www world wide web

This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. [STANDARDS-TRACK]

draft-ietf-ipngwg-url-literal-04 RFC3986 RFC2396 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2732 10.17487/RFC2732
RFC2733 An RTP Payload Format for Generic Forward Error Correction J. Rosenberg H. Schulzrinne December 1999 ASCII 53120 26 FEC real-time protocol stream

This document specifies a payload format for generic forward error correction of media encapsulated in RTP. [STANDARDS-TRACK]

draft-ietf-avt-fec-08 RFC5109 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2733
RFC2734 IPv4 over IEEE 1394 P. Johansson December 1999 ASCII 69314 29 internet protocol datagrams packet encapsulation ARP address resolution multicast

This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS-TRACK]

draft-ietf-ip1394-ipv4-19 PROPOSED STANDARD PROPOSED STANDARD IETF int ip1394 10.17487/RFC2734
RFC2735 NHRP Support for Virtual Private Networks B. Fox B. Petri December 1999 ASCII 26451 12 next hop resolution protocol VPN addresses

The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address. This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network. [STANDARDS-TRACK]

draft-ietf-ion-nhrp-vpn-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2735
RFC2736 Guidelines for Writers of RTP Payload Format Specifications M. Handley C. Perkins December 1999 ASCII 24143 10 real-time transport protocol data types audio video codecs

This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-avt-rtp-format-guidelines-04 BCP0036 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai avt 10.17487/RFC2736
RFC2737 Entity MIB (Version 2) K. McCloghrie A. Bierman December 1999 ASCII 125141 56 management information base SNMP simple network protocol

This memo defines a portion of the Management Information Base (M for use with network management protocols in the Internet communi In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]

draft-ietf-entmib-v2-06 RFC2037 RFC4133 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=2737 10.17487/RFC2737
RFC2738 Corrections to "A Syntax for Describing Media Feature Sets" G. Klyne December 1999 ASCII 8353 5 FEC real-time protocol stream

In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates. [STANDARDS-TRACK]

draft-ietf-conneg-feature-syntax-er-00 RFC2533 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2738
RFC2739 Calendar Attributes for vCard and LDAP T. Small D. Hennessy F. Dawson January 2000 ASCII 25892 16 lightweight directory access protocol

This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS-TRACK]

draft-ietf-calsch-locating-03 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch 10.17487/RFC2739
RFC2740 OSPF for IPv6 R. Coltun D. Ferguson J. Moy December 1999 ASCII 189810 80 internet protocol open shortest path first

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

draft-ietf-ospf-ospfv6-08 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2740 10.17487/RFC2740
RFC2741 Agent Extensibility (AgentX) Protocol Version 1 M. Daniele B. Wijnen M. Ellison D. Francisco January 2000 ASCII 199867 91 SNMP simple network management

This memo defines a standardized framework for extensible SNMP agents. [STANDARDS-TRACK]

draft-ietf-agentx-rfc-update-03 RFC2257 DRAFT STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2741
RFC2742 Definitions of Managed Objects for Extensible SNMP Agents L. Heintz S. Gudur M. Ellison January 2000 ASCII 36644 20 SNMP management information base simple network protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. [STANDARDS-TRACK]

draft-ietf-agentx-mib-05 DRAFT STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2742
RFC2743 Generic Security Service Application Program Interface Version 2, Update 1 J. Linn January 2000 ASCII 229418 101 GSS-API portability application authentication cryptology

This memo obsoletes [STANDARDS-TRACK]

draft-ietf-cat-rfc2078bis-08 RFC2078 RFC5554 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=2743 10.17487/RFC2743
RFC2744 Generic Security Service API Version 2 : C-bindings J. Wray January 2000 ASCII 218572 101 GSS-API cryptology authentication

This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC 2743. [STANDARDS-TRACK]

draft-ietf-cat-gssv2-cbind-09 RFC1509 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=2744 10.17487/RFC2744
RFC2745 RSVP Diagnostic Messages A. Terzis B. Braden S. Vincent L. Zhang January 2000 ASCII 52256 23 resource reservation protocol network management

This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. [STANDARDS-TRACK]

draft-ietf-rsvp-diagnostic-msgs-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2745
RFC2746 RSVP Operation Over IP Tunnels A. Terzis J. Krawczyk J. Wroclawski L. Zhang January 2000 ASCII 58094 25 resource reservation protocol internet

This document describes an approach for providing RSVP protocol services over IP tunnels. [STANDARDS-TRACK]

draft-ietf-rsvp-tunnel-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2746
RFC2747 RSVP Cryptographic Authentication F. Baker B. Lindell M. Talwar January 2000 ASCII 49477 21 resource reservation protocol security

This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-TRACK]

draft-ietf-rsvp-md5-08 RFC3097 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2747 10.17487/RFC2747
RFC2748 The COPS (Common Open Policy Service) Protocol D. Durham Editor J. Boyle R. Cohen S. Herzog R. Rajan A. Sastry January 2000 ASCII 90906 38 COPS qos quality of service signaling

This document describes a simple client/server model for supporting policy control over QoS signaling protocols. [STANDARDS-TRACK]

draft-ietf-rap-cops-08 RFC4261 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2748
RFC2749 COPS usage for RSVP S. Herzog Editor J. Boyle R. Cohen D. Durham R. Rajan A. Sastry January 2000 ASCII 33477 17 common open policy resource reservation protocol

This document describes usage directives for supporting COPS policy services in RSVP environments. [STANDARDS-TRACK]

draft-ietf-rap-cops-rsvp-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2749
RFC2750 RSVP Extensions for Policy Control S. Herzog January 2000 ASCII 26379 13 resource reservation protocol admission

This memo presents a set of extensions for supporting generic policy based admission control in RSVP. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-ext-06 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2750
RFC2751 Signaled Preemption Priority Policy Element S. Herzog January 2000 ASCII 21451 12 RSVP COPS resource reservation protocol common open service

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as RSVP and COPS). [STANDARDS-TRACK]

draft-ietf-rap-signaled-priority-04 RFC3181 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2751
RFC2752 Identity Representation for RSVP S. Yadav R. Yavatkar R. Pabbati P. Ford T. Moore S. Herzog January 2000 ASCII 33954 17 resource reservation protocol admission authentication

This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in RSVP. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-identity-05 RFC3182 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2752
RFC2753 A Framework for Policy-based Admission Control R. Yavatkar D. Pendarakis R. Guerin January 2000 ASCII 49763 20

This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community.

draft-ietf-rap-framework-03 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC2753
RFC2754 RPS IANA Issues C. Alaettinoglu C. Villamizar R. Govindan January 2000 ASCII 11582 7 internet assigned numbers authority routing policy specification system security

RPS Security requires certain RPSL objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required from IANA. This memo provides information for the Internet community.

draft-ietf-rps-iana-02 RFC6254 HISTORIC INFORMATIONAL IETF ops rps 10.17487/RFC2754
RFC2755 Security Negotiation for WebNFS A. Chiu M. Eisler B. Callaghan January 2000 ASCII 23493 12 RSVP QOS resource reservation protocol quality of service

This document describes a protocol for a WebNFS client (RFC2054) to negotiate the desired security mechanism with a WebNFS server (RFC2055) before the WebNFS client falls back to the MOUNT v3 protocol (RFC1813). This document is provided so that people can write compatible implementations. This memo provides information for the Internet community.

draft-chiu-network-wnfs-sec-nego-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2755
RFC2756 Hyper Text Caching Protocol (HTCP/0.0) P. Vixie D. Wessels January 2000 ASCII 32176 15 HTCP hypertext transfer protocol caches data

This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions. This memo defines an Experimental Protocol for the Internet community.

draft-vixie-htcp-proto-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2756
RFC2757 Long Thin Networks G. Montenegro S. Dawkins M. Kojo V. Magret N. Vaidya January 2000 ASCII 112988 46 wireless WAN wide area networks TCP transmission control protocol

Our goal is to identify a TCP that works for all users, including users of long thin networks. This memo provides information for the Internet community.

draft-montenegro-pilc-ltn-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2757
RFC2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring K. White February 2000 ASCII 145581 71 MIB management information base SLAs

This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. This memo defines an Experimental Protocol for the Internet community.

draft-white-slapm-mib-06 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2758
RFC2759 Microsoft PPP CHAP Extensions, Version 2 G. Zorn January 2000 ASCII 34178 20 point-to-point protocol challenge handshake authentication

This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1). This memo provides information for the Internet community.

draft-ietf-pppext-mschap-v2-04 INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2759 10.17487/RFC2759
RFC2760 Ongoing TCP Research Related to Satellites M. Allman Editor S. Dawkins D. Glover J. Griner D. Tran T. Henderson J. Heidemann J. Touch H. Kruse S. Ostermann K. Scott J. Semke February 2000 ASCII 111141 46 transmission control protocol bandwidth network links

This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. This memo provides information for the Internet community.

draft-ietf-tcpsat-res-issues-12 INFORMATIONAL INFORMATIONAL IETF tsv tcpsat 10.17487/RFC2760
RFC2761 Terminology for ATM Benchmarking J. Dunn C. Martin February 2000 ASCII 61219 32 asynchronous transfer mode performance

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices. This memo provides information for the Internet community.

draft-ietf-bmwg-atm-term-00 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2761
RFC2762 Sampling of the Group Membership in RTP J. Rosenberg H. Schulzrinne February 2000 ASCII 25796 12 real-time transport protocol packets

This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-avt-rtpsample-06 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC2762
RFC2763 Dynamic Hostname Exchange Mechanism for IS-IS N. Shen H. Smit February 2000 ASCII 8593 5 intermediate system routers TLV

This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. This memo provides information for the Internet community.

draft-ietf-isis-dyname-02 RFC5301 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=2763 10.17487/RFC2763
RFC2764 A Framework for IP Based Virtual Private Networks B. Gleeson A. Lin J. Heinanen G. Armitage A. Malis February 2000 ASCII 163215 62 VPN internet protocol backbone

This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community.

draft-gleeson-vpn-framework-03 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2764 10.17487/RFC2764
RFC2765 Stateless IP/ICMP Translation Algorithm (SIIT) E. Nordmark February 2000 ASCII 59465 26 SIIT internet protocol control message IPv4 IPv6

This document specifies a transition mechanism algorithm in addition to the mechanisms already specified. [STANDARDS-TRACK]

draft-ietf-ngtrans-siit-08 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2765
RFC2766 Network Address Translation - Protocol Translation (NAT-PT) G. Tsirtsis P. Srisuresh February 2000 ASCII 49836 21 NAT-PT IPv4 IPv6 internet

This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified. [STANDARDS-TRACK]

draft-ietf-ngtrans-natpt-07 RFC4966 RFC3152 HISTORIC PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2766
RFC2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) K. Tsuchiya H. Higuchi Y. Atarashi February 2000 ASCII 26402 13 IPv4 IPv6 internet protocol applications

This memo proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. This memo provides information for the Internet community.

draft-ietf-ngtrans-bis-00 RFC6535 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2767
RFC2768 Network Policy and Services: A Report of a Workshop on Middleware B. Aiken J. Strassner B. Carpenter I. Foster C. Lynch J. Mambretti R. Moore B. Teitelbaum February 2000 ASCII 81034 29 protocols internet applications

An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified. This memo provides information for the Internet community.

draft-aiken-middleware-reqndef-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2768
RFC2769 Routing Policy System Replication C. Villamizar C. Alaettinoglu R. Govindan D. Meyer February 2000 ASCII 95255 42 RPSL database language

This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC. [STANDARDS-TRACK]

draft-ietf-rps-dist-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2769
RFC2770 GLOP Addressing in 233/8 D. Meyer P. Lothberg February 2000 ASCII 8988 5 multicast allocation global

This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mboned-glop-addressing-02 RFC3180 EXPERIMENTAL EXPERIMENTAL IETF ops mboned 10.17487/RFC2770
RFC2771 An Abstract API for Multicast Address Allocation R. Finlayson February 2000 ASCII 20954 11 application programming interfaces service

This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. This memo provides information for the Internet community.

draft-ietf-malloc-api-07 INFORMATIONAL INFORMATIONAL IETF tsv malloc 10.17487/RFC2771
RFC2772 6Bone Backbone Routing Guidelines R. Rockell R. Fink February 2000 ASCII 28565 14 IP internet protocol routing

This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. This memo provides information for the Internet community.

draft-ietf-ngtrans-harden-04 RFC2546 RFC3152 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2772
RFC2773 Encryption using KEA and SKIPJACK R. Housley P. Yee W. Nace February 2000 ASCII 20008 9 key exchange algorithm symmetric

This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October

draft-ietf-cat-ftpkeasj-01 RFC0959 EXPERIMENTAL EXPERIMENTAL IETF sec cat 10.17487/RFC2773
RFC2774 An HTTP Extension Framework H. Nielsen P. Leach S. Lawrence February 2000 ASCII 39719 20 hyper-text transfer protocol

This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. This memo defines an Experimental Protocol for the Internet community.

draft-frystyk-http-extensions-03 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2774
RFC2775 Internet Transparency B. Carpenter February 2000 ASCII 42956 18 end-to-end network layer connectivity

This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency.

draft-carpenter-transparency-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2775
RFC2776 Multicast-Scope Zone Announcement Protocol (MZAP) M. Handley D. Thaler R. Kermode February 2000 ASCII 61628 27 MZAP packets addresses service location

This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. [STANDARDS-TRACK]

draft-ietf-mboned-mzap-06 HISTORIC PROPOSED STANDARD IETF ops mboned 10.17487/RFC2776
RFC2777 Publicly Verifiable Nomcom Random Selection D. Eastlake 3rd February 2000 ASCII 30064 16 Internet Engineering Task Force IETF

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. This memo provides information for the Internet community.

draft-eastlake-selection-04 RFC3797 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2777
RFC2778 A Model for Presence and Instant Messaging M. Day J. Rosenberg H. Sugano February 2000 ASCII 35153 17 service users MIME multipurpose Internet mail extensions

This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. This memo provides information for the Internet community.

draft-ietf-impp-model-03 INFORMATIONAL INFORMATIONAL IETF app impp 10.17487/RFC2778
RFC2779 Instant Messaging / Presence Protocol Requirements M. Day S. Aggarwal G. Mohr J. Vincent February 2000 ASCII 47420 26 MIME multipurpose Internet mail extensions service users

This document defines a minimal set of requirements that IMPP must meet. This memo provides information for the Internet community.

draft-ietf-impp-reqts-04 INFORMATIONAL INFORMATIONAL IETF app impp 10.17487/RFC2779
RFC2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers S. Bradner V. Paxson March 2000 ASCII 18954 10 internet assigned numbers authority IP

This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-bradner-iana-allocation-05 RFC4443 RFC5237 RFC5771 RFC6335 RFC7045 BCP0037 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2780
RFC2781 UTF-16, an encoding of ISO 10646 P. Hoffman F. Yergeau February 2000 ASCII 29870 14 unicode character data code point

This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community.

draft-hoffman-utf16-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2781
RFC2782 A DNS RR for specifying the location of services (DNS SRV) A. Gulbrandsen P. Vixie L. Esibov February 2000 ASCII 24013 12 DNS-SRV domain name system resource record

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]

draft-ietf-dnsind-rfc2052bis-05 RFC2052 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=2782 10.17487/RFC2782
RFC2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0 J. Mogul D. Mills J. Brittenson J. Stone U. Windl March 2000 ASCII 61421 31 NTP time clock synchronization

RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. This memo provides information for the Internet community.

draft-mogul-pps-api-06 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2783
RFC2784 Generic Routing Encapsulation (GRE) D. Farinacci T. Li S. Hanks D. Meyer P. Traina March 2000 ASCII 16627 9 GRE packet size payload

This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK]

draft-meyer-gre-update-03 RFC2890 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2784 10.17487/RFC2784
RFC2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME R. Zuccherato March 2000 ASCII 24415 11 security multipurpose internet mail extensions

This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. This memo provides information for the Internet community.

draft-ietf-smime-small-subgroup-03 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC2785
RFC2786 Diffie-Helman USM Key Management Information Base and Textual Convention M. St. Johns March 2000 ASCII 43280 20 mib security user-based model Hellman

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges an set of objects which extend the usmUserTable to permit the use of DH key exchange in addition to the key change method. This memo defines an Experimental Protocol for the Internet community.

draft-stjohns-snmpv3-dhkeychange-mib-02 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2786 10.17487/RFC2786
RFC2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol B. Jewell D. Chuang March 2000 ASCII 56672 31 management information base

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP). [STANDARDS-TRACK]

draft-ietf-vrrp-mib-09 RFC6527 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp 10.17487/RFC2787
RFC2788 Network Services Monitoring MIB N. Freed S. Kille March 2000 ASCII 43906 22 management information base

This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS-TRACK]

draft-ietf-madman-netsm-mib-07 RFC2248 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2788
RFC2789 Mail Monitoring MIB N. Freed S. Kille March 2000 ASCII 65671 33 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [STANDARDS-TRACK]

draft-ietf-madman-email-mib-06 RFC2249 RFC1566 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2789
RFC2790 Host Resources MIB S. Waldbusser P. Grillo March 2000 ASCII 95807 50 management information base

This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. [STANDARDS-TRACK]

draft-ops-hostmib-01 RFC1514 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2790
RFC2791 Scalable Routing Design Principles J. Yu July 2000 ASCII 63416 26 network packets

This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks. This memo provides information for the Internet community.

draft-yu-routing-scaling-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2791
RFC2792 DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System M. Blaze J. Ioannidis A. Keromytis March 2000 ASCII 13461 7 cryptology digial signatures

This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. This memo provides information for the Internet community.

draft-angelos-keynote-dsa-rsa-encoding-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2792
RFC2793 RTP Payload for Text Conversation G. Hellstrom May 2000 ASCII 20674 10 real-time applications video audio packets

This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. [STANDARDS-TRACK]

draft-ietf-avt-rtp-text-05 RFC4103 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2793
RFC2794 Mobile IP Network Access Identifier Extension for IPv4 P. Calhoun C. Perkins March 2000 ASCII 16960 9 internet protocol NAI

Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. [STANDARDS-TRACK]

draft-ietf-mobileip-mn-nai-07 RFC2290 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2794
RFC2795 The Infinite Monkey Protocol Suite (IMPS) S. Christey April 1 2000 ASCII 42902 20 control packet client

This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. This memo provides information for the Internet community.

draft-christey-imps-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2795
RFC2796 BGP Route Reflection - An Alternative to Full Mesh IBGP T. Bates R. Chandra E. Chen April 2000 ASCII 20174 11 border gateway protocol

This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. [STANDARDS-TRACK]

draft-ietf-idr-route-reflect-v2-03 RFC4456 RFC1966 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2796
RFC2797 Certificate Management Messages over CMS M. Myers X. Liu J. Schaad J. Weinstein April 2000 ASCII 103357 47 certificate management protocol cryptology syntax

This document defines a Certificate Management protocol using CMS (CMC). [STANDARDS-TRACK]

draft-ietf-pkix-cmc-05 RFC5272 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2797 10.17487/RFC2797
RFC2798 Definition of the inetOrgPerson LDAP Object Class M. Smith April 2000 ASCII 32929 20 lightweight directory access protocol directory services

We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. This memo provides information for the Internet community.

draft-smith-ldap-inetorgperson-03 RFC3698 RFC4519 RFC4524 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2798
RFC2799 Request for Comments Summary RFC Numbers 2700-2799 S. Ginoza September 2000 ASCII 42622 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2799 RFC2800 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza May 2001 ASCII 101648 38

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to the RFC series. [STANDARDS-TRACK]

RFC2700 RFC2900 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2800
RFC2801 Internet Open Trading Protocol - IOTP Version 1.0 D. Burdett April 2000 ASCII 598794 290 commerce payment system merchant

This document discusses the Internet Open Trading Protocol (IOTP) and its provision of an interoperable framework for Internet commerce. This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1.0-protocol-07 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2801
RFC2802 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) K. Davidson Y. Kawatsura April 2000 ASCII 52756 29 commerce payment system xml extensible markup language security

This document describes the syntax and procedures for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP). This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1.0-dsig-05 INFORMATIONAL INFORMATIONAL IETF app trade http://www.rfc-editor.org/errata_search.php?rfc=2802 10.17487/RFC2802
RFC2803 Digest Values for DOM (DOMHASH) H. Maruyama K. Tamura N. Uramoto April 2000 ASCII 22552 11 xml extensible markup language secruity

This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This memo provides information for the Internet community.

draft-ietf-trade-hiroshi-dom-hash-03 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2803
RFC2804 IETF Policy on Wiretapping IAB IESG May 2000 ASCII 18934 10 internet engineering task force

This document describes the position that the Internet Engineering Task Force (IETF) has taken regarding the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means. This memo provides information for the Internet community.

draft-iab-raven-01 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2804 10.17487/RFC2804
RFC2805 Media Gateway Control Protocol Architecture and Requirements N. Greene M. Ramalho B. Rosen April 2000 ASCII 88190 45 MG mapping transcoding network

This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway. This memo provides information for the Internet community.

draft-ietf-megaco-reqs-10 INFORMATIONAL INFORMATIONAL IETF rai megaco 10.17487/RFC2805
RFC2806 URLs for Telephone Calls A. Vaha-Sipila April 2000 ASCII 50647 21 uniform resource locator schemes

This document specifies URL (Uniform Resource Locator) schemes "tel", "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. [STANDARDS-TRACK]

draft-antti-telephony-url-12 RFC3966 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2806
RFC2807 XML Signature Requirements J. Reagle July 2000 ASCII 21973 9 digital extensible markup language

This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. This memo provides information for the Internet community.

draft-ietf-xmldsig-requirements-03 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC2807
RFC2808 The SecurID(r) SASL Mechanism M. Nystrom April 2000 ASCII 20342 11 simple authentication security layer

This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism using SecurID (a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication), thereby providing a means for such tokens to be used in SASL environments. This mechanism is only is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo provides information for the Internet community.

draft-nystrom-securid-sasl-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2808
RFC2809 Implementation of L2TP Compulsory Tunneling via RADIUS B. Aboba G. Zorn April 2000 ASCII 47259 23 remote authentication dial-in user service layer two

This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP (Layer Two Tunneling Protocol) protocol. This memo provides information for the Internet community.

draft-ietf-radius-tunnel-imp-05 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2809
RFC2810 Internet Relay Chat: Architecture C. Kalt April 2000 ASCII 19087 10 IRC text based conferencing

This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here. This memo provides information for the Internet community.

draft-kalt-irc-arch-00 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2810 10.17487/RFC2810
RFC2811 Internet Relay Chat: Channel Management C. Kalt April 2000 ASCII 40788 19 IRC text based conferencing

This document specifies how channels, their characteristics and properties are managed by IRC servers. This memo provides information for the Internet community.

draft-kalt-irc-chan-01 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2811
RFC2812 Internet Relay Chat: Client Protocol C. Kalt April 2000 ASCII 122637 63 IRC text based conferencing

This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture. This memo provides information for the Internet community.

draft-kalt-irc-client-03 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2812 10.17487/RFC2812
RFC2813 Internet Relay Chat: Server Protocol C. Kalt April 2000 ASCII 56681 26 IRC text based conferencing

This document defines the protocol used by servers to talk to each other. This memo provides information for the Internet community.

draft-kalt-irc-server-02 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2813 10.17487/RFC2813
RFC2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks R. Yavatkar D. Hoffman Y. Bernet F. Baker M. Speer May 2000 ASCII 141886 60 LAN local area resource reservation

This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. [STANDARDS-TRACK]

draft-ietf-issll-is802-sbm-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2814
RFC2815 Integrated Service Mappings on IEEE 802 Networks M. Seaman A. Smith E. Crawley J. Wroclawski May 2000 ASCII 42403 17 LAN local area resource reservation

This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). [STANDARDS-TRACK]

draft-ietf-issll-is802-svc-mapping-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2815
RFC2816 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies A. Ghanwani J. Pace V. Srinivasan A. Smith M. Seaman May 2000 ASCII 119043 47 LAN local area network parameter switches

This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. This memo provides information for the Internet community.

draft-ietf-issll-is802-framework-07 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2816
RFC2817 Upgrading to TLS Within HTTP/1.1 R. Khare S. Lawrence May 2000 ASCII 27598 13 hypertext transfer protocol transport layer security

This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]

draft-ietf-tls-http-upgrade-05 RFC2616 RFC7230 RFC7231 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2817 10.17487/RFC2817
RFC2818 HTTP Over TLS E. Rescorla May 2000 ASCII 15170 7 hypertext transfer protocol transport layer security

This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.

draft-ietf-tls-https-04 RFC5785 RFC7230 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2818 10.17487/RFC2818
RFC2819 Remote Network Monitoring Management Information Base S. Waldbusser May 2000 ASCII 198676 98 RMON-MIB MIB RMON

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

draft-ietf-rmonmib-rmonfull-02 RFC1757 STD0059 INTERNET STANDARD INTERNET STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=2819 10.17487/RFC2819
RFC2820 Access Control Requirements for LDAP E. Stokes D. Byrne B. Blakley P. Behera May 2000 ASCII 18172 9 lightweight directory access protocol

This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. This memo provides information for the Internet community.

draft-ietf-ldapext-acl-reqts-03 INFORMATIONAL INFORMATIONAL IETF app ldapext http://www.rfc-editor.org/errata_search.php?rfc=2820 10.17487/RFC2820
RFC2821 Simple Mail Transfer Protocol J. Klensin Editor April 2001 ASCII 192504 79 SMTP

This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. [STANDARDS-TRACK]

draft-ietf-drums-smtpupd-13 RFC0821 RFC0974 RFC1869 RFC5321 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2821 10.17487/RFC2821
RFC2822 Internet Message Format P. Resnick Editor April 2001 ASCII 110695 51 MAIL

This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]

draft-ietf-drums-msg-fmt-09 RFC0822 RFC5322 RFC5335 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2822 10.17487/RFC2822
RFC2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing J. Carlson P. Langner E. Hernandez-Valencia J. Manchester May 2000 ASCII 60049 28 PPP-SDL point-to-point protocol synchronous optical network digital hierarchy data link simple

This document extends methods found in the Point-to-Point Protocol (PPP) and RFCs 1662 and 2615 to include a new encapsulation for PPP called Simple Data Link (SDL). SDL provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 and 2615 provide a means to carry PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pppext-sdl-06 EXPERIMENTAL EXPERIMENTAL IETF int pppext 10.17487/RFC2823
RFC2824 Call Processing Language Framework and Requirements J. Lennox H. Schulzrinne May 2000 ASCII 58711 25 CPL-F telephony signalling network devices

This document describes an architectural framework we call a processing language, as a simple and standardized way for implementing and deploying Internet telephony. A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. It also outlines requirements for such a language. This memo provides information for the Internet community.

draft-ietf-iptel-cpl-framework-02 INFORMATIONAL INFORMATIONAL IETF rai iptel 10.17487/RFC2824
RFC2825 A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols IAB L. Daigle Editor May 2000 ASCII 15612 7 character sets e-commerce interoperability

This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces. This memo provides information for the Internet community.

draft-iab-i18n-dns-01 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2825 10.17487/RFC2825
RFC2826 IAB Technical Comment on the Unique DNS Root Internet Architecture Board May 2000 ASCII 13400 6 Internet Architecture Board domain name system

This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community.

draft-iab-unique-dns-root-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2826
RFC2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing P. Ferguson D. Senie May 2000 ASCII 21258 10 ISP Internet Service Provider Internet Protocol DOS

This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2267 RFC3704 BCP0038 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2827 10.17487/RFC2827
RFC2828 Internet Security Glossary R. Shirey May 2000 ASCII 489292 212 information system ISD internet standard documents

This Glossary provides abbreviations, explanations, and recommendations for use of information system security terminology. This memo provides information for the Internet community.

draft-shirey-security-glossary-02 RFC4949 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2828
RFC2829 Authentication Methods for LDAP M. Wahl H. Alvestrand J. Hodges R. Morgan May 2000 ASCII 33471 16 lightweight directory access protocol security

This document specifies particular combinations of security mechanisms which are required and recommended in LDAP implementations. [STANDARDS-TRACK]

draft-ietf-ldapext-authmeth-04 RFC4513 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2829
RFC2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security J. Hodges R. Morgan M. Wahl May 2000 ASCII 24469 12 LDAP TLS

This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP. [STANDARDS-TRACK]

draft-ietf-ldapext-ldapv3-tls-06 RFC4511 RFC4513 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2830
RFC2831 Using Digest Authentication as a SASL Mechanism P. Leach C. Newman May 2000 ASCII 58124 27 http hypertext transfer protocol security simple layer

This specification defines how HTTP Digest Authentication can be used as a SASL mechanism for any protocol that has a SASL (Simple Authentication and Security Layer) profile. [STANDARDS-TRACK]

draft-leach-digest-sasl-05 RFC6331 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC2831
RFC2832 NSI Registry Registrar Protocol (RRP) Version 1.1.0 S. Hollenbeck M. Srivastava May 2000 ASCII 77057 39 RRP shared registration system gLTD ccTLD top level domain

This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top Level Domains (ccTLDs). This memo provides information for the Internet community.

draft-hollenbeck-rrp-01 RFC3632 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2832
RFC2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals H. Schulzrinne S. Petrack May 2000 ASCII 68786 30 real-time application protocol DTMF dual-tone multifrequency

This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. [STANDARDS-TRACK]

draft-ietf-avt-tones-07 RFC4733 RFC4734 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2833
RFC2834 ARP and IP Broadcast over HIPPI-800 J.-M. Pittet May 2000 ASCII 76243 34 address resolution protocol internet high-performance internface parallel

This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP (hardware addresses). This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC 2067 "IP over HIPPI") obsoletes RFC 1374. [STANDARDS-TRACK]

draft-pittet-hippiarp-05 RFC1374 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2834 10.17487/RFC2834
RFC2835 IP and ARP over HIPPI-6400 (GSN) J.-M. Pittet May 2000 ASCII 74178 33 GSN address resolution protocol internet high-performance internface parallel

This document further specifies a method for resolving IP addresses to HIPPI-6400 (High-Performance Parallel Interface) hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore, it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. [STANDARDS-TRACK]

draft-pittet-gsnlan-04 RFC5494 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2835
RFC2836 Per Hop Behavior Identification Codes S. Brim B. Carpenter F. Le Faucheur May 2000 ASCII 13399 7 PHB differentiated services codepoint DSCP

This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS-TRACK]

draft-ietf-diffserv-phbid-00 RFC3140 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC2836
RFC2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard K. Teow May 2000 ASCII 87860 48 MIB management information base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. [STANDARDS-TRACK]

draft-ietf-ipfc-fabric-element-mib-07 RFC4044 PROPOSED STANDARD PROPOSED STANDARD IETF int ipfc 10.17487/RFC2837
RFC2838 Uniform Resource Identifiers for Television Broadcasts D. Zigmond M. Vickers May 2000 ASCII 11405 6 URI TV WWW world wide web

This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community.

draft-zigmond-tv-url-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2838
RFC2839 Internet Kermit Service F. da Cruz J. Altman May 2000 ASCII 42726 20 file transfer management service

This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community.

draft-columbia-kermit-service-03 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2839 10.17487/RFC2839
RFC2840 TELNET KERMIT OPTION J. Altman F. da Cruz May 2000 ASCII 22519 12 file transfer management service

This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community.

draft-altman-telnet-kermit-server-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2840
RFC2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC) P. Metzger W. Simpson November 2000 ASCII 14139 9 IP-MAC encryption secure hash algorithm

This document describes the use of keyed SHA1 (Secure Hash Algorithm) with the IP Authentication Header. This memo defines a Historic Document for the Internet community.

draft-simpson-ah-sha-kdp-00 RFC1852 HISTORIC HISTORIC Legacy 10.17487/RFC2841
RFC2842 Capabilities Advertisement with BGP-4 R. Chandra J. Scudder May 2000 ASCII 8366 5 border gateway protocol

This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. [STANDARDS-TRACK]

draft-ietf-idr-bgp4-cap-neg-06 RFC3392 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2842
RFC2843 Proxy-PAR P. Droz T. Przygienda May 2000 ASCII 27891 13 PNNI augmented Routing ATM asynchronous transfer mode

The intention of this document is to provide general information about Proxy-PAR (PNNI Augmented Routing). [STANDARDS-TRACK]

draft-ietf-ion-proxypar-arch-02 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2843
RFC2844 OSPF over ATM and Proxy-PAR T. Przygienda P. Droz R. Haas May 2000 ASCII 32146 14 PNNI augmented Routing asynchronous transfer mode open shortest-path first

This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC (Permanent Virtual Connections) and SVC (Switched Virtual Circuit) meshes with the presence of Proxy-PAR (PNNI Augmented Routing). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ospf-atm-04 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC2844
RFC2845 Secret Key Transaction Authentication for DNS (TSIG) P. Vixie O. Gudmundsson D. Eastlake 3rd B. Wellington May 2000 ASCII 32272 15 TSIG domain name system transaction signature

This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS-TRACK]

draft-ietf-dnsext-tsig-00 RFC1035 RFC3645 RFC4635 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2845
RFC2846 GSTN Address Element Extensions in E-mail Services C. Allocchio June 2000 ASCII 54316 35 global switched telephone network

This memo defines a full syntax for a specific application in which there is a need to represent GSTN (Global Switched Telephone Network) addressing and Internet addressing. [STANDARDS-TRACK]

draft-ietf-fax-fulladdr-06 RFC3191 RFC3192 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=2846 10.17487/RFC2846
RFC2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM M. Eisler June 2000 ASCII 50045 22 LIPKEY client server simple pubilc key mechanism authentication

This memorandum describes a method whereby one can use GSS-API (Generic Security Service Application Program Interface) to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. [STANDARDS-TRACK]

draft-ietf-cat-lipkey-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2847
RFC2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services S. Petrack L. Conroy June 2000 ASCII 168851 73 session initiation protocol internet description

This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. [STANDARDS-TRACK]

draft-ietf-pint-protocol-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pint 10.17487/RFC2848
RFC2849 The LDAP Data Interchange Format (LDIF) - Technical Specification G. Good June 2000 ASCII 26017 14 LDIF lightweight directory access protocol file

This document describes a file format suitable for describing directory information or modifications made to directory information. [STANDARDS-TRACK]

draft-good-ldap-ldif-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2849 10.17487/RFC2849
RFC2850 Charter of the Internet Architecture Board (IAB) Internet Architecture Board B. Carpenter Editor May 2000 ASCII 15984 8 ISOC Internet Society IETF IRTF

This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-rfc1601bis-04 RFC1601 BCP0039 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC2850
RFC2851 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder June 2000 ASCII 32587 16 layer management information base inet address mib

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. [STANDARDS-TRACK]

draft-ops-endpoint-mib-08 RFC3291 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2851
RFC2852 Deliver By SMTP Service Extension D. Newman June 2000 ASCII 29285 13 simple mail transfer protocol client server

This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. [STANDARDS-TRACK]

draft-newman-deliver-03 RFC1894 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2852 10.17487/RFC2852
RFC2853 Generic Security Service API Version 2 : Java Bindings J. Kabat M. Upadhyay June 2000 ASCII 199512 96 GSI application program interface

This document specifies the Java bindings for GSS-API (Generic Security Service Application Program Interface) which is described at a language independent conceptual level in RFC 2743. [STANDARDS-TRACK]

draft-ietf-cat-gssv2-javabind-05 RFC5653 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2853
RFC2854 The 'text/html' Media Type D. Connolly L. Masinter June 2000 ASCII 16135 8 HTML-INT HTML WWW World Wide Web

This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations. This memo provides information for the Internet community.

draft-connolly-text-html-02 RFC2070 RFC1980 RFC1942 RFC1867 RFC1866 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2854
RFC2855 DHCP for IEEE 1394 K. Fujisawa June 2000 ASCII 8070 5 dynamic host configuration protocol high performance serial bus

This memo describes specific usage of some fields of DHCP (Dynamic Host Configuration Protocol) messages. IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. [STANDARDS-TRACK]

draft-ietf-ip1394-dhcp-04 PROPOSED STANDARD PROPOSED STANDARD IETF int ip1394 10.17487/RFC2855
RFC2856 Textual Conventions for Additional High Capacity Data Types A. Bierman K. McCloghrie R. Presuhn June 2000 ASCII 20954 10 SNMP simple network management protocol

This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. [STANDARDS-TRACK]

draft-kzm-hcdata-types-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2856
RFC2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH A. Keromytis N. Provos June 2000 ASCII 13544 7 ipsec encapsulating security payload authentication

This memo describes the use of the HMAC algorithm in conjunction with the RIPEMD-160 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload (ESP) and the revised IPSEC Authentication Header (AH). [STANDARDS-TRACK]

draft-ietf-ipsec-auth-hmac-ripemd-160-96-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2857
RFC2858 Multiprotocol Extensions for BGP-4 T. Bates Y. Rekhter R. Chandra D. Katz June 2000 ASCII 23305 11 MEXT-BGP4 Border gateway protocol router network layer

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). [STANDARDS-TRACK]

draft-ietf-idr-bgp4-multiprotocol-v2-05 RFC2283 RFC4760 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2858 10.17487/RFC2858
RFC2859 A Time Sliding Window Three Colour Marker (TSWTCM) W. Fang N. Seddigh B. Nandy June 2000 ASCII 19203 9 TSWTCM packets traffic stream routers

This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner. This memo defines an Experimental Protocol for the Internet community.

draft-fang-diffserv-tc-tswtcm-01 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2859
RFC2860 Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority B. Carpenter F. Baker M. Roberts June 2000 ASCII 12361 7 mou iana ietf icann engineering task force corporation names

This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community.

draft-iab-iana-mou-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2860
RFC2861 TCP Congestion Window Validation M. Handley J. Padhye S. Floyd June 2000 ASCII 26993 11 transmission control protocol

This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. This memo defines an Experimental Protocol for the Internet community.

draft-handley-tcp-cwv-02 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2861 10.17487/RFC2861
RFC2862 RTP Payload Format for Real-Time Pointers M. Civanlar G. Cash June 2000 ASCII 12031 7 view graphs resolution audio video signals

This document describes an RTP payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. [STANDARDS-TRACK]

draft-ietf-avt-pointer-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2862
RFC2863 The Interfaces Group MIB K. McCloghrie F. Kastenholz June 2000 ASCII 155014 69 INTERGRMIB Management Information Base Network

This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS-TRACK]

draft-ietf-ifmib-ifmib2-03 RFC2233 DRAFT STANDARD DRAFT STANDARD IETF int ifmib 10.17487/RFC2863
RFC2864 The Inverted Stack Table Extension to the Interfaces Group MIB K. McCloghrie G. Hanson June 2000 ASCII 21445 11 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS-TRACK]

draft-ietf-ifmib-invstackmib-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2864
RFC2865 Remote Authentication Dial In User Service (RADIUS) C. Rigney S. Willens A. Rubens W. Simpson June 2000 ASCII 146456 76 RADIUS encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

draft-ietf-radius-radius-v2-06 RFC2138 RFC2868 RFC3575 RFC5080 RFC6929 DRAFT STANDARD DRAFT STANDARD IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2865 10.17487/RFC2865
RFC2866 RADIUS Accounting C. Rigney June 2000 ASCII 51135 28 RADIUS-ACC remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community.

draft-ietf-radius-accounting-v2-05 RFC2139 RFC2867 RFC5080 RFC5997 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2866 10.17487/RFC2866
RFC2867 RADIUS Accounting Modifications for Tunnel Protocol Support G. Zorn B. Aboba D. Mitton June 2000 ASCII 51135 11 RADIUS] encryption NAS Network Access Server

This document defines new RADIUS (Remote Authentication Dial In User Service) accounting Attributes and new values for the existing Acct- Status-Type Attribute designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.

draft-ietf-radius-tunnel-acct-05 RFC2866 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2867 10.17487/RFC2867
RFC2868 RADIUS Attributes for Tunnel Protocol Support G. Zorn D. Leifer A. Rubens J. Shriver M. Holdrege I. Goyret June 2000 ASCII 42609 20 RADIUS encryption NAS Network Access Server

This document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.

draft-ietf-radius-tunnel-auth-09 RFC2865 RFC3575 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2868 10.17487/RFC2868
RFC2869 RADIUS Extensions C. Rigney W. Willats P. Calhoun June 2000 ASCII 96854 47 RADIUS encryption NAS Network Access Server

This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community.

draft-ietf-radius-ext-07 RFC3579 RFC5080 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2869
RFC2870 Root Name Server Operational Requirements R. Bush D. Karrenberg M. Kosters R. Plzak June 2000 ASCII 21133 10 infrastructure domain names security

The primary focus of this document is to provide guidelines for operation of the root name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsop-root-opreq-05 RFC2010 BCP0040 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC2870
RFC2871 A Framework for Telephony Routing over IP J. Rosenberg H. Schulzrinne June 2000 ASCII 60664 25 internet protocol TRIP gateway

This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. This memo provides information for the Internet community.

draft-ietf-iptel-gwloc-framework-06 INFORMATIONAL INFORMATIONAL IETF rai iptel 10.17487/RFC2871
RFC2872 Application and Sub Application Identity Policy Element for Use with RSVP Y. Bernet R. Pabbati June 2000 ASCII 10933 6 resource reservation protocol

RSVP signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-appid-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2872
RFC2873 TCP Processing of the IPv4 Precedence Field X. Xiao A. Hannan V. Paxson E. Crabbe June 2000 ASCII 15565 8 transmission control protocol internet

This memo describes a conflict between TCP and DiffServ on the use of the three leftmost bits in the TOS octet of an IPv4 header. [STANDARDS-TRACK]

draft-xiao-tcp-prec-03 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2873 10.17487/RFC2873
RFC2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering M. Crawford C. Huitema July 2000 ASCII 44204 20 internet protocol domain name system

This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. [STANDARDS-TRACK]

draft-ietf-ipngwg-dns-lookups-08 RFC1886 RFC3152 RFC3226 RFC3363 RFC3364 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2874
RFC2875 Diffie-Hellman Proof-of-Possession Algorithms H. Prafullchandra J. Schaad July 2000 ASCII 45231 23 certificate security encryption

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. [STANDARDS-TRACK]

draft-ietf-pkix-dhpop-03 RFC6955 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2875
RFC2876 Use of the KEA and SKIPJACK Algorithms in CMS J. Pawling July 2000 ASCII 29265 13 encryption cryptographic message syntax

This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types. This memo provides information for the Internet community.

draft-ietf-smime-cmskea-05 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2876 10.17487/RFC2876
RFC2877 5250 Telnet Enhancements T. Murphy Jr. P. Rieth J. Stevens July 2000 ASCII 83369 36 client server printer

This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. This memo provides information for the Internet community.

draft-ietf-tn3270e-tn5250e-05 RFC4777 RFC1205 INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC2877
RFC2878 PPP Bridging Control Protocol (BCP) M. Higashiyama F. Baker July 2000 ASCII 79527 38 PPP-BCP point-to-point datagrams network

This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]

draft-ietf-pppext-bcp-04 RFC1638 RFC3518 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2878
RFC2879 Content Feature Schema for Internet Fax (V2) G. Klyne L. McIntyre August 2000 ASCII 104032 58 media features mechanism

This document defines a content media feature schema for Internet fax. [STANDARDS-TRACK]

draft-ietf-fax-feature-schema-v2-01 RFC2531 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2879
RFC2880 Internet Fax T.30 Feature Mapping L. McIntyre G. Klyne August 2000 ASCII 75973 37 schema media tags

This document describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in "Content feature schema for Internet fax". This memo provides information for the Internet community.

draft-ietf-fax-feature-T30-mapping-03 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2880
RFC2881 Network Access Server Requirements Next Generation (NASREQNG) NAS Model D. Mitton M. Beadles July 2000 ASCII 45029 20 RADIUS remote authentication dial-up user service

This document describes the terminology and gives a model of typical Network Access Server (NAS). This memo provides information for the Internet community.

draft-ietf-nasreq-nasmodel-02 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC2881
RFC2882 Network Access Servers Requirements: Extended RADIUS Practices D. Mitton July 2000 ASCII 31426 16 NAS remote authentication dial-in user service

This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS (Remote Authentication Dial In User Service) RFCs 2138, 2139. This memo provides information for the Internet community.

draft-ietf-nasreq-ext-radiuspract-03 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC2882
RFC2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP S. Floyd J. Mahdavi M. Mathis M. Podolsky July 2000 ASCII 35794 17 SACK transmission control protocol packets sender receiver

This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS-TRACK]

draft-floyd-sack-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2883 10.17487/RFC2883
RFC2884 Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks J. Hadi Salim U. Ahmed July 2000 ASCII 44647 18 internet protocol end-to-end TCP transmission control

This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. This memo provides information for the Internet community.

draft-hadi-jhsua-ecnperf-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2884
RFC2885 Megaco Protocol version 0.8 F. Cuervo N. Greene C. Huitema A. Rayhan B. Rosen J. Segers August 2000 ASCII 344871 170 H.248 media gateway control

This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. [STANDARDS-TRACK]

draft-ietf-megaco-protocol-08 RFC3015 HISTORIC PROPOSED STANDARD IETF rai megaco 10.17487/RFC2885
RFC2886 Megaco Errata T. Taylor August 2000 ASCII 41311 21 H.248 media gateway control

This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS-TRACK]

draft-ietf-megaco-errata-03 RFC3015 HISTORIC PROPOSED STANDARD IETF rai megaco 10.17487/RFC2886
RFC2887 The Reliable Multicast Design Space for Bulk Data Transfer M. Handley S. Floyd B. Whetten R. Kermode L. Vicisano M. Luby August 2000 ASCII 51135 22 application RM congestion control data

This document provides an overview of the design space and the ways in which application constraints affect possible solutions. This memo provides information for the Internet community.

draft-ietf-rmt-design-space-01 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC2887
RFC2888 Secure Remote Access with L2TP P. Srisuresh August 2000 ASCII 41255 19 layer two tunneling protocol

The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This memo provides information for the Internet community.

draft-srisuresh-secure-ra-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2888
RFC2889 Benchmarking Methodology for LAN Switching Devices R. Mandeville J. Perser August 2000 ASCII 73251 35 local area network MAC medium access control

This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community.

draft-ietf-bmwg-mswitch-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2889
RFC2890 Key and Sequence Number Extensions to GRE G. Dommety September 2000 ASCII 14503 7 generic routing encapsulation

This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]

draft-dommety-gre-ext-04 RFC2784 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2890
RFC2891 LDAP Control Extension for Server Side Sorting of Search Results T. Howes M. Wahl A. Anantha August 2000 ASCII 15833 8 lightweight directory access protocol

This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. [STANDARDS-TRACK]

draft-ietf-ldapext-sorting-03 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2891
RFC2892 The Cisco SRP MAC Layer Protocol D. Tsiang G. Suwala August 2000 ASCII 107645 52 spatial reuse

This document specifies the MAC layer protocol, "Spatial Reuse Protocol" (SRP) for use with ring based media. This is a second version of the protocol (V2). This memo provides information for the Internet community.

draft-tsiang-srp-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2892
RFC2893 Transition Mechanisms for IPv6 Hosts and Routers R. Gilligan E. Nordmark August 2000 ASCII 62731 29 TRANS-IPV6 IPv4

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]

draft-ietf-ngtrans-mech-06 RFC1933 RFC4213 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2893
RFC2894 Router Renumbering for IPv6 M. Crawford August 2000 ASCII 69135 32 internet protocol operations scalability applicability

This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. [STANDARDS-TRACK]

draft-ietf-ipngwg-router-renum-10 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2894
RFC2895 Remote Network Monitoring MIB Protocol Identifier Reference A. Bierman C. Bucci R. Iddon August 2000 ASCII 88094 42 RMON-MIB management information base

This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding ``INDEX`` values for the protocolDirTable, found in the RMON-2 MIB. [STANDARDS-TRACK]

draft-ietf-rmonmib-rmonprot-ref-01 RFC2074 RFC3395 DRAFT STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2895
RFC2896 Remote Network Monitoring MIB Protocol Identifier Macros A. Bierman C. Bucci R. Iddon August 2000 ASCII 135768 84 RMON management information base

This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB and the RMON Protocol Identifier Reference. This memo provides information for the Internet community.

draft-ietf-rmonmib-rmonprot-mac-02 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC2896
RFC2897 Proposal for an MGCP Advanced Audio Package D. Cromwell August 2000 ASCII 67459 34 media gateway control protocol IVR interactive voice response

This document is a proposal to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server. This memo provides information for the Internet community.

draft-cromwell-mgcp-advanced-audio-pkg-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2897
RFC2898 PKCS #5: Password-Based Cryptography Specification Version 2.0 B. Kaliski September 2000 ASCII 68692 34 public-key authentication encryption

This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.

draft-kaliski-pkcs5-v2-04 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2898 10.17487/RFC2898
RFC2899 Request for Comments Summary RFC Numbers 2800-2899 S. Ginoza May 2001 ASCII 43805 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2899 RFC2900 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza August 2001 ASCII 112809 42

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. This memo is an Internet Standard.

RFC2800 RFC3000 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2900
RFC2901 Guide to Administrative Procedures of the Internet Infrastructure Z. Wenzel J. Klensin R. Bush S. Huter August 2000 ASCII 63680 31 address space routing database domain name registration

This document describes the administrative procedures for networks seeking to connect to the global Internet. This memo provides information for the Internet community.

draft-wenzel-nsrc-02 FYI0037 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2901
RFC2902 Overview of the 1998 IAB Routing Workshop S. Deering S. Hares C. Perkins R. Perlman August 2000 ASCII 32773 16 internet architecture board

This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. This memo provides information for the Internet community.

draft-iab-rtrws-over-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2902
RFC2903 Generic AAA Architecture C. de Laat G. Gross L. Gommans J. Vollbrecht D. Spence August 2000 ASCII 60627 26 authentication authorization accounting

This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-aaaarch-generic-01 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2903
RFC2904 AAA Authorization Framework J. Vollbrecht P. Calhoun S. Farrell L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII 78098 35 authentication authorization accounting

This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. This memo provides information for the Internet community.

draft-irtf-aaaarch-authorization-framework-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2904
RFC2905 AAA Authorization Application Examples J. Vollbrecht P. Calhoun S. Farrell L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII 118645 53 authentication authorization accounting

This memo describes several examples of applications requiring authorization. This memo provides information for the Internet community.

draft-irtf-aaaarch-authorization-apps-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2905
RFC2906 AAA Authorization Requirements S. Farrell J. Vollbrecht P. Calhoun L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII 48618 23 authentication authorization accounting

This document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. This memo provides information for the Internet community.

draft-irtf-aaaarch-authorization-reqs-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2906
RFC2907 MADCAP Multicast Scope Nesting State Option R. Kermode September 2000 ASCII 27572 13 address dynamic allocation client protocol

This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. [STANDARDS-TRACK]

draft-ietf-malloc-madcap-nest-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC2907
RFC2908 The Internet Multicast Address Allocation Architecture D. Thaler M. Handley D. Estrin September 2000 ASCII 30515 13 MALLOC host server intra-domain inter-domain

This document proposes a multicast address allocation architecture (MALLOC) for the Internet. This memo provides information for the Internet community.

draft-ietf-malloc-arch-05 RFC6308 HISTORIC INFORMATIONAL IETF tsv malloc 10.17487/RFC2908
RFC2909 The Multicast Address-Set Claim (MASC) Protocol P. Radoslavov D. Estrin R. Govindan M. Handley S. Kumar D. Thaler September 2000 ASCII 127278 56 MASC inter-domain router

This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-malloc-masc-06 HISTORIC EXPERIMENTAL IETF tsv malloc 10.17487/RFC2909
RFC2910 Internet Printing Protocol/1.1: Encoding and Transport R. Herriot Editor S. Butler P. Moore R. Turner J. Wenn September 2000 ASCII 100599 46 IPP-E-T IPP application media-type media type

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]

draft-ietf-ipp-protocol-v11-06 RFC2565 RFC3380 RFC3381 RFC3382 RFC3510 RFC3995 RFC7472 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2910 10.17487/RFC2910
RFC2911 Internet Printing Protocol/1.1: Model and Semantics T. Hastings Editor R. Herriot R. deBry S. Isaacson P. Powell September 2000 ASCII 575805 224 IPP-M-S IPP application media-type job

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]

draft-ietf-ipp-model-v11-07 RFC2566 RFC3380 RFC3382 RFC3996 RFC3995 RFC7472 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2911 10.17487/RFC2911
RFC2912 Indicating Media Features for MIME Content G. Klyne September 2000 ASCII 20618 11 multipurpose mail extensions tag format

This memo defines a Multipurpose Internet Mail Extensions (MIME) ' Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. [STANDARDS-TRACK]

draft-ietf-conneg-content-features-03 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2912
RFC2913 MIME Content Types in Media Feature Expressions G. Klyne September 2000 ASCII 16095 9 multipurpose mail extensions tag format

This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. [STANDARDS-TRACK]

draft-ietf-conneg-feature-type-03 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2913
RFC2914 Congestion Control Principles S. Floyd September 2000 ASCII 43823 17 end-to-end

The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-floyd-cong-04 RFC7141 BCP0041 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ecm 10.17487/RFC2914
RFC2915 The Naming Authority Pointer (NAPTR) DNS Resource Record M. Mealling R. Daniel September 2000 ASCII 41521 18 NAPTR domain name system RR

This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). [STANDARDS-TRACK]

draft-ietf-urn-naptr-rr-04 RFC3401 RFC3402 RFC3403 RFC3404 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn 10.17487/RFC2915
RFC2916 E.164 number and DNS P. Faltstrom September 2000 ASCII 18159 10 domain name system

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. [STANDARDS-TRACK]

draft-ietf-enum-e164-dns-03 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=2916 10.17487/RFC2916
RFC2917 A Core MPLS IP VPN Architecture K. Muthukrishnan A. Malis September 2000 ASCII 35352 16 internet protocol virtual private networks multiprotocol label switching

This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This memo provides information for the Internet community.

draft-muthukrishnan-mpls-corevpn-arch-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2917
RFC2918 Route Refresh Capability for BGP-4 E. Chen September 2000 ASCII 7354 4 border gateway protocol

This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. [STANDARDS-TRACK]

draft-ietf-idr-bgp-route-refresh-01 RFC7313 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2918
RFC2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists R. Chandhok G. Wenger March 2001 ASCII 18480 9 server clients user agents

Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. [STANDARDS-TRACK]

draft-chandhok-listid-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2919 10.17487/RFC2919
RFC2920 SMTP Service Extension for Command Pipelining N. Freed September 2000 ASCII 17065 9 SMTP-Pipe simple mail transfer protocol TCP transmission control protocol

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS-TRACK]

draft-freed-smtp-pipe-01 RFC2197 STD0060 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2920
RFC2921 6BONE pTLA and pNLA Formats (pTLA) B. Fink September 2000 ASCII 14218 7 IPv6 internet protocol pseudo top-level next-level aggregation identifiers

This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation", to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). This memo provides information for the Internet community.

draft-ietf-ngtrans-6bone-ptla-00 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2921
RFC2922 Physical Topology MIB A. Bierman K. Jones September 2000 ASCII 66830 32 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. This memo provides information for the Internet community.

draft-ietf-ptopomib-mib-05 INFORMATIONAL INFORMATIONAL IETF ops ptopomib 10.17487/RFC2922
RFC2923 TCP Problems with Path MTU Discovery K. Lahey September 2000 ASCII 30976 15 transmission control protocol maximum unit

This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. This memo provides information for the Internet community.

draft-ietf-tcpimpl-pmtud-04 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2923
RFC2924 Accounting Attributes and Record Formats N. Brownlee A. Blount September 2000 ASCII 75561 36 data transport integrated

This document summarises Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) documents related to Accounting. This memo provides information for the Internet community.

draft-ietf-aaa-accounting-attributes-04 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2924
RFC2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations K. White September 2000 ASCII 150691 77 mib management information base

This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. [STANDARDS-TRACK]

draft-ietf-disman-remops-mib-08 RFC4560 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=2925 10.17487/RFC2925
RFC2926 Conversion of LDAP Schemas to and from SLP Templates J. Kempf R. Moats P. St. Pierre September 2000 ASCII 55365 27 service location protocol lightweight directory access

This document describes a procedure for mapping between Service Location Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. This memo provides information for the Internet community.

draft-ietf-svrloc-template-conversion-08 INFORMATIONAL INFORMATIONAL IETF int svrloc 10.17487/RFC2926
RFC2927 MIME Directory Profile for LDAP Schema M. Wahl September 2000 ASCII 16122 10 lightweight directory access protocol multipurpose internet mail extensions

This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol (LDAP) schema. This memo provides information for the Internet community.

draft-ietf-schema-ldap-01 INFORMATIONAL INFORMATIONAL IETF app schema http://www.rfc-editor.org/errata_search.php?rfc=2927 10.17487/RFC2927
RFC2928 Initial IPv6 Sub-TLA ID Assignments R. Hinden S. Deering R. Fink T. Hain September 2000 ASCII 11882 7 internet protocol sub-top-level aggregation identifiers address registries

This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. This memo provides information for the Internet community.

draft-ietf-ipngwg-iana-tla-03 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2928
RFC2929 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd E. Brunner-Williams B. Manning September 2000 ASCII 22454 12 internet assigned numbers authority resource records RRs

This document discusses the Internet Assigned Number Authority (IANA) parameter assignment considerations given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsext-iana-dns-01 RFC5395 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC2929
RFC2930 Secret Key Establishment for DNS (TKEY RR) D. Eastlake 3rd September 2000 ASCII 34894 16 TKEY-RR domain name system resource record transaction key

This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [STANDARDS-TRACK]

draft-ietf-dnsext-tkey-04 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2930
RFC2931 DNS Request and Transaction Signatures ( SIG(0)s ) D. Eastlake 3rd September 2000 ASCII 19073 10 domain name system data security

This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK]

draft-ietf-dnsext-sig-zero-02 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2931
RFC2932 IPv4 Multicast Routing MIB K. McCloghrie D. Farinacci D. Thaler October 2000 ASCII 50430 27 internet protocol management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. [STANDARDS-TRACK]

draft-ietf-idmr-multicast-routmib-13 RFC5132 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr 10.17487/RFC2932
RFC2933 Internet Group Management Protocol MIB K. McCloghrie D. Farinacci D. Thaler October 2000 ASCII 33406 19 igmp management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP). [STANDARDS-TRACK]

draft-ietf-idmr-igmp-mib-14 RFC5519 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr 10.17487/RFC2933
RFC2934 Protocol Independent Multicast MIB for IPv4 K. McCloghrie D. Farinacci D. Thaler B. Fenner October 2000 ASCII 48379 27 internet protocol management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-idmr-pim-mib-11 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC2934
RFC2935 Internet Open Trading Protocol (IOTP) HTTP Supplement D. Eastlake 3rd C. Smith September 2000 ASCII 16168 8 IOTP-HTTP hypertext XML extensible markup language transfer

The goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. [STANDARDS-TRACK]

draft-ietf-trade-iotp-http-07 PROPOSED STANDARD PROPOSED STANDARD IETF app trade 10.17487/RFC2935
RFC2936 HTTP MIME Type Handler Detection D. Eastlake 3rd C. Smith D. Soroka September 2000 ASCII 25238 13 multipurpose internet mail extensions hypertext transfer protocol

Entities composing web pages to provide services over the Hypertext Transfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on the Internet as of early 2000. This memo provides information for the Internet community.

draft-ietf-trade-mime-detector-03 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2936
RFC2937 The Name Service Search Option for DHCP C. Smith September 2000 ASCII 8368 5 dynamic host configuration protocol

This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. [STANDARDS-TRACK]

draft-ietf-dhc-nsso-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2937
RFC2938 Identifying Composite Media Features G. Klyne L. Masinter September 2000 ASCII 34451 18 tags expression hash

This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite. [STANDARDS-TRACK]

draft-ietf-conneg-feature-hash-05 RFC2533 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg http://www.rfc-editor.org/errata_search.php?rfc=2938 10.17487/RFC2938
RFC2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types R. Droms September 2000 ASCII 13631 7 dynamic host configuration protocol internet assigned numbers authority

This document describes the procedure for defining new DHCP options and message types. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dhc-new-opt-msg-02 RFC2489 BCP0043 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2939 10.17487/RFC2939
RFC2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients A. Smith D. Partain J. Seligson October 2000 ASCII 52427 27 cops mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client of the Common Open Policy Service (COPS) protocol. [STANDARDS-TRACK]

draft-ietf-rap-cops-client-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2940
RFC2941 Telnet Authentication Option T. Ts'o Editor J. Altman September 2000 ASCII 52427 15 TOPT-AUTH encryption Security

This document describes the authentication option to the telnet protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. [STANDARDS-TRACK]

draft-tso-telnet-auth-enc-05 RFC1416 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2941
RFC2942 Telnet Authentication: Kerberos Version 5 T. Ts'o September 2000 ASCII 14562 7 encryption

This document describes how Kerberos Version 5 is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option. [STANDARDS-TRACK]

draft-tso-telnet-krb5-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2942
RFC2943 TELNET Authentication Using DSA R. Housley T. Horting P. Yee September 2000 ASCII 21694 12 digital signature algorithm

This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA). It relies on the Telnet Authentication Option. [STANDARDS-TRACK]

draft-housley-telnet-auth-dsa-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2943
RFC2944 Telnet Authentication: SRP T. Wu September 2000 ASCII 13933 7 secure remote password protocol

This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 2941, using the Secure Remote Password Protocol (SRP) authentication mechanism. [STANDARDS-TRACK]

draft-wu-telnet-auth-srp-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2944
RFC2945 The SRP Authentication and Key Exchange System T. Wu September 2000 ASCII 17843 8 secure remote password protocol

This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK]

draft-wu-srp-auth-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2945
RFC2946 Telnet Data Encryption Option T. Ts'o September 2000 ASCII 16527 8 stream authentication

This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. [STANDARDS-TRACK]

draft-tso-telnet-encryption-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2946
RFC2947 Telnet Encryption: DES3 64 bit Cipher Feedback J. Altman September 2000 ASCII 11064 6 data encryption standard

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option. [STANDARDS-TRACK]

draft-altman-telnet-enc-des3-cfb-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2947
RFC2948 Telnet Encryption: DES3 64 bit Output Feedback J. Altman September 2000 ASCII 11064 6 data encryption standard

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option. [STANDARDS-TRACK]

draft-altman-telnet-enc-des3-ofb-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2948
RFC2949 Telnet Encryption: CAST-128 64 bit Output Feedback J. Altman September 2000 ASCII 9240 5 algorithm option

This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]

draft-altman-telnet-enc-cast128-ofb-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2949
RFC2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback J. Altman September 2000 ASCII 9267 5 algorithm option

This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]

draft-altman-telnet-enc-cast128-cfb-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2950
RFC2951 TELNET Authentication Using KEA and SKIPJACK R. Housley T. Horting P. Yee September 2000 ASCII 20757 11 key exchange algorithm encryption

This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. This memo provides information for the Internet community.

draft-housley-telnet-auth-keasj-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2951
RFC2952 Telnet Encryption: DES 64 bit Cipher Feedback T. Ts'o September 2000 ASCII 9064 5 data encryption standard

This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option. This memo provides information for the Internet community.

draft-tso-telnet-enc-des-cfb-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2952
RFC2953 Telnet Encryption: DES 64 bit Output Feedback T. Ts'o September 2000 ASCII 8995 5 data encryption standard

This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option. This memo provides information for the Internet community.

draft-tso-telnet-enc-des-ofb-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2953
RFC2954 Definitions of Managed Objects for Frame Relay Service K. Rehbehn D. Fowler October 2000 ASCII 164217 76 FR-MIB mib management information base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. [STANDARDS-TRACK]

draft-ietf-frnetmib-frs-mib-12 RFC1604 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC2954
RFC2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function K. Rehbehn O. Nicklass G. Mouradian October 2000 ASCII 83281 39 asynchronous transfer mode permanent virtual connections MIB management information base

This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. [STANDARDS-TRACK]

draft-ietf-frnetmib-atmiwf-06 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC2955
RFC2956 Overview of 1999 IAB Network Layer Workshop M. Kaat October 2000 ASCII 36830 16 intenret architecture board

This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. This memo provides information for the Internet community.

draft-iab-ntwlyrws-over-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2956
RFC2957 The application/whoispp-query Content-Type L. Daigle P. Faltstrom October 2000 ASCII 10262 6 mime multipurpose internet mail extensions media-types

The intention of this document, in conjunction with RFC 2958, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.

draft-daigle-wppquery-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2957
RFC2958 The application/whoispp-response Content-type L. Daigle P. Faltstrom October 2000 ASCII 9995 6 mime multipurpose internet mail extensions media-types

The intention of this document, in conjunction with RFC 2957, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.

draft-daigle-wppresp-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2958
RFC2959 Real-Time Transport Protocol Management Information Base M. Baugher B. Strahm I. Suconick October 2000 ASCII 62063 31 RTP MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2959
RFC2960 Stream Control Transmission Protocol R. Stewart Q. Xie K. Morneault C. Sharp H. Schwarzbauer T. Taylor I. Rytina M. Kalla L. Zhang V. Paxson October 2000 ASCII 297757 134 SCTP IP internet transport packet network

This document describes the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]

draft-ietf-sigtran-sctp-13 RFC4960 RFC3309 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=2960 10.17487/RFC2960
RFC2961 RSVP Refresh Overhead Reduction Extensions L. Berger D. Gan G. Swallow P. Pan F. Tommasi S. Molendini April 2001 ASCII 81675 34 resource reservation protocol messages

This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. [STANDARDS-TRACK]

draft-ietf-rsvp-refresh-reduct-05 RFC5063 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2961
RFC2962 An SNMP Application Level Gateway for Payload Address Translation D. Raz J. Schoenwaelder B. Sugla October 2000 ASCII 46803 20 simple network management protocol

This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another. This memo provides information for the Internet community.

draft-ietf-nat-snmp-alg-05 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC2962
RFC2963 A Rate Adaptive Shaper for Differentiated Services O. Bonaventure S. De Cnodder October 2000 ASCII 39895 19 RAS TCP transmission control protocol diffserv

This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 and RFC2698, respectively. This memo provides information for the Internet community.

draft-bonaventure-diffserv-rashaper-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2963
RFC2964 Use of HTTP State Management K. Moore N. Freed October 2000 ASCII 18899 8 hypertext transfer protocol

This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iesg-http-cookies-03 BCP0044 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2964
RFC2965 HTTP State Management Mechanism D. Kristol L. Montulli October 2000 ASCII 56176 26 hypertext transfer protocol

This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. [STANDARDS-TRACK]

draft-ietf-http-state-man-mec-12 RFC2109 RFC6265 HISTORIC PROPOSED STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2965 10.17487/RFC2965
RFC2966 Domain-wide Prefix Distribution with Two-Level IS-IS T. Li T. Przygienda H. Smit October 2000 ASCII 32465 14 intermediate system routers loops IP internet protocol

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. This memo provides information for the Internet community.

draft-ietf-isis-domain-wide-03 RFC5302 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC2966
RFC2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways L. Daigle R. Hedberg October 2000 ASCII 209845 105 single point service

The overarching goal of this project is to develop the necessary technical infrastructure to provide a single-access-point service for searching for whitepages information on Swedish Internet users. This memo provides information for the Internet community.

draft-daigle-tisdag-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2967
RFC2968 Mesh of Multiple DAG servers - Results from TISDAG L. Daigle T. Eklof October 2000 ASCII 19306 9 technical infrastructure swedish directory access gateways mesh index

This document defines the basic principle for establishing a mesh, that interoperating services should exchange index objects, according to the architecture of the mesh (e.g., hierarchical, or graph-like, preferably without loops!). The Common Indexing Protocol (CIP) is designed to facilitate the creation not only of query referral indexes, but also of meshes of (loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services. This memo provides information for the Internet community.

draft-daigle-dag-mesh-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2968
RFC2969 Wide Area Directory Deployment - Experiences from TISDAG T. Eklof L. Daigle October 2000 ASCII 43002 19 technical infrastructure swedish access gateways

This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. This memo provides information for the Internet community.

draft-eklof-dag-experiences-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2969
RFC2970 Architecture for Integrated Directory Services - Result from TISDAG L. Daigle T. Eklof October 2000 ASCII 40448 18 ids whitepages technical infrastructure swedish access gateways

Drawing from experiences with the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use. This memo provides information for the Internet community.

draft-daigle-arch-ids-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2970
RFC2971 IMAP4 ID extension T. Showalter October 2000 ASCII 14670 8 internet message access protocol client server

This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service. The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. [STANDARDS-TRACK]

draft-showalter-imap-id-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2971
RFC2972 Context and Goals for Common Name Resolution N. Popp M. Mealling L. Masinter K. Sollins October 2000 ASCII 26252 11 CNRP

This document establishes the context and goals for a Common Name Resolution Protocol. This memo provides information for the Internet community.

draft-ietf-cnrp-goals-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2972
RFC2973 IS-IS Mesh Groups R. Balay D. Katz J. Parker October 2000 ASCII 14846 8 intermediate system PDU protocol data unit

This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This memo provides information for the Internet community.

draft-ietf-isis-wg-mesh-group-01 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC2973
RFC2974 Session Announcement Protocol M. Handley C. Perkins E. Whelan October 2000 ASCII 40129 18 SAP

This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mmusic-sap-v2-06 EXPERIMENTAL EXPERIMENTAL IETF rai mmusic 10.17487/RFC2974
RFC2975 Introduction to Accounting Management B. Aboba J. Arkko D. Harrington October 2000 ASCII 129771 54 resource consumption data cost allocation

This document describes and discusses the issues involved in the design of the modern accounting systems. The field of Accounting Management is concerned with the collection the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This memo provides information for the Internet community.

draft-ietf-aaa-acct-06 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2975
RFC2976 The SIP INFO Method S. Donovan October 2000 ASCII 17736 9 session initiation protocol information extension

This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. [STANDARDS-TRACK]

draft-ietf-sip-info-method-05 RFC6086 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC2976
RFC2977 Mobile IP Authentication, Authorization, and Accounting Requirements S. Glass T. Hiller S. Jacobs C. Perkins October 2000 ASCII 63520 27 AAA internet protocol

This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. This memo provides information for the Internet community.

draft-ietf-mobileip-aaa-reqs-04 INFORMATIONAL INFORMATIONAL IETF int mobileip 10.17487/RFC2977
RFC2978 IANA Charset Registration Procedures N. Freed J. Postel October 2000 ASCII 21615 11 character set mime multipurpose internet mail extensions

Multipurpose Internet Mail Extensions (MIME) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-freed-charset-regist-03 RFC2278 BCP0019 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=2978 10.17487/RFC2978
RFC2979 Behavior of and Requirements for Internet Firewalls N. Freed October 2000 ASCII 14350 7 security intranet network

This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. This memo provides information for the Internet community.

draft-iab-firewall-req-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2979
RFC2980 Common NNTP Extensions S. Barber October 2000 ASCII 57165 27 network news transfer protocol

In this document, a number of popular extensions to the Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. This memo provides information for the Internet community.

draft-ietf-nntpext-imp-04 RFC3977 RFC4643 RFC4644 RFC6048 INFORMATIONAL INFORMATIONAL IETF app nntpext 10.17487/RFC2980
RFC2981 Event MIB R. Kavasseri Editor October 2000 ASCII 98248 50 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. [STANDARDS-TRACK]

draft-ietf-disman-event-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=2981 10.17487/RFC2981
RFC2982 Distributed Management Expression MIB R. Kavasseri Editor October 2000 ASCII 81371 41 information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. [STANDARDS-TRACK]

draft-ietf-disman-express-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2982
RFC2983 Differentiated Services and Tunnels D. Black October 2000 ASCII 35644 14 internet protocol encapsulation

This document considers the interaction of Differentiated Services (diffserv) with IP tunnels of various forms. This memo provides information for the Internet community.

draft-ietf-diffserv-tunnels-02 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC2983
RFC2984 Use of the CAST-128 Encryption Algorithm in CMS C. Adams October 2000 ASCII 11591 6 cryptographic message syntax security cipher

This document specifies how to incorporate CAST-128 into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. [STANDARDS-TRACK]

draft-ietf-smime-cast-128-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2984
RFC2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0 M. Nystrom B. Kaliski November 2000 ASCII 70703 42 public-key cryptography standards LDAP lightweight directory access protocol

This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community.

draft-nystrom-pkcs9-v2-01 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2985 10.17487/RFC2985
RFC2986 PKCS #10: Certification Request Syntax Specification Version 1.7 M. Nystrom B. Kaliski November 2000 ASCII 27794 14 public-key cryptography standards PKCS-10 public key distinguished name encryption data

This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.

draft-nystrom-pkcs10-v1-7-00 RFC2314 RFC5967 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2986
RFC2987 Registration of Charset and Languages Media Features Tags P. Hoffman November 2000 ASCII 8799 6 character sets human languages devices

This document contains the registration for two media feature tags: "charset" and "language". [STANDARDS-TRACK]

draft-hoffman-char-lang-media-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2987
RFC2988 Computing TCP's Retransmission Timer V. Paxson M. Allman November 2000 ASCII 15280 8 transmission control protocol algorithm

This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. [STANDARDS-TRACK]

draft-paxson-tcp-rto-01 RFC6298 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2988 10.17487/RFC2988
RFC2989 Criteria for Evaluating AAA Protocols for Network Access B. Aboba P. Calhoun S. Glass T. Hiller P. McCann H. Shiino P. Walsh G. Zorn G. Dommety C. Perkins B. Patil D. Mitton S. Manning M. Beadles X. Chen S. Sivalingham A. Hameed M. Munson S. Jacobs B. Lim B. Hirschman R. Hsu H. Koo M. Lipford E. Campbell Y. Xu S. Baba E. Jaques November 2000 ASCII 53197 28 authentication authorization accounting

This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access. This memo provides information for the Internet community.

draft-ietf-aaa-na-reqts-07 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2989
RFC2990 Next Steps for the IP QoS Architecture G. Huston November 2000 ASCII 65450 24 internet protocol quality of service end-to-end

This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board. This memo provides information for the Internet community.

draft-iab-qos-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2990
RFC2991 Multipath Issues in Unicast and Multicast Next-Hop Selection D. Thaler C. Hopps November 2000 ASCII 17796 9 routing forwarding packets ECMP

The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions. This memo provides information for the Internet community.

draft-thaler-multipath-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2991
RFC2992 Analysis of an Equal-Cost Multi-Path Algorithm C. Hopps November 2000 ASCII 17524 8 ECMP routing packets forwarding

Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. This memo provides information for the Internet community.

draft-hopps-ecmp-algo-analysis-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2992
RFC2993 Architectural Implications of NAT T. Hain November 2000 ASCII 74136 29 network address translation

This document discusses some of the architectural implications and guidelines for implementations of Network Address Translation (NAT). This memo provides information for the Internet community.

draft-iab-nat-implications-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2993
RFC2994 A Description of the MISTY1 Encryption Algorithm H. Ohta M. Matsui November 2000 ASCII 17803 10 cryptosystem security data stream

This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part. This memo provides information for the Internet community.

draft-ohta-misty1desc-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2994
RFC2995 Pre-Spirits Implementations of PSTN-initiated Services H. Lu Editor I. Faynberg J. Voelker M. Weissman W. Zhang S. Rhim J. Hwang S. Ago S. Moeenuddin S. Hadvani S. Nyckelgard J. Yoakum L. Robart November 2000 ASCII 96427 44 public switched telephone network

This document describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN. This memo provides information for the Internet community.

draft-ietf-spirits-implementations-02 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC2995
RFC2996 Format of the RSVP DCLASS Object Y. Bernet November 2000 ASCII 18929 9 resource reservation protocol QoS Quality of Service

This document specifies the format of the DCLASS object and briefly discusses its use. [STANDARDS-TRACK]

draft-ietf-issll-dclass-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2996
RFC2997 Specification of the Null Service Type Y. Bernet A. Smith B. Davie November 2000 ASCII 25071 12 resource reservation protocol QoS Quality of Service

The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. [STANDARDS-TRACK]

draft-ietf-issll-nullservice-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2997
RFC2998 A Framework for Integrated Services Operation over Diffserv Networks Y. Bernet P. Ford R. Yavatkar F. Baker L. Zhang M. Speer R. Braden B. Davie J. Wroclawski E. Felstaine November 2000 ASCII 76378 31 intserv QoS Quality of Service end-to-end

This document describes a framework by which Integrated Services may be supported over Diffserv networks. This memo provides information for the Internet community.

draft-ietf-issll-diffserv-rsvp-05 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2998
RFC2999 Request for Comments Summary RFC Numbers 2900-2999 S. Ginoza August 2001 ASCII 45307 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2999 RFC3000 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza L. Shiota November 2001 ASCII 115207 43

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]

RFC2900 RFC3300 HISTORIC INTERNET STANDARD INDEPENDENT 10.17487/RFC3000
RFC3001 A URN Namespace of Object Identifiers M. Mealling November 2000 ASCII 7459 5 uniform resource names OIDs

This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.

draft-mealling-oid-urn-01 RFC3061 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3001
RFC3002 Overview of 2000 IAB Wireless Internetworking Workshop D. Mitzel December 2000 ASCII 101466 42 internet architecture board

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. This memo provides information for the Internet community.

draft-iab-wirelessws-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3002
RFC3003 The audio/mpeg Media Type M. Nilsson November 2000 ASCII 8381 5 MIME multipurpose internet mail extensions

The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose Internet Mail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents. [STANDARDS-TRACK]

draft-nilsson-audio-mpeg-03 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3003 10.17487/RFC3003
RFC3004 The User Class Option for DHCP G. Stump R. Droms Y. Gu R. Vyaghrapuri A. Demirtjis B. Beser J. Privat November 2000 ASCII 10423 6 dynamic host configuration protocol

This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. [STANDARDS-TRACK]

draft-ietf-dhc-userclass-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3004
RFC3005 IETF Discussion List Charter S. Harris November 2000 ASCII 5682 3 internet engineering task force

The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed. Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-poisson-listaup-02 BCP0045 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC3005
RFC3006 Integrated Services in the Presence of Compressible Flows B. Davie C. Iturralde D. Oran S. Casner J. Wroclawski November 2000 ASCII 31588 13 routing resource allocation int-serv

This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. [STANDARDS-TRACK]

draft-ietf-intserv-compress-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC3006
RFC3007 Secure Domain Name System (DNS) Dynamic Update B. Wellington November 2000 ASCII 18056 9 security authentication validation DNSSEC

This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK]

draft-ietf-dnsext-simple-secure-update-02 RFC2137 RFC2535 RFC2136 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3007
RFC3008 Domain Name System Security (DNSSEC) Signing Authority B. Wellington November 2000 ASCII 13484 7 DNSSEC authentication validation SIG signature

This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. [STANDARDS-TRACK]

draft-ietf-dnsext-signing-auth-02 RFC4035 RFC4033 RFC4034 RFC2535 RFC3658 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3008
RFC3009 Registration of parityfec MIME types J. Rosenberg H. Schulzrinne November 2000 ASCII 16022 10 media-type multimedia internet mail extensions

The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes. This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. [STANDARDS-TRACK]

draft-ietf-avt-fecmime-01 RFC5109 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3009
RFC3010 NFS version 4 Protocol S. Shepler B. Callaghan D. Robinson R. Thurlow C. Beame M. Eisler D. Noveck December 2000 ASCII 450434 212 NFSv4 network file system

NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [STANDARDS-TRACK]

draft-ietf-nfsv4-07 RFC3530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=3010 10.17487/RFC3010
RFC3011 The IPv4 Subnet Selection Option for DHCP G. Waters November 2000 ASCII 13967 7 internet protocol dynamic host configuration

This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address. [STANDARDS-TRACK]

draft-ietf-dhc-subnet-option-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3011
RFC3012 Mobile IPv4 Challenge/Response Extensions C. Perkins P. Calhoun November 2000 ASCII 37005 17 internet protocol authentication foreign agent

In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. [STANDARDS-TRACK]

draft-ietf-mobileip-challenge-13 RFC4721 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3012
RFC3013 Recommended Internet Service Provider Security Services and Procedures T. Killalea November 2000 ASCII 27905 13 ISPs

The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grip-isp-expectations-06 BCP0046 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip 10.17487/RFC3013
RFC3014 Notification Log MIB R. Kavasseri November 2000 ASCII 48287 26 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. [STANDARDS-TRACK]

draft-ietf-disman-notif-log-mib-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3014
RFC3015 Megaco Protocol Version 1.0 F. Cuervo N. Greene A. Rayhan C. Huitema B. Rosen J. Segers November 2000 ASCII 385432 179 MEGACO H.248 media gateway control

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and a Media Gateway Controller. [STANDARDS-TRACK]

draft-ietf-megaco-merged-01 RFC2885 RFC2886 RFC3525 PROPOSED STANDARD PROPOSED STANDARD IETF rai megaco http://www.rfc-editor.org/errata_search.php?rfc=3015 10.17487/RFC3015
RFC3016 RTP Payload Format for MPEG-4 Audio/Visual Streams Y. Kikuchi T. Nomura S. Fukunaga Y. Matsui H. Kimata November 2000 ASCII 47070 21 real-time transport protocol media-type

This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mpeg4-es-05 RFC6416 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3016
RFC3017 XML DTD for Roaming Access Phone Book M. Riegel G. Zorn December 2000 ASCII 59762 33 extensible markup language document type declaration

This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. [STANDARDS-TRACK]

draft-ietf-roamops-phonebook-xml-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops roamops 10.17487/RFC3017
RFC3018 Unified Memory Space Protocol Specification A. Bogdanov December 2000 ASCII 177783 81 UMSP network connection-oriented

This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. This memo defines an Experimental Protocol for the Internet community.

draft-bogdanov-umsp-00 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3018
RFC3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol B. Haberman R. Worzella January 2001 ASCII 28293 15 IPv6 MIB MLD

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [STANDARDS-TRACK]

draft-ietf-ipngwg-mld-mib-05 RFC5519 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC3019
RFC3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function P. Pate B. Lynch K. Rehbehn December 2000 ASCII 67736 36 MIB management information base

This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. [STANDARDS-TRACK]

draft-ietf-frnetmib-mfrmib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3020
RFC3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links A. Retana R. White V. Fuller D. McPherson December 2000 ASCII 19771 10 internet protocol addresses subnet masks

With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. [STANDARDS-TRACK]

draft-retana-31bits-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3021
RFC3022 Traditional IP Network Address Translator (Traditional NAT) P. Srisuresh K. Egevang January 2001 ASCII 37675 16 internet protocol ports private

The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail. This memo provides information for the Internet community.

draft-ietf-nat-traditional-05 RFC1631 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=3022 10.17487/RFC3022
RFC3023 XML Media Types M. Murata S. St. Laurent D. Kohn January 2001 ASCII 86011 39 extensible markup language web authority hypertext transfer protocol

This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS-TRACK]

draft-murata-xml-09 RFC2376 RFC7303 RFC2048 RFC6839 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3023 10.17487/RFC3023
RFC3024 Reverse Tunneling for Mobile IP, revised G. Montenegro Editor January 2001 ASCII 63929 30 internet protocol node care-of-address

This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. [STANDARDS-TRACK]

draft-ietf-mobileip-rfc2344-bis-02 RFC2344 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3024 10.17487/RFC3024
RFC3025 Mobile IP Vendor/Organization-Specific Extensions G. Dommety K. Leung February 2001 ASCII 15611 8 internet protocol

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]

draft-ietf-mobileip-vendor-ext-11 RFC3115 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3025
RFC3026 Liaison to IETF/ISOC on ENUM R. Blane January 2001 ASCII 11460 6 dns domain name system internet security engineering task force E.164 number

Working Party 1/2, of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions. This memo provides information for the Internet community.

draft-itu-sg2-liason-enum-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3026
RFC3027 Protocol Complications with the IP Network Address Translator M. Holdrege P. Srisuresh January 2001 ASCII 48662 20 IP internet protocol network address translator

The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. This memo provides information for the Internet community.

draft-ietf-nat-protocol-complications-06 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC3027
RFC3028 Sieve: A Mail Filtering Language T. Showalter January 2001 ASCII 73582 36 client server

This document describes a language for filtering e-mail messages at time of final delivery. [STANDARDS-TRACK]

draft-showalter-sieve-12 RFC5228 RFC5429 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3028 10.17487/RFC3028
RFC3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols C. Adams P. Sylvester M. Zolotarev R. Zuccherato February 2001 ASCII 107347 51 DVCS TTP trusted third party

This document describes a general Data Validation and Certification Server (DVCS) and the protocols to be used when communicating with it. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pkix-dcs-07 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC3029
RFC3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages G. Vaudreuil December 2000 ASCII 23405 12 simple mail transfer protocol multipurpose interent

This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK]

draft-vaudreuil-esmtp-binary2-03 RFC1830 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3030 10.17487/RFC3030
RFC3031 Multiprotocol Label Switching Architecture E. Rosen A. Viswanathan R. Callon January 2001 ASCII 147175 61 MPLS

This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]

draft-ietf-mpls-arch-06 RFC6178 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3031 10.17487/RFC3031
RFC3032 MPLS Label Stack Encoding E. Rosen D. Tappan G. Fedorkow Y. Rekhter D. Farinacci T. Li A. Conta January 2001 ASCII 48314 23 multi-protocol label switching

This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]

draft-ietf-mpls-label-encaps-07 RFC3443 RFC4182 RFC5332 RFC3270 RFC5129 RFC5462 RFC5586 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3032 10.17487/RFC3032
RFC3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol M. Suzuki January 2001 ASCII 52188 25 IP

The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. [STANDARDS-TRACK]

draft-ietf-mpls-git-uus-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3033
RFC3034 Use of Label Switching on Frame Relay Networks Specification A. Conta P. Doolan A. Malis January 2001 ASCII 53176 24 MPLS multi-protocol

This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. [STANDARDS-TRACK]

draft-ietf-mpls-fr-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3034
RFC3035 MPLS using LDP and ATM VC Switching B. Davie J. Lawrence K. McCloghrie E. Rosen G. Swallow Y. Rekhter P. Doolan January 2001 ASCII 46463 20 multi-protocol label switching asynchronous transfer mode distribution protocol

This document extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. [STANDARDS-TRACK]

draft-ietf-mpls-atm-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3035
RFC3036 LDP Specification L. Andersson P. Doolan N. Feldman A. Fredette B. Thomas January 2001 ASCII 274855 132 label distribution protocol

A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-11 RFC5036 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3036 10.17487/RFC3036
RFC3037 LDP Applicability B. Thomas E. Gray January 2001 ASCII 13601 7 label distribution protocol

A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-applic-02 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3037 10.17487/RFC3037
RFC3038 VCID Notification over ATM link for LDP K. Nagami Y. Katsube N. Demizu H. Esaki P. Doolan January 2001 ASCII 39134 19 asynchronous transfer mode label distribution protocol

This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. [STANDARDS-TRACK]

draft-ietf-mpls-vcid-atm-05 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3038
RFC3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile S. Santesson W. Polk P. Barzin M. Nystrom January 2001 ASCII 67619 35 syntax

This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The goal of this document is to define a general syntax independent of local legal requirements. [STANDARDS-TRACK]

draft-ietf-pkix-qc-06 RFC3739 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC3039
RFC3040 Internet Web Replication and Caching Taxonomy I. Cooper I. Melve G. Tomlinson January 2001 ASCII 63257 32 infrastructure www world wide

This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. This memo provides information for the Internet community.

draft-ietf-wrec-taxonomy-06 INFORMATIONAL INFORMATIONAL IETF app wrec 10.17487/RFC3040
RFC3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 T. Narten R. Draves January 2001 ASCII 44446 17 internet protocol interface identifier

This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS-TRACK]

draft-ietf-ipngwg-addrconf-privacy-04 RFC4941 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=3041 10.17487/RFC3041
RFC3042 Enhancing TCP's Loss Recovery Using Limited Transmit M. Allman H. Balakrishnan S. Floyd January 2001 ASCII 19885 9 transmission control protocol

This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. [STANDARDS-TRACK]

draft-ietf-tsvwg-limited-xmit-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3042
RFC3043 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations M. Mealling January 2001 ASCII 8136 5 uniform resource name

This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. This memo provides information for the Internet community.

draft-mealling-pin-urn-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3043
RFC3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace S. Rozenfeld January 2001 ASCII 28094 15 serials identifier

This document presents how the ISSN - International Standard Serial Number - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier. This memo provides information for the Internet community.

draft-rozenfeld-urn-issn-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3044
RFC3045 Storing Vendor Information in the LDAP root DSE M. Meredith January 2001 ASCII 10518 6 lightweight directory access protocol DSA-specific entry

This document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. This memo provides information for the Internet community.

draft-mmeredith-rootdse-vendor-info-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3045
RFC3046 DHCP Relay Agent Information Option M. Patrick January 2001 ASCII 30633 14 dynamic host configuration protocol

Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK]

draft-ietf-dhc-agent-options-12 RFC6607 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3046
RFC3047 RTP Payload Format for ITU-T Recommendation G.722.1 P. Luthi January 2001 ASCII 16292 8 international telecommunication union real-time transport protocol

This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use of G.722.1 with MIME and SDP. [STANDARDS-TRACK]

draft-ietf-avt-rtp-g7221-01 RFC5577 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3047 10.17487/RFC3047
RFC3048 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer B. Whetten L. Vicisano R. Kermode M. Handley S. Floyd M. Luby January 2001 ASCII 48965 20 RMT protocol core

This document describes a framework for the standardization of bulk-data reliable multicast transport. This memo provides information for the Internet community.

draft-ietf-rmt-buildingblocks-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3048
RFC3049 TN3270E Service Location and Session Balancing J. Naugle K. Kasthurirangan G. Ledford January 2001 ASCII 40743 21 SLP

This document discusses the implementation of Service Location Protocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server. [STANDARDS-TRACK]

draft-ietf-tn3270e-service-loc-06 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC3049
RFC3050 Common Gateway Interface for SIP J. Lennox H. Schulzrinne J. Rosenberg January 2001 ASCII 76652 35 session initiation protocol

This document defines a SIP CGI interface for providing SIP services on a SIP server. This memo provides information for the Internet community.

draft-lennox-sip-cgi-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3050
RFC3051 IP Payload Compression Using ITU-T V.44 Packet Method J. Heath J. Border January 2001 ASCII 15845 8 internet protocol international telecommunication union

This document describes a compression method based on the data compression algorithm described in International Telecommunication Union (ITU-T) Recommendation V.44. This document defines the application of V.44 Packet Method to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393). This memo provides information for the Internet community.

draft-heath-ipcomp-v44-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3051
RFC3052 Service Management Architectures Issues and Review M. Eder S. Nag January 2001 ASCII 31859 12 framework packets network

The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved. This memo provides information for the Internet community.

draft-irtf-nsmrg-sm-issues-00 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3052 10.17487/RFC3052
RFC3053 IPv6 Tunnel Broker A. Durand P. Fasano I. Guardini D. Lento January 2001 ASCII 27336 13 internet protocol infrastructure

The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting in February 1999. This memo provides information for the Internet community.

draft-ietf-ngtrans-broker-06 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3053
RFC3054 Megaco IP Phone Media Gateway Application Profile P. Blatherwick R. Bell P. Holland January 2001 ASCII 31971 14 internet protocol H.248 telephone MG

This document specifies a particular application of the Megaco/H.248 Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. This memo provides information for the Internet community.

draft-ietf-megaco-ipphone-03 INFORMATIONAL INFORMATIONAL IETF rai megaco 10.17487/RFC3054
RFC3055 Management Information Base for the PINT Services Architecture M. Krishnaswamy D. Romascanu February 2001 ASCII 39315 21 MIB PSTN/Internet interworking

This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. [STANDARDS-TRACK]

draft-ietf-pint-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pint 10.17487/RFC3055
RFC3056 Connection of IPv6 Domains via IPv4 Clouds B. Carpenter K. Moore February 2001 ASCII 54902 23 internet protocol wide area network unicast point-to-point

This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK]

draft-ietf-ngtrans-6to4-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans http://www.rfc-editor.org/errata_search.php?rfc=3056 10.17487/RFC3056
RFC3057 ISDN Q.921-User Adaptation Layer K. Morneault S. Rengasami M. Kalla G. Sidebottom February 2001 ASCII 13601 66 SCTP signaling media gateway interface

This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). [STANDARDS-TRACK]

draft-ietf-sigtran-iua-10 RFC4233 RFC3807 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3057
RFC3058 Use of the IDEA Encryption Algorithm in CMS S. Teiwes P. Hartmann D. Kuenzi February 2001 ASCII 17257 8 international data encryption algorithm cryptic message syntax s/mime multipurpose internet mail extensions

This memo specifies how to incorporate International Data Encryption Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. This memo provides information for the Internet community.

draft-ietf-smime-idea-08 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3058
RFC3059 Attribute List Extension for the Service Location Protocol E. Guttman February 2001 ASCII 11208 6 SLPv2 messages user agent

This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information. [STANDARDS-TRACK]

draft-guttman-svrloc-attrlist-ext-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3059
RFC3060 Policy Core Information Model -- Version 1 Specification B. Moore E. Ellesson J. Strassner A. Westerinen February 2001 ASCII 240309 100 CIM common schema object-oriented

This document presents the object-oriented information model for representing policy information developed jointly in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). [STANDARDS-TRACK]

draft-ietf-policy-core-info-model-08 RFC3460 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3060
RFC3061 A URN Namespace of Object Identifiers M. Mealling February 2001 ASCII 8387 6 uniform resource names OIDs

This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.

draft-mealling-rfc3001bis-01 RFC3001 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3061 10.17487/RFC3061
RFC3062 LDAP Password Modify Extended Operation K. Zeilenga February 2001 ASCII 11807 6 lightweight directory access protocol

This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. [STANDARDS-TRACK]

draft-zeilenga-ldap-passwd-exop-05 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3062 10.17487/RFC3062
RFC3063 MPLS Loop Prevention Mechanism Y. Ohba Y. Katsube E. Rosen P. Doolan February 2001 ASCII 93523 44 multiprotocol label switching path LSPs

This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mpls-loop-prevention-03 EXPERIMENTAL EXPERIMENTAL IETF rtg mpls 10.17487/RFC3063
RFC3064 MGCP CAS Packages B. Foster February 2001 ASCII 116818 56 media gateway controllers

This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. This memo provides information for the Internet community.

draft-foster-mgcp-cas-packages-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3064
RFC3065 Autonomous System Confederations for BGP P. Traina D. McPherson J. Scudder February 2001 ASCII 20529 11 BGP-ASC AS border gateway protocol

This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. [STANDARDS-TRACK]

draft-ietf-idr-bgp-confed-rfc1965bis-01 RFC1965 RFC5065 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=3065 10.17487/RFC3065
RFC3066 Tags for the Identification of Languages H. Alvestrand January 2001 ASCII 26522 13 Lang-Tag

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-alvestrand-lang-tag-v2-05 RFC1766 RFC4646 RFC4647 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=3066 10.17487/RFC3066
RFC3067 TERENA'S Incident Object Description and Exchange Format Requirements J. Arvidsson A. Cormack Y. Demchenko J. Meijer February 2001 ASCII 36836 17 IEDEF data archiving

The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (Computer Security Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements. This memo provides information for the Internet community.

draft-terena-itdwg-iodef-requirements-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3067
RFC3068 An Anycast Prefix for 6to4 Relay Routers C. Huitema June 2001 ASCII 20120 9 exterior gateway protocol interior IGP EGP

This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." [STANDARDS-TRACK]

draft-ietf-ngtrans-6to4anycast-03 RFC7526 HISTORIC PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC3068
RFC3069 VLAN Aggregation for Efficient IP Address Allocation D. McPherson B. Dykes February 2001 ASCII 14891 7 virtual local area network internet protocol

This document introduces the concept of Virtual Local Area Network (VLAN) aggregation as it relates to IPv4 address allocation. This memo provides information for the Internet community.

draft-mcpherson-vlan-ipagg-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3069 10.17487/RFC3069
RFC3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay V. Rawat R. Tio S. Nanji R. Verma February 2001 ASCII 12940 7 L2TP-FR point-to-point virtual switched circuits PVCs SVCs

This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). [STANDARDS-TRACK]

draft-ietf-l2tpext-fr-01 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3070
RFC3071 Reflections on the DNS, RFC 1591, and Categories of Domains J. Klensin February 2001 ASCII 24892 10 DNS Policy Top-Level TLD

This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how 1591 might have been interpreted and adjusted by the Internet Assigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. This memo provides information for the Internet community.

draft-klensin-1591-reflections-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3071
RFC3072 Structured Data Exchange Format (SDXF) M. Wildgrube March 2001 ASCII 48481 26 chunks file datatype

This specification describes an all-purpose interchange format for use as a file format or for net-working. This memo provides information for the Internet community.

draft-wildgrube-sdxf-08 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3072
RFC3073 Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration J. Collins March 2001 ASCII 9076 6 multipurpose internet mail extensions

This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification. This memo provides information for the Internet community.

draft-collins-pfr-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3073
RFC3074 DHC Load Balancing Algorithm B. Volz S. Gonczi T. Lemon R. Stevens February 2001 ASCII 19374 10 dynamic host configuration protocol

This document proposes a method of algorithmic load balancing. [STANDARDS-TRACK]

draft-ietf-dhc-loadb-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3074
RFC3075 XML-Signature Syntax and Processing D. Eastlake 3rd J. Reagle D. Solo March 2001 ASCII 145520 64 extensible markup language

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]

draft-ietf-xmldsig-core-11 RFC3275 PROPOSED STANDARD PROPOSED STANDARD IETF sec xmldsig 10.17487/RFC3075
RFC3076 Canonical XML Version 1.0 J. Boyer March 2001 ASCII 63955 28 extensible markup language

This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. This memo provides information for the Internet community.

draft-ietf-xmldsig-canonical-01 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC3076
RFC3077 A Link-Layer Tunneling Mechanism for Unidirectional Links E. Duros W. Dabbous H. Izumiyama N. Fujii Y. Zhang March 2001 ASCII 52410 25 ll udl bidirectional connectivity ip internet protocol

This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. [STANDARDS-TRACK]

draft-ietf-udlr-lltunnel-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg udlr 10.17487/RFC3077
RFC3078 Microsoft Point-To-Point Encryption (MPPE) Protocol G. Pall G. Zorn March 2001 ASCII 22952 12 security ppp

This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets. This memo provides information for the Internet community.

draft-ietf-pppext-mppe-05 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC3078
RFC3079 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) G. Zorn March 2001 ASCII 38905 21 security ppp

This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. This memo provides information for the Internet community.

draft-ietf-pppext-mppe-keys-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3079
RFC3080 The Blocks Extensible Exchange Protocol Core M. Rose March 2001 ASCII 82089 58 BEEP text binary messages kernal

This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. [STANDARDS-TRACK]

draft-ietf-beep-framework-11 PROPOSED STANDARD PROPOSED STANDARD IETF app beep http://www.rfc-editor.org/errata_search.php?rfc=3080 10.17487/RFC3080
RFC3081 Mapping the BEEP Core onto TCP M. Rose March 2001 ASCII 14008 8 transmission control protocol blocks extensible exchange

This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. [STANDARDS-TRACK]

draft-ietf-beep-tcpmapping-06 PROPOSED STANDARD PROPOSED STANDARD IETF app beep 10.17487/RFC3081
RFC3082 Notification and Subscription for SLP J. Kempf J. Goldschmidt March 2001 ASCII 33410 14 service location protocol

The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling. This memo defines an Experimental Protocol for the Internet community.

draft-kempf-srvloc-notify-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3082
RFC3083 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems R. Woundy March 2001 ASCII 88318 45 MIB BPI data-over-cable service interface specifications

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based (Simple Network Management Protocol) management of the Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0 (Data-Over- Cable Service Interface Specifications) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This memo provides information for the Internet community.

draft-ietf-ipcdn-mcns-bpi-mib-02 INFORMATIONAL INFORMATIONAL IETF ops ipcdn http://www.rfc-editor.org/errata_search.php?rfc=3083 10.17487/RFC3083
RFC3084 COPS Usage for Policy Provisioning (COPS-PR) K. Chan J. Seligson D. Durham S. Gai K. McCloghrie S. Herzog F. Reichmeyer R. Yavatkar A. Smith March 2001 ASCII 79341 34 COPS-PR common open service security quality

This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS-TRACK]

draft-ietf-rap-pr-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3084
RFC3085 URN Namespace for NewsML Resources A. Coates D. Allen D. Rivers-Moore March 2001 ASCII 10016 6 uniform resource name newsitems iptc

This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. This memo provides information for the Internet community.

draft-iptc-newsml-urn-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3085
RFC3086 Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification K. Nichols B. Carpenter April 2001 ASCII 63122 24 diffserv QoS quality of service

This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This memo provides information for the Internet community.

draft-ietf-diffserv-pdb-def-03 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3086
RFC3087 Control of Service Context using SIP Request-URI B. Campbell R. Sparks April 2001 ASCII 83612 39 session initiation protocol uniform resource identifier

This memo describes a useful way to conceptualize the use of the standard SIP (Session Initiation Protocol) Request-URI (Uniform Resource Identifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543. This memo provides information for the Internet community.

draft-campbell-sip-service-control-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3087
RFC3088 OpenLDAP Root Service An experimental LDAP referral service K. Zeilenga April 2001 ASCII 19471 11 lightweight directory access protocol dns domain name system

The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the "OpenLDAP Root Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records). This document describes this service. This memo defines an Experimental Protocol for the Internet community.

draft-zeilenga-ldap-root-02 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3088
RFC3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism H. Kitamura April 2001 ASCII 25193 12 internet protocol application layer

This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. This memo provides information for the Internet community.

draft-ietf-ngtrans-socks-gateway-06 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3089
RFC3090 DNS Security Extension Clarification on Zone Status E. Lewis March 2001 ASCII 24166 11 domain name system rsa dsa

The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. [STANDARDS-TRACK]

draft-ietf-dnsext-zone-status-05 RFC4033 RFC4034 RFC4035 RFC2535 RFC3658 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3090
RFC3091 Pi Digit Generation Protocol H. Kennedy April 1 2001 ASCII 10375 6

This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3091
RFC3092 Etymology of "Foo" D. Eastlake 3rd C. Manros E. Raymond April 1 2001 ASCII 29235 14

Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3092 10.17487/RFC3092
RFC3093 Firewall Enhancement Protocol (FEP) M. Gaynor S. Bradner April 1 2001 ASCII 22405 11

Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3093
RFC3094 Tekelec's Transport Adapter Layer Interface D. Sprague R. Benedyk D. Brendes J. Keller April 2001 ASCII 265099 106 signaling gatewa circuit network internet protocol

This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. This memo provides information for the Internet community.

draft-benedyk-sigtran-tali-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3094
RFC3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed C. Bormann C. Burmeister M. Degermark H. Fukushima H. Hannu L-E. Jonsson R. Hakenberg T. Koren K. Le Z. Liu A. Martensson A. Miyazaki K. Svanbro T. Wiebke T. Yoshimura H. Zheng July 2001 ASCII 368746 168 encapsulating security payload real-time transport protocol user datagram

This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK]

draft-ietf-rohc-rtp-09 RFC3759 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3095
RFC3096 Requirements for robust IP/UDP/RTP header compression M. Degermark Editor July 2001 ASCII 15018 8 real-time transport internet protocol user datagram

This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP. This memo provides information for the Internet community.

draft-ietf-rohc-rtp-requirements-05 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3096
RFC3097 RSVP Cryptographic Authentication -- Updated Message Type Value R. Braden L. Zhang April 2001 ASCII 6320 4 RSVP resource reservation protocol security

This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages. [STANDARDS-TRACK]

draft-ietf-rsvp-fix-iana-00 RFC2747 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC3097
RFC3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$ T. Gavin D. Eastlake 3rd S. Hambridge April 2001 ASCII 64687 28 internet marketing users service providers isps

This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. This memo provides information for the Internet community.

draft-ietf-run-adverts-02 FYI0038 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC3098
RFC3099 Request for Comments Summary RFC Numbers 3000-3099 S. Ginoza November 2001 ASCII 48990 25 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3099 RFC3100 RFC3101 The OSPF Not-So-Stubby Area (NSSA) Option P. Murphy January 2003 ASCII 76243 33 OSPF-NSSA stub external routes backward compatible

This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]

draft-ietf-ospf-nssa-update-11 RFC1587 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3101
RFC3102 Realm Specific IP: Framework M. Borella J. Lo D. Grabelsky G. Montenegro October 2001 ASCII 73856 30 RSIP end-to-end NAT addressing requirements

This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-nat-rsip-framework-05 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3102
RFC3103 Realm Specific IP: Protocol Specification M. Borella D. Grabelsky J. Lo K. Taniguchi October 2001 ASCII 115855 54 RSIP host gateway NAT requirements

This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-nat-rsip-protocol-07 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3103
RFC3104 RSIP Support for End-to-end IPsec G. Montenegro M. Borella October 2001 ASCII 38719 19 realm specific internet protocol NAT addressing requirements

This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-nat-rsip-ipsec-04 EXPERIMENTAL EXPERIMENTAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=3104 10.17487/RFC3104
RFC3105 Finding an RSIP Server with SLP J. Kempf G. Montenegro October 2001 ASCII 21427 11 realm specific internet protocol service location NAT addressing requirements

This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-nat-rsip-slp-00 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3105
RFC3106 ECML v1.1: Field Specifications for E-Commerce D. Eastlake 3rd T. Goldstein April 2001 ASCII 40715 20 electronic modeling language

Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication. This memo provides information for the Internet community.

draft-eastlake-ecom-fields2-05 RFC2706 RFC4112 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3106
RFC3107 Carrying Label Information in BGP-4 Y. Rekhter E. Rosen May 2001 ASCII 16442 8 SDP asynchronous transfer mode AAL syntax adaption layer

This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS-TRACK]

draft-ietf-mpls-bgp4-mpls-04 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3107 10.17487/RFC3107
RFC3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections R. Kumar M. Mostafa May 2001 ASCII 248037 110 asynchronous transfer mode AAL syntax adaption layer

This document describes conventions for using the Session Description Protocol (SDP) described in RFC 2327 for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-atm-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3108 10.17487/RFC3108
RFC3109 Request to Move STD 39 to Historic Status R. Braden R. Bush J. Klensin May 2001 ASCII 5841 4 BBN 1822 host imp arpanet

This memo changes the status of STD 39, BBN Report 1822, "Specification of the Interconnection of a Host and an IMP", from Standard to Historic. This memo provides information for the Internet community.

draft-ymbk-std39-historic-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3109
RFC3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) D. Eastlake 3rd May 2001 ASCII 14587 7 RRs resource records security

This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]

draft-ietf-dnsext-rsa-03 RFC2537 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3110 10.17487/RFC3110
RFC3111 Service Location Protocol Modifications for IPv6 E. Guttman May 2001 ASCII 25543 13 SLP internet protocol

This document defines the Service Location Protocol Version 2's (SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. [STANDARDS-TRACK]

draft-ietf-svrloc-ipv6-12 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc 10.17487/RFC3111
RFC3112 LDAP Authentication Password Schema K. Zeilenga May 2001 ASCII 17116 9 lightweight directory access protocol

This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This memo provides information for the Internet community.

draft-zeilenga-ldap-authpasswd-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3112
RFC3113 3GPP-IETF Standardization Collaboration K. Rosenbrock R. Sanmugam S. Bradner J. Klensin June 2001 ASCII 11405 7 internet engineering task force third generation partnership project

This document describes the standardization collaboration between 3GPP and IETF. This memo provides information for the Internet community.

draft-3gpp-collaboration-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3113
RFC3114 Implementing Company Classification Policy with the S/MIME Security Label W. Nicolls May 2002 ASCII 27764 14 data multipurpose internet mail extensions access control information classification security category

This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples. This memo provides information for the Internet community.

draft-ietf-smime-seclabel-03 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3114
RFC3115 Mobile IP Vendor/Organization-Specific Extensions G. Dommety K. Leung April 2001 ASCII 16363 9 internet protocol

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]

RFC3025 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3115
RFC3116 Methodology for ATM Benchmarking J. Dunn C. Martin June 2001 ASCII 295052 127 asynchronous transfer mode formats switching

This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (Asynchronous Transfer Mode) based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.

draft-ietf-bmwg-atm-method-03 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3116
RFC3117 On the Design of Application Protocols M. Rose November 2001 ASCII 57279 27 beep bxxp blocks extensible exchange text binary

This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). This memo provides information for the Internet community.

draft-mrose-beep-design-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3117
RFC3118 Authentication for DHCP Messages R. Droms W. Arbaugh Editors June 2001 ASCII 35536 17 dynamic host configuration protocol verification

This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS-TRACK]

draft-ietf-dhc-authentication-16 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3118 10.17487/RFC3118
RFC3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio R. Finlayson June 2001 ASCII 37796 19 real-time protocol moving picture experts group

This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mp3-06 RFC5219 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3119 10.17487/RFC3119
RFC3120 A URN Namespace for XML.org K. Best N. Walsh June 2001 ASCII 8068 5 uniform resource name extensible markup language

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.

draft-best-xmlorg-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3120
RFC3121 A URN Namespace for OASIS K. Best N. Walsh June 2001 ASCII 11074 7 uniform resource name organization for the advancement of structured information standards

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.

draft-best-urn-oasis-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3121
RFC3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification A. Conta June 2001 ASCII 40416 20 internet protocol IND link-layer

This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. [STANDARDS-TRACK]

draft-ietf-ion-ipv6-ind-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=3122 10.17487/RFC3122
RFC3123 A DNS RR Type for Lists of Address Prefixes (APL RR) P. Koch June 2001 ASCII 14648 8 domain name system resource record

The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dnsext-apl-rr-02 EXPERIMENTAL EXPERIMENTAL IETF int dnsext 10.17487/RFC3123
RFC3124 The Congestion Manager H. Balakrishnan S. Seshan June 2001 ASCII 53591 22 network stream end-system module

This document describes the Congestion Manager (CM), an end-system module that enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and allows applications to easily adapt to network congestion. [STANDARDS-TRACK]

draft-ietf-ecm-cm-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ecm 10.17487/RFC3124
RFC3125 Electronic Signature Policies J. Ross D. Pinkas N. Pope September 2001 ASCII 95505 44 signer purchase contract invoice transactions applications

This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-smime-espolicies-00 EXPERIMENTAL EXPERIMENTAL IETF sec smime 10.17487/RFC3125
RFC3126 Electronic Signature Formats for long term electronic signatures D. Pinkas J. Ross N. Pope September 2001 ASCII 175886 84 purchase contract invoice application smart cards data

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). This memo provides information for the Internet community.

draft-ietf-smime-esformats-03 RFC5126 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3126 10.17487/RFC3126
RFC3127 Authentication, Authorization, and Accounting: Protocol Evaluation D. Mitton M. St.Johns S. Barkley D. Nelson B. Patil M. Stevens B. Wolff June 2001 ASCII 170579 84 AAA network access requirements

This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989. This memo provides information for the Internet community.

draft-ietf-aaa-proto-eval-02 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC3127
RFC3128 Protection Against a Variant of the Tiny Fragment Attack (RFC 1858) I. Miller June 2001 ASCII 8242 5 firewalls internet

This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action. This memo provides information for the Internet community.

draft-miller-rfc1858-cmts-00 RFC1858 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3128
RFC3129 Requirements for Kerberized Internet Negotiation of Keys M. Thomas June 2001 ASCII 11401 6 KINK cryptographic security authentication

The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. This memo provides information for the Internet community.

draft-ietf-kink-reqmt-03 INFORMATIONAL INFORMATIONAL IETF sec kink 10.17487/RFC3129
RFC3130 Notes from the State-Of-The-Technology: DNSSEC E. Lewis June 2001 ASCII 22291 10 domain name system security extensions report

This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting. This memo provides information for the Internet community.

draft-lewis-state-of-dnssec-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3130
RFC3131 3GPP2-IETF Standardization Collaboration S. Bradner P. Calhoun H. Cuschieri S. Dennett G. Flynn M. Lipford M. McPheters June 2001 ASCII 13643 8 internet engineering task force third generation partnership project

This document describes the standardization collaboration between 3GPP2 and IETF. This memo provides information for the Internet community.

draft-bradner-3gpp2-collaboration-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3131
RFC3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement J. Kempf June 2001 ASCII 34985 14 molulity radio link internet protocl

This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. This memo provides information for the Internet community.

draft-ietf-seamoby-paging-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3132
RFC3133 Terminology for Frame Relay Benchmarking J. Dunn C. Martin June 2001 ASCII 44182 24 switching devices signaling

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices. This memo provides information for the Internet community.

draft-ietf-bmwg-fr-term-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3133
RFC3134 Terminology for ATM ABR Benchmarking J. Dunn C. Martin June 2001 ASCII 29542 16 asynchronous transfer mode available bit rate

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices supporting ABR (Available Bit Rate). This memo provides information for the Internet community.

draft-ietf-bmwg-atm-term-abr-03 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3134
RFC3135 Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations J. Border M. Kojo J. Griner G. Montenegro Z. Shelby June 2001 ASCII 114825 45 PEP PILC TCP transmission control protocol

This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. This memo provides information for the Internet community.

draft-ietf-pilc-pep-07 INFORMATIONAL INFORMATIONAL IETF tsv pilc 10.17487/RFC3135
RFC3136 The SPIRITS Architecture L. Slutsman Editor I. Faynberg H. Lu M. Weissman June 2001 ASCII 19241 10 PSTN public switched telephone network

This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public Switched Telephone Network)and necessitating the interactions between the PSTN and the Internet. This memo provides information for the Internet community.

draft-ietf-spirits-architecture-03 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC3136
RFC3137 OSPF Stub Router Advertisement A. Retana L. Nguyen R. White A. Zinin D. McPherson June 2001 ASCII 8140 5 open shortest path first

This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This memo provides information for the Internet community.

draft-ietf-ospf-stub-adv-02 RFC6987 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC3137
RFC3138 Extended Assignments in 233/8 D. Meyer June 2001 ASCII 6776 4 internet address AS autonomous system number

This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space. This memo provides information for the Internet community.

draft-ietf-mboned-glop-extensions-02 RFC5771 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3138
RFC3139 Requirements for Configuration Management of IP-based Networks L. Sanchez K. McCloghrie J. Saperia June 2001 ASCII 23624 11 internet protocol

This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP-based networks. This memo provides information for the Internet community.

draft-ops-ip-config-management-reqmnts-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3139
RFC3140 Per Hop Behavior Identification Codes D. Black S. Brim B. Carpenter F. Le Faucheur June 2001 ASCII 16586 8 PHB differentiated services codepoint DSCP

This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836. [STANDARDS-TRACK]

draft-ietf-diffserv-2836bis-02 RFC2836 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC3140
RFC3141 CDMA2000 Wireless Data Requirements for AAA T. Hiller P. Walsh X. Chen M. Munson G. Dommety S. Sivalingham B. Lim P. McCann H. Shiino B. Hirschman S. Manning R. Hsu H. Koo M. Lipford P. Calhoun C. Lo E. Jaques E. Campbell Y.Xu,S.Baba,T.Ayaki,T.Seki,A.Hameed June 2001 ASCII 27998 16 authentication authorization accounting

This memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. This memo provides information for the Internet community.

draft-hiller-cdma2000-aaa-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3141
RFC3142 An IPv6-to-IPv4 Transport Relay Translator J. Hagino K. Yamamoto June 2001 ASCII 20864 11 TRT internet protocol

The document describes an IPv6-to-IPv4 transport relay translator (TRT). This memo provides information for the Internet community.

draft-ietf-ngtrans-tcpudp-relay-04 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3142
RFC3143 Known HTTP Proxy/Caching Problems I. Cooper J. Dilley June 2001 ASCII 57117 32 www world wide web hypertext transfer protocol

This document catalogs a number of known problems with World Wide Web (WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. This memo provides information for the Internet community.

draft-cooper-wrec-known-prob-01 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3143 10.17487/RFC3143
RFC3144 Remote Monitoring MIB Extensions for Interface Parameters Monitoring D. Romascanu August 2001 ASCII 62491 30 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. [STANDARDS-TRACK]

draft-ietf-rmonmib-iftopn-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3144
RFC3145 L2TP Disconnect Cause Information R. Verma M. Verma J. Carlson July 2001 ASCII 17421 10 layer2 tunneling PPP point-to-point accounting debugging

This document provides an extension to the Layer 2 Tunneling Protocol ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3145
RFC3146 Transmission of IPv6 Packets over IEEE 1394 Networks K. Fujisawa A. Onoe October 2001 ASCII 16569 8 link-local addresses statelessly autoconfigured

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. [STANDARDS-TRACK]

draft-ietf-ipngwg-1394-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC3146
RFC3147 Generic Routing Encapsulation over CLNS Networks P. Christian July 2001 ASCII 14125 8 connectionless network service GRE layer protocol

This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network using GRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3147
RFC3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics M. Mathis M. Allman July 2001 ASCII 36041 16 BTC transport data

This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity. This memo provides information for the Internet community.

draft-ietf-ippm-btc-framework-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3148
RFC3149 MGCP Business Phone Packages A. Srinath G. Levendel K. Fritz R. Kalyanaram September 2001 ASCII 77304 41 media gateway control packages

This document describes a collection of MGCP (Media Gateway Control Protocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones. This memo provides information for the Internet community.

draft-srinath-mgcp-bus-packages-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3149
RFC3150 End-to-end Performance Implications of Slow Links S. Dawkins G. Montenegro M. Kojo V. Magret July 2001 ASCII 39942 17 PILC data applications header compression

This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-slow-06 BCP0048 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3150
RFC3151 A URN Namespace for Public Identifiers N. Walsh J. Cowan P. Grosso August 2001 ASCII 15595 9 uniform resource name publicid

This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI (Uniform Resource Identifiers) syntax. This memo provides information for the Internet community.

draft-walsh-urn-publicid-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3151
RFC3152 Delegation of IP6.ARPA R. Bush August 2001 ASCII 5727 4 internet protocol domain name system DNS zone

This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ymbk-ip6-arpa-delegation-02 RFC3596 RFC2874 RFC2772 RFC2766 RFC2553 RFC1886 BCP0049 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3152
RFC3153 PPP Multiplexing R. Pazhyannur I. Ali C. Fox August 2001 ASCII 19244 9 point-to-point protocol

This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links. [STANDARDS-TRACK]

draft-ietf-pppext-pppmux-03 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3153
RFC3154 Requirements and Functional Architecture for an IP Host Alerting Protocol J. Kempf C. Castelluccia P. Mutaf N. Nakajima Y. Ohba R. Ramjee Y. Saifullah B. Sarikaya X. Xu August 2001 ASCII 31534 16 internet protocol paging mobile hosts

This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. This memo provides information for the Internet community.

draft-ietf-seamoby-paging-requirements-01 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3154
RFC3155 End-to-end Performance Implications of Links with Errors S. Dawkins G. Montenegro M. Kojo V. Magret N. Vaidya August 2001 ASCII 36388 16 TCP transmission control protocol

This document discusses the specific TCP mechanisms that are problematic in environments with high uncorrected error rates, and discusses what can be done to mitigate the problems without introducing intermediate devices into the connection. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-error-08 BCP0050 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3155
RFC3156 MIME Security with OpenPGP M. Elkins D. Del Torto R. Levien T. Roessler August 2001 ASCII 26809 15 MIME-PGP Authentication Encryption

This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]

draft-ietf-openpgp-mime-07 RFC2015 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp http://www.rfc-editor.org/errata_search.php?rfc=3156 10.17487/RFC3156
RFC3157 Securely Available Credentials - Requirements A. Arsenault S. Farrell August 2001 ASCII 46169 20 SACRED trusted roots private keys PSE personal security environment

This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This memo provides information for the Internet community.

draft-ietf-sacred-reqs-03 INFORMATIONAL INFORMATIONAL IETF sec sacred 10.17487/RFC3157
RFC3158 RTP Testing Strategies C. Perkins J. Rosenberg H. Schulzrinne August 2001 ASCII 48208 22 real-time transport protocol

This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations. This memo provides information for the Internet community.

draft-ietf-avt-rtptest-06 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC3158
RFC3159 Structure of Policy Provisioning Information (SPPI) K. McCloghrie M. Fine J. Seligson K. Chan S. Hahn R. Sahita A. Smith F. Reichmeyer August 2001 ASCII 78621 40 PIB base SNMP simple network management information SMI

This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. [STANDARDS-TRACK]

draft-ietf-rap-sppi-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3159
RFC3160 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force S. Harris August 2001 ASCII 98411 38 Internet Engineering Task Force Meeting

This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. This memo provides information for the Internet community.

draft-ietf-uswg-tao-06 RFC1718 RFC4677 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC3160
RFC3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) C. Adams P. Cain D. Pinkas R. Zuccherato August 2001 ASCII 54585 26 TSA authority security request response

This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK]

draft-ietf-pkix-time-stamp-15 RFC5816 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3161 10.17487/RFC3161
RFC3162 RADIUS and IPv6 B. Aboba G. Zorn D. Mitton August 2001 ASCII 20492 12 remote authentication dial in user service attributes

This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. [STANDARDS-TRACK]

draft-aboba-radius-ipv6-10 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3162 10.17487/RFC3162
RFC3163 ISO/IEC 9798-3 Authentication SASL Mechanism R. Zuccherato M. Nystrom August 2001 ASCII 32498 17 simple authentication security layer

This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication. This memo defines an Experimental Protocol for the Internet community.

draft-zuccherato-9798-3-sasl-03 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3163
RFC3164 The BSD Syslog Protocol C. Lonvick August 2001 ASCII 72951 29 berkeley software distribution transmission messages

This document describes the observed behavior of the syslog protocol. This memo provides information for the Internet community.

draft-ietf-syslog-syslog-12 RFC5424 INFORMATIONAL INFORMATIONAL IETF sec syslog 10.17487/RFC3164
RFC3165 Definitions of Managed Objects for the Delegation of Management Scripts D. Levi J. Schoenwaelder August 2001 ASCII 134479 64 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]

draft-ietf-disman-script-mib-v2-04 RFC2592 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=3165 10.17487/RFC3165
RFC3166 Request to Move RFC 1403 to Historic Status D. Meyer J. Scudder August 2001 ASCII 3740 3 BGP-OSPF Border gateway protocol Open shortest path first routing

RFC 1403, "BGP OSPF Interaction", describes technology which is no longer used. This document requests that RFC 1403 be moved to Historic status. This memo provides information for the Internet community.

draft-meyer-rfc1403-historic-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3166
RFC3167 Request to Move RFC 1745 to Historic Status D. Meyer J. Scudder August 2001 ASCII 3825 3 BGP4/IDRP Internet Inter-Domain Routing Protocol Border Gateway Open Shortest Path First

RFC 1745, "BGP4/IDRP for IP---OSPF Interaction", describes technology which was never deployed in the public internet. This document requests that RFC 1745 be moved to Historic status. This memo provides information for the Internet community.

draft-meyer-rfc1745-historic-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3167
RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP K. Ramakrishnan S. Floyd D. Black September 2001 ASCII 170966 63 internet protocol header

This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]

draft-ietf-tsvwg-ecn-04 RFC2481 RFC2003 RFC2474 RFC2401 RFC0793 RFC4301 RFC6040 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3168 10.17487/RFC3168
RFC3169 Criteria for Evaluating Network Access Server Protocols M. Beadles D. Mitton September 2001 ASCII 35303 17 NAS network device AAA authentication authorization accounting

This document defines requirements for protocols used by Network Access Servers (NAS). This memo provides information for the Internet community.

draft-ietf-nasreq-criteria-06 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC3169
RFC3170 IP Multicast Applications: Challenges and Solutions B. Quinn K. Almeroth September 2001 ASCII 67207 28 internet protocol unicast

This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications. This memo provides information for the Internet community.

draft-ietf-mboned-mcast-apps-02 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3170
RFC3171 IANA Guidelines for IPv4 Multicast Address Assignments Z. Albanna K. Almeroth D. Meyer M. Schipper August 2001 ASCII 15389 8 internet assigned numbers authority protocol parameters

This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mboned-iana-ipv4-mcast-guidelines-04 RFC5771 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=3171 10.17487/RFC3171
RFC3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa") G. Huston Editor September 2001 ASCII 18097 8 database DNS domain name system

This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-arpa-03 BCP0052 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC3172
RFC3173 IP Payload Compression Protocol (IPComp) A. Shacham B. Monsour R. Pereira M. Thomas September 2001 ASCII 15389 13 IPCOMP internet protocol datagram lossless

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]

draft-shacham-ippcp-rfc2393bis-08 RFC2393 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3173
RFC3174 US Secure Hash Algorithm 1 (SHA1) D. Eastlake 3rd P. Jones September 2001 ASCII 35525 22 FIPS federal information processing standard

The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.

draft-eastlake-sha1-02 RFC4634 RFC6234 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3174 10.17487/RFC3174
RFC3175 Aggregation of RSVP for IPv4 and IPv6 Reservations F. Baker C. Iturralde F. Le Faucheur B. Davie September 2001 ASCII 88681 36 resource reservation protocol internet ATM asynchronous transfer mode

This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations. [STANDARDS-TRACK]

draft-ietf-issll-rsvp-aggr-04 RFC5350 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC3175
RFC3176 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks P. Phaal S. Panchen N. McKee September 2001 ASCII 60171 31 agent data MIB management information base

This memo defines InMon Corporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. This memo provides information for the Internet community.

draft-phaal-sflow-montraffic-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3176
RFC3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites IAB IESG September 2001 ASCII 23178 10 internet architecture board engineering steering group protocol

This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.

draft-iesg-ipv6-addressing-recommendations-03 RFC6177 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC3177
RFC3178 IPv6 Multihoming Support at Site Exit Routers J. Hagino H. Snyder October 2001 ASCII 24453 12 internet protocol ISP Service Provider Routing

The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. This memo provides information for the Internet community.

draft-ietf-ipngwg-ipv6-2260-02 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC3178
RFC3179 Script MIB Extensibility Protocol Version 1.1 J. Schoenwaelder J. Quittek October 2001 ASCII 56311 25 SMX language management information base

The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. This memo defines an Experimental Protocol for the Internet community.

draft-schoenw-rfc-2593-update-04 RFC2593 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3179
RFC3180 GLOP Addressing in 233/8 D. Meyer P. Lothberg September 2001 ASCII 8225 5 static multicast

This document defines the policy for the use of 233/8 for statically e assigned multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mboned-glop-update-01 RFC2770 BCP0053 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=3180 10.17487/RFC3180
RFC3181 Signaled Preemption Priority Policy Element S. Herzog October 2001 ASCII 21990 12 rsvp resource reservation protocol cops common open service

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS). [STANDARDS-TRACK]

draft-ietf-rap-signaled-priority-v2-00 RFC2751 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3181
RFC3182 Identity Representation for RSVP S. Yadav R. Yavatkar R. Pabbati P. Ford T. Moore S. Herzog R. Hess October 2001 ASCII 36544 18 resource reservation protocol

This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-newidentity-01 RFC2752 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap http://www.rfc-editor.org/errata_search.php?rfc=3182 10.17487/RFC3182
RFC3183 Domain Security Services using S/MIME T. Dean W. Ottaway October 2001 ASCII 57129 24 secure/multipurpose internet mail extensions

This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-smime-domsec-09 EXPERIMENTAL EXPERIMENTAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3183 10.17487/RFC3183
RFC3184 IETF Guidelines for Conduct S. Harris October 2001 ASCII 7413 4 internet engineering task force

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-poisson-code-04 RFC7154 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC3184
RFC3185 Reuse of CMS Content Encryption Keys S. Farrell S. Turner October 2001 ASCII 20404 10 cryptographic message syntax data packets

This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. [STANDARDS-TRACK]

draft-ietf-smime-rcek-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3185
RFC3186 MAPOS/PPP Tunneling mode S. Shimizu T. Kawano K. Murakami E. Beier December 2001 ASCII 27109 14 multiple access protocol over SONET/SDH point-to-point

This document specifies tunneling configuration over MAPOS (Multiple Access Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead. This memo provides information for the Internet community.

draft-shimizu-ppp-mapos-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3186
RFC3187 Using International Standard Book Numbers as Uniform Resource Names J. Hakala H. Walravens October 2001 ASCII 22620 11 isbn urn bibliographic identifiers

This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.

draft-hakala-isbn-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3187
RFC3188 Using National Bibliography Numbers as Uniform Resource Names J. Hakala October 2001 ASCII 27923 13 urn nbn national libraries

This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.

draft-hakala-nbn-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3188
RFC3189 RTP Payload Format for DV (IEC 61834) Video K. Kobayashi A. Ogawa S. Casner C. Bormann January 2002 ASCII 25991 13 real-time transport protocol

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

draft-ietf-avt-dv-video-04 RFC6469 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3189 10.17487/RFC3189
RFC3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio K. Kobayashi A. Ogawa S. Casner C. Bormann January 2002 ASCII 34977 17 real-time transport protocol digital audio tape

This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear). [STANDARDS-TRACK]

draft-ietf-avt-dv-audio-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3190
RFC3191 Minimal GSTN address format in Internet Mail C. Allocchio October 2001 ASCII 24235 13 MIN-PSTN global switched telephone network email

This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. [STANDARDS-TRACK]

draft-ietf-fax-minaddr-v2-04 RFC2303 RFC2846 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3191
RFC3192 Minimal FAX address format in Internet Mail C. Allocchio October 2001 ASCII 18813 11 MINFAX-IM facsimile GSTN global switched telephone network

This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses of facsimile devices in the local- part of Internet email addresses. [STANDARDS-TRACK]

draft-ietf-fax-faxaddr-v2-04 RFC2304 RFC2846 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3192
RFC3193 Securing L2TP using IPsec B. Patel B. Aboba W. Dixon G. Zorn S. Booth November 2001 ASCII 63804 28 layer two tunneling protocol authentication

This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed. [STANDARDS-TRACK]

draft-ietf-l2tpext-security-08 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3193
RFC3194 The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio A. Durand C. Huitema November 2001 ASCII 14539 7 IPng White Paper

This document provides an update on the "H ratio" defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand. This memo provides information for the Internet community.

draft-durand-huitema-h-density-ratio-01 RFC1715 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3194
RFC3195 Reliable Delivery for syslog D. New M. Rose November 2001 ASCII 60960 36 mappings encryption authentication beep blocks extensible exchange

The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. [STANDARDS-TRACK]

draft-ietf-syslog-reliable-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC3195
RFC3196 Internet Printing Protocol/1.1: Implementor's Guide T. Hastings C. Manros P. Zehler C. Kugler H. Holst November 2001 ASCII 200720 96 IPP client object

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). This memo provides information for the Internet community.

draft-ietf-ipp-implementers-guide-v11-03 RFC2639 INFORMATIONAL INFORMATIONAL IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3196 10.17487/RFC3196
RFC3197 Applicability Statement for DNS MIB Extensions R. Austein November 2001 ASCII 8610 5 DNS-R-MIB Domain Name System Management Information Base

This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status. This memo provides information for the Internet community.

draft-ietf-dnsext-dnsmib-historical-00 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC3197
RFC3198 Terminology for Policy-Based Management A. Westerinen J. Schnizlein J. Strassner M. Scherling B. Quinn S. Herzog A. Huynh M. Carlson J. Perry S. Waldbusser November 2001 ASCII 47806 21 glossary network ISDs internet standard documents

This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs). This memo provides information for the Internet community.

draft-ietf-policy-terminology-04 INFORMATIONAL INFORMATIONAL IETF ops policy 10.17487/RFC3198
RFC3199 Request for Comments Summary RFC Numbers 3100-3199 S. Ginoza February 2003 ASCII 47287 24 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3199 RFC3200 RFC3201 Definitions of Managed Objects for Circuit to Interface Translation R. Steinberger O. Nicklass January 2002 ASCII 45583 23 mib

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. [STANDARDS-TRACK]

draft-ietf-frnetmib-frsi-04 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3201
RFC3202 Definitions of Managed Objects for Frame Relay Service Level Definitions R. Steinberger O. Nicklass January 2002 ASCII 130816 64 mib

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service Level Definitions. [STANDARDS-TRACK]

draft-ietf-frnetmib-frmrelay-service-06 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3202
RFC3203 DHCP reconfigure extension Y. T'Joens C. Hublet P. De Schrijver December 2001 ASCII 11857 6 dynamic host configuration protocol forcerenew

This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS-TRACK]

draft-ietf-dhc-pv4-reconfigure-06 RFC6704 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3203
RFC3204 MIME media types for ISUP and QSIG Objects E. Zimmerer J. Peterson A. Vemuri L. Ong F. Audet M. Watson M. Zonoun December 2001 ASCII 19712 10 multipart internet mail extensions

This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. [STANDARDS-TRACK]

draft-ietf-sip-isup-mime-10 RFC3459 RFC5621 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3204 10.17487/RFC3204
RFC3205 On the use of HTTP as a Substrate K. Moore February 2002 ASCII 34785 14 hypertext transfer protocol layering

Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-moore-using-http-01 BCP0056 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=3205 10.17487/RFC3205
RFC3206 The SYS and AUTH POP Response Codes R. Gellens February 2002 ASCII 9917 6 security authentication

This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. [STANDARDS-TRACK]

draft-gellens-pop-err-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3206
RFC3207 SMTP Service Extension for Secure SMTP over Transport Layer Security P. Hoffman February 2002 ASCII 18679 9 simple mail transfer protocol ssl tls

This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]

draft-hoffman-rfc2487bis-06 RFC2487 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3207 10.17487/RFC3207
RFC3208 PGM Reliable Transport Protocol Specification T. Speakman J. Crowcroft J. Gemmell D. Farinacci S. Lin D. Leshchiner M. Luby T. Montgomery L. Rizzo A. Tweedly N. Bhaskar R. Edmonstone R. Sumanasekera L. Vicisano December 2001 ASCII 244637 111 pragmatic general multicast

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. This memo defines an Experimental Protocol for the Internet community.

draft-speakman-pgm-spec-07 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3208 10.17487/RFC3208
RFC3209 RSVP-TE: Extensions to RSVP for LSP Tunnels D. Awduche L. Berger D. Gan T. Li V. Srinivasan G. Swallow December 2001 ASCII 132264 61 resource reservation protocol label switched paths

This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-lsp-tunnel-09 RFC3936 RFC4420 RFC4874 RFC5151 RFC5420 RFC5711 RFC6780 RFC6790 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3209 10.17487/RFC3209
RFC3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels D. Awduche A. Hannan X. Xiao December 2001 ASCII 17691 8 resource reservation protocol label switched paths

This memo discusses the applicability of "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. This memo provides information for the Internet community.

draft-ietf-mpls-rsvp-tunnel-applicability-02 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3210
RFC3211 Password-based Encryption for CMS P. Gutmann December 2001 ASCII 30527 17 cryptographic message syntax S/MIME key wrap derivation passwordrecipientinfo PWRI

This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. [STANDARDS-TRACK]

draft-ietf-smime-password-06 RFC3369 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3211
RFC3212 Constraint-Based LSP Setup using LDP B. Jamoussi Editor L. Andersson R. Callon R. Dantu L. Wu P. Doolan T. Worster N. Feldman A. Fredette M. Girish E. Gray J. Heinanen T. Kilty A. Malis January 2002 ASCII 87591 42 label switching protocol distribution CR

This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). [STANDARDS-TRACK]

draft-ietf-mpls-cr-ldp-06 RFC3468 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3212
RFC3213 Applicability Statement for CR-LDP J. Ash M. Girish E. Gray B. Jamoussi G. Wright January 2002 ASCII 14489 7 constraint-based label distribution protocol

This document discusses the applicability of Constraint-Based LSP Setup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. This memo provides information for the Internet community.

draft-ietf-mpls-crldp-applic-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3213
RFC3214 LSP Modification Using CR-LDP J. Ash Y. Lee P. Ashwood-Smith B. Jamoussi D. Fedyk D. Skalecki L. Li January 2002 ASCII 25453 11 label switching protocol constraint-based distribution

This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. [STANDARDS-TRACK]

draft-ietf-mpls-crlsp-modify-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3214
RFC3215 LDP State Machine C. Boscher P. Cheval L. Wu E. Gray January 2002 ASCII 117278 78 label distribution protocol

This document provides state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-state-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3215
RFC3216 SMIng Objectives C. Elliott D. Harrington J. Jason J. Schoenwaelder F. Strauss W. Weiss December 2001 ASCII 58551 33 SNMP simple network management protocol COPS-PR common open policy service provisioning

This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. This memo provides information for the Internet community.

draft-ietf-sming-reqs-06 INFORMATIONAL INFORMATIONAL IETF ops sming 10.17487/RFC3216
RFC3217 Triple-DES and RC2 Key Wrapping R. Housley December 2001 ASCII 19855 9 algorithm data encryption standard

This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. This memo provides information for the Internet community.

draft-ietf-smime-key-wrap-01 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3217 10.17487/RFC3217
RFC3218 Preventing the Million Message Attack on Cryptographic Message Syntax E. Rescorla January 2002 ASCII 16047 7 cryptographic syntax

This memo describes a strategy for resisting the Million Message Attack. This memo provides information for the Internet community.

draft-ietf-smime-pkcs1-01 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3218
RFC3219 Telephony Routing over IP (TRIP) J. Rosenberg H. Salama M. Squire January 2002 ASCII 184618 79 inter-administrative BGP border gateway protocol

This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. [STANDARDS-TRACK]

draft-ietf-iptel-trip-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=3219 10.17487/RFC3219
RFC3220 IP Mobility Support for IPv4 C. Perkins Editor January 2002 ASCII 238343 98 MOBILEIPSUPIP Internet Protocol

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]

draft-ietf-mobileip-rfc2002-bis-08 RFC2002 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3220 10.17487/RFC3220
RFC3221 Commentary on Inter-Domain Routing in the Internet G. Huston December 2001 ASCII 66580 25 BGP border gateway protocol

This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This memo provides information for the Internet community.

draft-iab-bgparch-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3221
RFC3222 Terminology for Forwarding Information Base (FIB) based Router Performance G. Trotter December 2001 ASCII 25483 15 internet protocol routing table benchmark

This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This memo provides information for the Internet community.

draft-ietf-bmwg-fib-term-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3222
RFC3223 RFC3224 Vendor Extensions for Service Location Protocol, Version 2 E. Guttman January 2002 ASCII 19618 10 SLP SVRLOC opaque

This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol." [STANDARDS-TRACK]

RFC2608 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3224 10.17487/RFC3224
RFC3225 Indicating Resolver Support of DNSSEC D. Conrad December 2001 ASCII 11548 6 domain name system security extensions

In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-okbit-02 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3225
RFC3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements O. Gudmundsson December 2001 ASCII 12078 6 domain name space security extensions dns endso

This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements. [STANDARDS-TRACK]

draft-ietf-dnsext-message-size-04 RFC2535 RFC2874 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3226 10.17487/RFC3226
RFC3227 Guidelines for Evidence Collection and Archiving D. Brezinski T. Killalea February 2002 ASCII 18468 10 security incident

A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grip-prot-evidence-05 BCP0055 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip 10.17487/RFC3227
RFC3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP) B. Fenner February 2002 ASCII 6473 4 assigned numbers authority

This memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-magma-igmp-iana-01 BCP0057 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int magma 10.17487/RFC3228
RFC3229 Delta encoding in HTTP J. Mogul B. Krishnamurthy F. Douglis A. Feldmann Y. Goland A. van Hoff D. Hellerstein January 2002 ASCII 111953 49 hyper text transfer protocol

This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS-TRACK]

draft-mogul-http-delta-10 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3229
RFC3230 Instance Digests in HTTP J. Mogul A. Van Hoff January 2002 ASCII 26846 13 hyper text transfer protocol

HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS-TRACK]

draft-mogul-http-digest-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3230
RFC3231 Definitions of Managed Objects for Scheduling Management Operations D. Levi J. Schoenwaelder January 2002 ASCII 61308 29 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. [STANDARDS-TRACK]

draft-ietf-disman-schedule-mib-v2-04 RFC2591 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3231
RFC3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database J. Reynolds Editor January 2002 ASCII 3849 3 IANA internet assigned numbers authority parameters

This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.

RFC1700 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3232
RFC3233 Defining the IETF P. Hoffman S. Bradner February 2002 ASCII 6401 4 internet engineering task force

This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hoffman-what-is-ietf-05 BCP0058 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3233
RFC3234 Middleboxes: Taxonomy and Issues B. Carpenter S. Brim February 2002 ASCII 62329 27 internet protocol router data path host

This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.

draft-carpenter-midtax-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3234
RFC3235 Network Address Translator (NAT)-Friendly Application Design Guidelines D. Senie January 2002 ASCII 29588 13 NAPT ALG firewall

This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). This memo provides information for the Internet community.

draft-ietf-nat-app-guide-07 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC3235
RFC3236 The 'application/xhtml+xml' Media Type M. Baker P. Stark January 2002 ASCII 16750 8 mime multipurpose internet mail extensions

This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'. This memo provides information for the Internet community.

draft-baker-xhtml-media-reg-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3236
RFC3237 Requirements for Reliable Server Pooling M. Tuexen Q. Xie R. Stewart M. Shore L. Ong J. Loughney M. Stillman January 2002 ASCII 16986 10 rserpool application

This document defines a basic set of requirements for reliable server pooling. This memo provides information for the Internet community.

draft-ietf-rserpool-reqts-03 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC3237
RFC3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services S. Floyd L. Daigle January 2002 ASCII 42336 17 OPES internet architecture board

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. This memo provides information for the Internet community.

draft-iab-opes-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3238
RFC3239 Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations C. Kugler H. Lewis T. Hastings February 2002 ASCII 29532 15 object device

This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet Printing Protocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects. The remaining operations operate on a new Device object that more closely models a single output device. This memo provides information for the Internet community.

draft-ietf-ipp-ops-admin-req-01 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC3239
RFC3240 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration D. Clunie E. Cordonnier February 2002 ASCII 9102 6 multipurpose internet mail extensions

This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine). The baseline encoding is defined by the DICOM Standards Committee in "Digital Imaging and Communications in Medicine". This memo provides information for the Internet community.

draft-dicom-media-type-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3240
RFC3241 Robust Header Compression (ROHC) over PPP C. Bormann April 2002 ASCII 24424 12 point-to-point protocol datagram packets

This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point- to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]

draft-ietf-rohc-over-ppp-04 RFC1332 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3241
RFC3242 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP L-E. Jonsson G. Pelletier April 2002 ASCII 49007 21 internet protocol user datagram real-time application transport

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. [STANDARDS-TRACK]

draft-ietf-rohc-rtp-lla-03 RFC4362 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3242
RFC3243 RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression L-E. Jonsson April 2002 ASCII 12451 6 internet protocol user datagram real-time application transport applications LLA link-layer assisted

This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.

draft-ietf-rohc-rtp-0-byte-requirements-02 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3243
RFC3244 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols M. Swift J. Trostle J. Brezak February 2002 ASCII 13334 7 security message codes

This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user. This memo provides information for the Internet community.

draft-trostle-win2k-cat-kerberos-set-passwd-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3244
RFC3245 The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2) J. Klensin Editor IAB March 2002 ASCII 23758 10 IAB ARPA

RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.

draft-iab-itu-enum-notes-00 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3245 10.17487/RFC3245
RFC3246 An Expedited Forwarding PHB (Per-Hop Behavior) B. Davie A. Charny J.C.R. Bennet K. Benson J.Y. Le Boudec W. Courtney S. Davari V. Firoiu D. Stiliadis March 2002 ASCII 33896 16 per-hop behavior expedited forwarding differentiated services delay jitter

This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]

draft-ietf-diffserv-rfc2598bis-02 RFC2598 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC3246
RFC3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior) A. Charny J. Bennet K. Benson J. Boudec A. Chiu W. Courtney S. Davari V. Firoiu C. Kalmanek K. Ramakrishnan March 2002 ASCII 53786 24 differentiated services fifo fair queuing delay jitter

This document was written during the process of clarification of RFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This memo provides information for the Internet community.

draft-ietf-diffserv-ef-supplemental-01 INFORMATIONAL INFORMATIONAL IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3247 10.17487/RFC3247
RFC3248 A Delay Bound alternative revision of RFC 2598 G. Armitage B. Carpenter A. Casati J. Crowcroft J. Halpern B. Kumar J. Schnizlein March 2002 ASCII 21597 11 per hop behavior phb expedited forwarding ef db

For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB. This memo provides information for the Internet community.

draft-ietf-diffserv-efresolve-01 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3248
RFC3249 Implementers Guide for Facsimile Using Internet Mail V. Cancio M. Moldovan H. Tamura D. Wing September 2002 ASCII 40413 21 fax tiff tiff-fx ifax e-mail email esmtp dsn mdn

This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. This memo provides information for the Internet community.

draft-ietf-fax-implementers-guide-07 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC3249
RFC3250 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration L. McIntyre G. Parsons J. Rafferty September 2002 ASCII 17876 7 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]

draft-ietf-fax-tiff-fx-reg-01 RFC3950 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC3250
RFC3251 Electricity over IP B. Rajagopalan April 1 2002 ASCII 18994 9 Internet Protocol

Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question. This memo provides information for the Internet community.

draft-bala-mplamps-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3251
RFC3252 Binary Lexical Octet Ad-hoc Transport H. Kennedy April 1 2002 ASCII 25962 16 bloat

This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3252
RFC3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) G. Clemm J. Amsden T. Ellison C. Kaler J. Whitehead March 2002 ASCII 245514 118 hypertext transfer protocol clients label configuration management

This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. [STANDARDS-TRACK]

draft-ietf-deltav-versioning-20 PROPOSED STANDARD PROPOSED STANDARD IETF app deltav http://www.rfc-editor.org/errata_search.php?rfc=3253 10.17487/RFC3253
RFC3254 Definitions for talking about directories H. Alvestrand April 2002 ASCII 21541 11 domain name system lightweight access protocol

When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, "directories". This memo provides information for the Internet community.

draft-alvestrand-directory-defs-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3254
RFC3255 Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads N. Jones C. Murton April 2002 ASCII 14192 8

This document describes an extension to the mapping of Point-to-Point Protocol (PPP) into Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. [STANDARDS-TRACK]

draft-ietf-pppext-posvcholo-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3255
RFC3256 The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option D. Jones R. Woundy April 2002 ASCII 8551 5

This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS-TRACK]

draft-ietf-dhc-agentoptions-device-class-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3256
RFC3257 Stream Control Transmission Protocol Applicability Statement L. Coene April 2002 ASCII 24198 13 sctp udp tcp rtp transport security transport nat multihoming

This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) & Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. This memo provides information for the Internet community.

draft-ietf-sigtran-sctp-applicability-08 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC3257
RFC3258 Distributing Authoritative Name Servers via Shared Unicast Addresses T. Hardie April 2002 ASCII 22195 11 dns network topology latency

This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under- served areas of the network topology and to reduce the latency for DNS query responses in those areas. This memo provides information for the Internet community.

draft-ietf-dnsop-hardie-shared-root-server-07 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC3258
RFC3259 A Message Bus for Local Coordination J. Ott C. Perkins D. Kutscher April 2002 ASCII 84125 39 mbus message ip multicast addressing transport syntax

The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. This memo provides information for the Internet community.

draft-ietf-mmusic-mbus-transport-06 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC3259
RFC3260 New Terminology and Clarifications for Diffserv D. Grossman April 2002 ASCII 21900 10 DIFFSRV scalability IP internet protocol

This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community.

draft-ietf-diffserv-new-terms-08 RFC2474 RFC2475 RFC2597 INFORMATIONAL INFORMATIONAL IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3260 10.17487/RFC3260
RFC3261 SIP: Session Initiation Protocol J. Rosenberg H. Schulzrinne G. Camarillo A. Johnston J. Peterson R. Sparks M. Handley E. Schooler June 2002 ASCII 647976 269 SIP application-layer application layer multimedia multicast unicast

This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]

draft-ietf-sip-rfc2543bis-09 RFC2543 RFC3265 RFC3853 RFC4320 RFC4916 RFC5393 RFC5621 RFC5626 RFC5630 RFC5922 RFC5954 RFC6026 RFC6141 RFC6665 RFC6878 RFC7462 RFC7463 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3261 10.17487/RFC3261
RFC3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne June 2002 ASCII 29643 14 SIP application-layer application layer multimedia multicast unicast

This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS-TRACK]

draft-ietf-sip-100rel-06 RFC2543 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3262 10.17487/RFC3262
RFC3263 Session Initiation Protocol (SIP): Locating SIP Servers J. Rosenberg H. Schulzrinne June 2002 ASCII 42310 17 SIP application-layer application layer multimedia multicast unicast

The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS-TRACK]

draft-ietf-sip-srv-06 RFC2543 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3263
RFC3264 An Offer/Answer Model with Session Description Protocol (SDP) J. Rosenberg H. Schulzrinne June 2002 ASCII 60854 25 SIP application-layer application layer multimedia multicast unicast

This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-offer-answer-02 RFC2543 RFC6157 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3264 10.17487/RFC3264
RFC3265 Session Initiation Protocol (SIP)-Specific Event Notification A. B. Roach June 2002 ASCII 89005 38 SIP application-layer application layer multimedia multicast unicast

This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS-TRACK]

draft-ietf-sip-events-05 RFC2543 RFC6665 RFC3261 RFC5367 RFC5727 RFC6446 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3265 10.17487/RFC3265
RFC3266 Support for IPv6 in Session Description Protocol (SDP) S. Olson G. Camarillo A. B. Roach June 2002 ASCII 8693 5 internet addresses syntax

This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-ipv6-03 RFC4566 RFC2327 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3266 10.17487/RFC3266
RFC3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs J. Sjoberg M. Westerlund A. Lakaniemi Q. Xie June 2002 ASCII 110652 49 interoperate applications

This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. [STANDARDS-TRACK]

draft-ietf-avt-rtp-amr-13 RFC4867 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3267 10.17487/RFC3267
RFC3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) P. Chown June 2002 ASCII 13530 7 idea international data algorithm symmetric

This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS-TRACK]

draft-ietf-tls-ciphersuite-06 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3268
RFC3269 Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents R. Kermode L. Vicisano April 2002 ASCII 25258 12 definitions operation

This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community.

draft-ietf-rmt-author-guidelines-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3269
RFC3270 Multi-Protocol Label Switching (MPLS) Support of Differentiated Services F. Le Faucheur L. Wu B. Davie S. Davari P. Vaananen R. Krishnan P. Cheval J. Heinanen May 2002 ASCII 137960 64 diff-serv ba behaviour aggregate lsp label switched paths

This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS-TRACK]

draft-ietf-mpls-diff-ext-09 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3270 10.17487/RFC3270
RFC3271 The Internet is for Everyone V. Cerf April 2002 ASCII 12345 6 isoc internet society policy issues social impact economic impact international policy use and abuse of the internet

This document expresses the Internet Society's ideology that the Internet really is for everyone. However, it will only be such if we make it so. This memo provides information for the Internet community.

draft-isoc-internet-for-everyone-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3271 10.17487/RFC3271
RFC3272 Overview and Principles of Internet Traffic Engineering D. Awduche A. Chiu A. Elwalid I. Widjaja X. Xiao May 2002 ASCII 190384 71 te ip networks

This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community.

draft-ietf-tewg-principles-02 RFC5462 INFORMATIONAL INFORMATIONAL IETF subip tewg http://www.rfc-editor.org/errata_search.php?rfc=3272 10.17487/RFC3272
RFC3273 Remote Network Monitoring Management Information Base for High Capacity Networks S. Waldbusser July 2002 ASCII 150924 77 rmon mib high speed networks

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. [PROPOSED STANDARD]

draft-ietf-rmonmib-hcrmon-10 RFC4502 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3273
RFC3274 Compressed Data Content Type for Cryptographic Message Syntax (CMS) P. Gutmann June 2002 ASCII 11276 6 content info type

This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS-TRACK]

draft-ietf-smime-compression-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3274
RFC3275 (Extensible Markup Language) XML-Signature Syntax and Processing D. Eastlake 3rd J. Reagle D. Solo March 2002 ASCII 164198 73 extensible markup language

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]

draft-ietf-xmldsig-core-2-03 RFC3075 DRAFT STANDARD DRAFT STANDARD IETF sec xmldsig http://www.rfc-editor.org/errata_search.php?rfc=3275 10.17487/RFC3275
RFC3276 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing B. Ray R. Abbi May 2002 ASCII 122991 66 mib interfaces

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. [STANDARDS-TRACK]

draft-ietf-adslmib-hdsl2-12 RFC4319 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3276
RFC3277 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance D. McPherson April 2002 ASCII 13077 6 router

This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. This memo provides information for the Internet community.

draft-ietf-isis-transient-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3277
RFC3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) S. Blake-Wilson D. Brown P. Lambert April 2002 ASCII 33779 16 public key digital signatures authentication

This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. This memo provides information for the Internet community.

draft-ietf-smime-ecc-06 RFC5753 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3278
RFC3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile L. Bassham W. Polk R. Housley April 2002 ASCII 53833 27 ASN.1

This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK]

draft-ietf-pkix-ipki-pkalgs-05 RFC4055 RFC4491 RFC5480 RFC5758 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3279 10.17487/RFC3279
RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile R. Housley W. Polk W. Ford D. Solo April 2002 ASCII 295556 129

This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK]

draft-ietf-pkix-new-part1-12 RFC2459 RFC5280 RFC4325 RFC4630 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3280 10.17487/RFC3280
RFC3281 An Internet Attribute Certificate Profile for Authorization S. Farrell R. Housley April 2002 ASCII 90580 40 electronic mail email ipsec www security

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS-TRACK]

draft-ietf-pkix-ac509prof-09 RFC5755 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3281 10.17487/RFC3281
RFC3282 Content Language Headers H. Alvestrand May 2002 ASCII 14022 8

This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS-TRACK]

draft-alvestrand-content-language-03 RFC1766 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3282
RFC3283 Guide to Internet Calendaring B. Mahoney G. Babics A. Taler June 2002 ASCII 31768 16 scheduling systems cap calendar access protocool itip imip

This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. This memo provides information for the Internet community.

draft-ietf-calsch-inetcal-guide-02 INFORMATIONAL INFORMATIONAL IETF app calsch 10.17487/RFC3283
RFC3284 The VCDIFF Generic Differencing and Compression Data Format D. Korn J. MacDonald J. Mogul K. Vo June 2002 ASCII 64035 29 transport portable at&t encoding

This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS-TRACK]

draft-korn-vcdiff-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3284
RFC3285 Using Microsoft Word to create Internet Drafts and RFCs M. Gahrns T. Hain May 2002 ASCII 34556 19

This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. This memo provides information for the Internet community.

draft-hain-msword-template-04 RFC5385 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3285
RFC3286 An Introduction to the Stream Control Transmission Protocol (SCTP) L. Ong J. Yoakum May 2002 ASCII 22644 10 transport layer telephony signaling

This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. This memo provides information for the Internet community.

draft-ong-sigtran-sctpover-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3286
RFC3287 Remote Monitoring MIB Extensions for Differentiated Services A. Bierman July 2002 ASCII 249622 120 rmon management information base diffserv

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. [STANDARDS-TRACK]

draft-ietf-rmonmib-dsmon-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3287
RFC3288 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) E. O'Tuathail M. Rose June 2002 ASCII 27434 20 binding markup language xml

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. [STANDARDS-TRACK]

draft-etal-beep-soap-06 RFC4227 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3288
RFC3289 Management Information Base for the Differentiated Services Architecture F. Baker K. Chan A. Smith May 2002 ASCII 239041 116 mib diffserv router architecture

This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS-TRACK]

draft-ietf-diffserv-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3289 10.17487/RFC3289
RFC3290 An Informal Management Model for Diffserv Routers Y. Bernet S. Blake D. Grossman A. Smith May 2002 ASCII 129443 56 differentiated services

This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community.

draft-ietf-diffserv-model-06 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3290
RFC3291 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder May 2002 ASCII 43564 20 tc mib layer management information base

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-ops-rfc2851-update-06 RFC2851 RFC4001 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC3291
RFC3292 General Switch Management Protocol (GSMP) V3 A. Doria F. Hellstrand K. Sundell T. Worster June 2002 ASCII 318983 137 switch label unicast multicast qos quality of service

This document describes the General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. [STANDARDS-TRACK]

draft-ietf-gsmp-11 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3292
RFC3293 General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP) T. Worster A. Doria J. Buerkle June 2002 ASCII 18206 9

This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol). [STANDARDS-TRACK]

draft-ietf-gsmp-encaps-05 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3293
RFC3294 General Switch Management Protocol (GSMP) Applicability A. Doria K. Sundell June 2002 ASCII 18294 9 internet

This memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. This memo provides information for the Internet community.

draft-ietf-gsmp-applicability-02 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3294
RFC3295 Definitions of Managed Objects for the General Switch Management Protocol (GSMP) H. Sjostrand J. Buerkle B. Srinivasan June 2002 ASCII 95516 47 mib management information base controller gsmp-mib

This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). [STANDARDS-TRACK]

draft-ietf-gsmp-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3295
RFC3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories K. Zeilenga July 2002 ASCII 27389 14 schema elements description formats

This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS-TRACK]

draft-zeilenga-ldap-namedref-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3296
RFC3297 Content Negotiation for Messaging Services based on Email G. Klyne R. Iwazaki D. Crocker July 2002 ASCII 97094 46 facsimile

This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS-TRACK]

draft-ietf-fax-content-negotiation-05 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=3297 10.17487/RFC3297
RFC3298 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements I. Faynberg J. Gato H. Lu L. Slutsman August 2002 ASCII 36560 17 support

This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. This memo provides information for the Internet community.

draft-ietf-spirits-reqs-04 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC3298
RFC3299 Request for Comments Summary RFC Numbers 3200-3299 S. Ginoza December 2003 ASCII 63813 30 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3299 RFC3300 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza A. De La Cruz November 2002 ASCII 127805 49 RFC3000 RFC3600 HISTORIC INTERNET STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3300 10.17487/RFC3300 RFC3301 Layer Two Tunnelling Protocol (L2TP): ATM access network extensions Y. T'Joens P. Crivellari B. Sales June 2002 ASCII 42756 19 draft-ietf-l2tpext-atmext-04 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3301 RFC3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration G. Parsons J. Rafferty September 2002 ASCII 15183 8 TIFF Multipurpose Internet Mail extensions draft-ietf-fax-tiff-regbis-05 RFC2302 DRAFT STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC3302 RFC3303 Middlebox communication architecture and framework P. Srisuresh J. Kuthan J. Rosenberg A. Molitor A. Rayhan August 2002 ASCII 91209 34 midcom draft-ietf-midcom-framework-07 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC3303 RFC3304 Middlebox Communications (midcom) Protocol Requirements R. P. Swale P. A. Mart P. Sijben S. Brim M. Shore August 2002 ASCII 16187 9 nat network address protocol firewall middleboxes draft-ietf-midcom-requirements-05 INFORMATIONAL INFORMATIONAL IETF tsv midcom http://www.rfc-editor.org/errata_search.php?rfc=3304 10.17487/RFC3304 RFC3305 Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations M. Mealling Editor R. Denenberg Editor August 2002 ASCII 21793 11 internet engineering task force draft-mealling-uri-ig-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3305 10.17487/RFC3305 RFC3306 Unicast-Prefix-based IPv6 Multicast Addresses B. Haberman D. Thaler August 2002 ASCII 12713 7 internet protocol draft-ietf-ipngwg-uni-based-mcast-03 RFC3956 RFC4489 RFC7371 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3306 RFC3307 Allocation Guidelines for IPv6 Multicast Addresses B. Haberman August 2002 ASCII 15742 8 internet protocol draft-ietf-malloc-ipv6-guide-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC3307 RFC3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension P. Calhoun W. Luo D. McPherson K. Peirce November 2002 ASCII 21536 10 per hop behavior phb diffserv draft-ietf-l2tpext-ds-05 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3308 RFC3309 Stream Control Transmission Protocol (SCTP) Checksum Change J. Stone R. Stewart D. Otis September 2002 ASCII 34670 17 adler-32 checksum error detection draft-ietf-tsvwg-sctpcsum-07 RFC4960 RFC2960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3309 RFC3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) A. Niemi J. Arkko V. Torvinen September 2002 ASCII 36985 18 one-time password generation mechanism umts universal mobile telecommunications system draft-ietf-sip-digest-aka-03 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC3310 RFC3311 The Session Initiation Protocol (SIP) UPDATE Method J. Rosenberg October 2002 ASCII 28125 13 parameters media streams draft-ietf-sip-update-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3311 RFC3312 Integration of Resource Management and Session Initiation Protocol (SIP) G. Camarillo Editor W. Marshall Editor J. Rosenberg October 2002 ASCII 65757 30 PS 655218 PDF 130391 qos quality of service precondition draft-ietf-sip-manyfolks-resource-07 RFC4032 RFC5027 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3312 10.17487/RFC3312 RFC3313 Private Session Initiation Protocol (SIP) Extensions for Media Authorization W. Marshall Editor January 2003 ASCII 36866 16 qos quality of service draft-ietf-sip-call-auth-06 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC3313 RFC3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards M. Wasserman Editor September 2002 ASCII 48168 23 internet protocol draft-ietf-ipv6-3gpp-recommend-02 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3314 10.17487/RFC3314 RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms Editor J. Bound B. Volz T. Lemon C. Perkins M. Carney July 2003 ASCII 231402 101 internet protocol parameters addresses draft-ietf-dhc-dhcpv6-28 RFC4361 RFC5494 RFC6221 RFC6422 RFC6644 RFC7083 RFC7227 RFC7283 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3315 10.17487/RFC3315 RFC3316 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts J. Arkko G. Kuijpers H. Soliman J. Loughney J. Wiljakka April 2003 ASCII 48741 22 links bandwidth draft-ietf-ipv6-cellular-host-03 RFC7066 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3316 RFC3317 Differentiated Services Quality of Service Policy Information Base K. Chan R. Sahita S. Hahn K. McCloghrie March 2003 ASCII 188553 96 pib differentiated services architecture draft-ietf-diffserv-pib-08 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3317 RFC3318 Framework Policy Information Base R. Sahita Editor S. Hahn K. Chan K. McCloghrie March 2003 ASCII 144530 70 draft-ietf-rap-frameworkpib-09 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3318 RFC3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers H. Schulzrinne B. Volz July 2003 ASCII 14444 7 outbound proxy servers draft-ietf-sip-dhcpv6-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3319 RFC3320 Signaling Compression (SigComp) R. Price C. Bormann J. Christoffersson H. Hannu Z. Liu J. Rosenberg January 2003 ASCII 137035 62 sip session initiation protocol udvm universal decompressor virtual machine draft-ietf-rohc-sigcomp-07 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3320 RFC3321 Signaling Compression (SigComp) - Extended Operations H. Hannu J. Christoffersson S. Forsgren K.-C. Leung Z. Liu R. Price January 2003 ASCII 39433 19 sip session initiation protocol udvm universal decompressor virtual machine draft-ietf-rohc-sigcomp-extended-04 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3321 RFC3322 Signaling Compression (SigComp) Requirements & Assumptions H. Hannu January 2003 ASCII 27533 13 sip session initiation protocol wireless cellular sdp session description protocol draft-ietf-rohc-signaling-req-assump-06 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3322 RFC3323 A Privacy Mechanism for the Session Initiation Protocol (SIP) J. Peterson November 2002 ASCII 54116 22 privacy service draft-ietf-sip-privacy-general-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3323 RFC3324 Short Term Requirements for Network Asserted Identity M. Watson November 2002 ASCII 21964 11 session initiation protocol sip ua user agent draft-ietf-sipping-nai-reqs-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3324 RFC3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks C. Jennings J. Peterson M. Watson November 2002 ASCII 36170 18 trust domain draft-ietf-sip-asserted-identity-01 RFC5876 INFORMATIONAL INFORMATIONAL IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3325 10.17487/RFC3325 RFC3326 The Reason Header Field for the Session Initiation Protocol (SIP) H. Schulzrinne D. Oran G. Camarillo December 2002 ASCII 15695 8 heterogeneous error response forking problem herfp

The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS-TRACK]

draft-ietf-sip-reason-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3326
RFC3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts D. Willis B. Hoeneisen December 2002 ASCII 36493 17 3gpp register contact path registrar user agent ua draft-willis-sip-path-08 RFC5626 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3327 10.17487/RFC3327 RFC3328 RFC3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP) J. Arkko V. Torvinen G. Camarillo A. Niemi T. Haukka January 2003 ASCII 51503 24 ua user agent draft-ietf-sip-sec-agree-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3329 10.17487/RFC3329 RFC3330 Special-Use IPv4 Addresses IANA September 2002 ASCII 16200 7 internet protocol space assignments draft-iana-special-ipv4-05 RFC5735 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3330 10.17487/RFC3330 RFC3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer K. Morneault R. Dantu G. Sidebottom B. Bidulock J. Heitz September 2002 ASCII 210807 94 sctp stream control transmission protocol sg signaling gateway media gateway controller mgc draft-ietf-sigtran-m2ua-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=3331 10.17487/RFC3331 RFC3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) G. Sidebottom Editor K. Morneault Editor J. Pastor-Balbas Editor September 2002 ASCII 265055 120 isup sccp sctp stream control tranmission protocol mgc media gateway protocol st signalling gateway draft-ietf-sigtran-m3ua-12 RFC4666 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3332 RFC3334 Policy-Based Accounting T. Zseby S. Zander C. Carle October 2002 ASCII 103014 44 measurement metering meter configuration qos auditing aaa aaa architecture inter-domain accounting draft-irtf-aaaarch-pol-acct-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3334 RFC3335 MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet T. Harding R. Drummond C. Shih September 2002 ASCII 59687 29 multipurpose internet mail extensions edi draft-ietf-ediint-as1-17 PROPOSED STANDARD PROPOSED STANDARD IETF app ediint 10.17487/RFC3335 RFC3336 PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2) B. Thompson T. Koren B. Buffam December 2002 ASCII 33631 16 point-to-point protocol atm aal2 datagram packets draft-ietf-pppext-ppp-over-aal2-03 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3336 RFC3337 Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 B. Thompson T. Koren B. Buffam December 2002 ASCII 14911 7 point-to-point protocol atm aal2 encapsulation draft-ietf-pppext-ppp-over-aal2-class-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3337 RFC3338 Dual Stack Hosts Using "Bump-in-the-API" (BIA) S. Lee M-K. Shin Y-J. Kim E. Nordmark A. Durand October 2002 ASCII 34480 17 draft-ietf-ngtrans-bia-05 RFC6535 EXPERIMENTAL EXPERIMENTAL IETF ops ngtrans 10.17487/RFC3338 RFC3339 Date and Time on the Internet: Timestamps G. Klyne C. Newman July 2002 ASCII 35064 18 gregorian calendar iso draft-ietf-impp-datetime-05 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3339 10.17487/RFC3339 RFC3340 The Application Exchange Core M. Rose G. Klyne D. Crocker July 2002 ASCII 74266 40 APEX draft-ietf-apex-core-06 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3340 RFC3341 The Application Exchange (APEX) Access Service M. Rose G. Klyne D. Crocker July 2002 ASCII 46675 26 APEX draft-ietf-apex-access-08 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3341 RFC3342 The Application Exchange (APEX) Option Party Pack, Part Deux! E. Dixon H. Franklin J. Kint G. Klyne D. New S. Pead M. Rose M. Schwartz July 2002 ASCII 34300 22 datagram service core relaying mesh draft-ietf-apex-party-04 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3342 RFC3343 The Application Exchange (APEX) Presence Service M. Rose G. Klyne D. Crocker April 2003 ASCII 42043 23 endpoint draft-ietf-apex-presence-06 HISTORIC EXPERIMENTAL IETF app apex 10.17487/RFC3343 RFC3344 IP Mobility Support for IPv4 C. Perkins Editor August 2002 ASCII 241041 99 MOBILEIPSUPIP Internet Protocol RFC3220 RFC5944 RFC4636 RFC4721 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3344 10.17487/RFC3344 RFC3345 Border Gateway Protocol (BGP) Persistent Route Oscillation Condition D. McPherson V. Gill D. Walton A. Retana August 2002 ASCII 38137 19 idr ibgp draft-ietf-idr-route-oscillation-01 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=3345 10.17487/RFC3345 RFC3346 Applicability Statement for Traffic Engineering with MPLS J. Boyle V. Gill A. Hannan D. Cooper D. Awduche B. Christian W.S. Lai August 2002 ASCII 33754 14 multiprotocol label switching te draft-ietf-tewg-te-applicability-01 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3346 RFC3347 Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations M. Krueger R. Haagens July 2002 ASCII 58097 26 scsi tcp. storage fibre channel draft-ietf-ips-iscsi-reqmts-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3347 RFC3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension M. Gahrns R. Cheng July 2002 ASCII 11868 6 children draft-gahrns-imap-child-mailbox-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3348 10.17487/RFC3348 RFC3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force M. Rose July 2002 ASCII 7916 6 beep draft-mrose-beep-transientid-02 BCP0059 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3349 RFC3351 User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals N. Charlton M. Gasson G. Gybels M. Spanner A. van Wijk August 2002 ASCII 33894 17 relay service transcoding service textphone draft-ietf-sipping-deaf-req-03 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3351 RFC3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status K. Zeilenga March 2003 ASCII 7265 4 CLDAP CLDAP Presentation Address Application Entity Title draft-zeilenga-cldap-02 RFC1798 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3352 RFC3353 Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment D. Ooms B. Sales W. Livens A. Acharya F. Griffoul F. Ansari August 2002 ASCII 65860 30 inrternet protocol l2 multicast routing protocoln draft-ietf-mpls-multicast-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3353 RFC3354 Internet Open Trading Protocol Version 2 Requirements D. Eastlake 3rd August 2002 ASCII 9671 6 payment ecommerce merchant customer delivery signature messaging commerce sale draft-ietf-trade-iotp2-req-02 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3354 RFC3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) A. Singh R. Turner R. Tio S. Nanji August 2002 ASCII 25114 13 link dial-up server asynchronous transfer mode draft-ietf-l2tpext-l2tp-atm-03 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3355 RFC3356 Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines G. Fishman S. Bradner August 2002 ASCII 27149 12 internet society engineering task force draft-fishman-2436bis-02 RFC2436 RFC6756 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3356 RFC3357 One-way Loss Pattern Sample Metrics R. Koodli R. Ravikanth August 2002 ASCII 30570 15 packets voice video stream draft-ietf-ippm-loss-pattern-07 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3357 RFC3358 Optional Checksums in Intermediate System to Intermediate System (ISIS) T. Przygienda August 2002 ASCII 8266 4 type length value complete sequence number partial data draft-ietf-isis-wg-snp-checksum-03 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3358 RFC3359 Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System T. Przygienda August 2002 ASCII 7843 5 is-is igp osi complete sequence number partial data draft-ietf-isis-wg-tlv-codepoints-01 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=3359 10.17487/RFC3359 RFC3360 Inappropriate TCP Resets Considered Harmful S. Floyd August 2002 ASCII 46748 19 transmission control protocol rst bit connection draft-floyd-tcp-reset-04 BCP0060 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3360 RFC3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers H. Schulzrinne August 2002 ASCII 12549 7 proxy servers draft-ietf-sip-dhcp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3361 RFC3362 Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration G. Parsons August 2002 ASCII 8301 5 draft-parsons-itu-t38-reg-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3362 RFC3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) R. Bush A. Durand B. Fink O. Gudmundsson T. Hain August 2002 ASCII 11055 6 reverse mapping label binary draft-ietf-dnsext-ipv6-addresses-02 RFC2673 RFC2874 RFC6672 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3363 10.17487/RFC3363 RFC3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) R. Austein August 2002 ASCII 26544 11 reverse mapping rrs resource records draft-ietf-dnsext-ipv6-dns-tradeoffs-02 RFC2673 RFC2874 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3364 10.17487/RFC3364 RFC3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols J. Schiller August 2002 ASCII 16411 8 ietf draft-ietf-saag-whyenc-00 BCP0061 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3365 RFC3366 Advice to link designers on link Automatic Repeat reQuest (ARQ) G. Fairhurst L. Wood August 2002 ASCII 66097 27 tcp/ip subnetworks draft-ietf-pilc-link-arq-issues-04 BCP0062 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3366 RFC3367 Common Name Resolution Protocol (CNRP) N. Popp M. Mealling M. Moseley August 2002 ASCII 86889 42 unique resource locators client applications draft-ietf-cnrp-12 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3367 RFC3368 The 'go' URI Scheme for the Common Name Resolution Protocol M. Mealling August 2002 ASCII 12726 8 uniform resource identifier draft-ietf-cnrp-uri-07 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3368 RFC3369 Cryptographic Message Syntax (CMS) R. Housley August 2002 ASCII 113975 52 digitally sign authenticate encrypt arbitrary message content draft-ietf-smime-rfc2630bis-08 RFC2630 RFC3211 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3369 10.17487/RFC3369 RFC3370 Cryptographic Message Syntax (CMS) Algorithms R. Housley August 2002 ASCII 51001 24 digitally sign authenticate encrypt arbitrary message content draft-ietf-smime-cmsalg-08 RFC2630 RFC3211 RFC5754 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3370 10.17487/RFC3370 RFC3371 Layer Two Tunneling Protocol "L2TP" Management Information Base E. Caves P. Calhoun R. Wheeler August 2002 ASCII 139974 70 mib draft-ietf-l2tpext-l2tp-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3371 RFC3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures A. Vemuri J. Peterson September 2002 ASCII 49893 23 pstn public switch telephone network draft-ietf-sipping-sipt-04 BCP0063 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3372 10.17487/RFC3372 RFC3373 Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies D. Katz R. Saluja September 2002 ASCII 19522 9 links handshake draft-ietf-isis-3way-06 RFC5303 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3373 RFC3374 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network J. Kempf Editor September 2002 ASCII 28245 14 aaa qos authentication authorization accounting quality of service header compression draft-ietf-seamoby-context-transfer-problem-stat-04 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3374 RFC3375 Generic Registry-Registrar Protocol Requirements S. Hollenbeck September 2002 ASCII 46022 21 rrp client server domain names draft-ietf-provreg-grrp-reqs-06 INFORMATIONAL INFORMATIONAL IETF app provreg 10.17487/RFC3375 RFC3376 Internet Group Management Protocol, Version 3 B. Cain S. Deering I. Kouvelas B. Fenner A. Thyagarajan October 2002 ASCII 119726 53 IGMP IGMP multicast routing IP Internet Protocol draft-ietf-idmr-igmp-v3-11 RFC2236 RFC4604 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=3376 10.17487/RFC3376 RFC3377 Lightweight Directory Access Protocol (v3): Technical Specification J. Hodges R. Morgan September 2002 ASCII 9981 6 ldap ldapv3 draft-ietf-ldapbis-ldapv3-ts-01 RFC4510 RFC2251 RFC2252 RFC2253 RFC2254 RFC2255 RFC2256 RFC2829 RFC2830 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=3377 10.17487/RFC3377 RFC3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams R. Housley S. Hollenbeck September 2002 ASCII 18803 9 internet protocol ip 97 draft-housley-etherip-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3378 RFC3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements D. Pinkas R. Housley September 2002 ASCII 32455 15 dpv dpd public key certificates draft-ietf-pkix-dpv-dpd-req-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3379 RFC3380 Internet Printing Protocol (IPP): Job and Printer Set Operations T. Hastings R. Herriot C. Kugler H. Lewis September 2002 ASCII 132044 59 IPP-E-T IPP application media-type media type draft-ietf-ipp-job-printer-set-ops-05 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3380 RFC3381 Internet Printing Protocol (IPP): Job Progress Attributes T. Hastings H. Lewis R. Bergman September 2002 ASCII 36595 17 IPP-E-T IPP application media-type media type draft-ietf-ipp-job-prog-02 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3381 10.17487/RFC3381 RFC3382 Internet Printing Protocol (IPP): The 'collection' attribute syntax R. deBry T. Hastings R. Herriot K. Ocke P. Zehler September 2002 ASCII 78173 38 IPP-E-T IPP application media-type media type draft-ietf-ipp-collection-05 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3382 10.17487/RFC3382 RFC3383 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) K. Zeilenga September 2002 ASCII 45893 23 guidelines extensible values draft-ietf-ldapbis-iana-09 RFC4520 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ldapbis 10.17487/RFC3383 RFC3384 Lightweight Directory Access Protocol (version 3) Replication Requirements E. Stokes R. Weiser R. Moats R. Huber October 2002 ASCII 66871 31 ldapv3 data interoperability synchronization multi-master draft-ietf-ldup-replica-req-12 INFORMATIONAL INFORMATIONAL IETF app ldup 10.17487/RFC3384 RFC3385 Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations D. Sheinwald J. Satran P. Thaler V. Cavanna September 2002 ASCII 53450 23 error detection code draft-sheinwald-iscsi-crc-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3385 10.17487/RFC3385 RFC3386 Network Hierarchy and Multilayer Survivability W. Lai Editor D. McDysan Editor November 2002 ASCII 65345 27 service provider packet networks protection restoration recovery draft-ietf-tewg-restore-hierarchy-01 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3386 RFC3387 Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network M. Eder H. Chaskar S. Nag September 2002 ASCII 52693 19 internet protocol packts fuel-service draft-irtf-smrg-ipsmf-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3387 RFC3388 Grouping of Media Lines in the Session Description Protocol (SDP) G. Camarillo G. Eriksson J. Holler H. Schulzrinne December 2002 ASCII 39365 11 formats attribute port host interfaces fid flow identification lip synchronization ls draft-ietf-mmusic-fid-06 RFC5888 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3388 RFC3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN) R. Zopf September 2002 ASCII 17018 8 codecs audio multimedia draft-ietf-avt-rtp-cn-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3389 10.17487/RFC3389 RFC3390 Increasing TCP's Initial Window M. Allman S. Floyd C. Partridge October 2002 ASCII 36177 15 transmission control protocol draft-ietf-tsvwg-initwin-04 RFC2414 RFC2581 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3390 RFC3391 The MIME Application/Vnd.pwg-multiplexed Content-Type R. Herriot December 2002 ASCII 54739 25 multipurpose internet mail extensions media type draft-herriot-application-multiplexed-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3391 RFC3392 Capabilities Advertisement with BGP-4 R. Chandra J. Scudder November 2002 ASCII 9885 6 border gateway protocol draft-ietf-idr-rfc2842bis-02 RFC2842 RFC5492 DRAFT STANDARD DRAFT STANDARD IETF rtg idr 10.17487/RFC3392 RFC3393 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) C. Demichelis P. Chimento November 2002 ASCII 47731 21 internet protocol ipdv draft-ietf-ippm-ipdv-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC3393 RFC3394 Advanced Encryption Standard (AES) Key Wrap Algorithm J. Schaad R. Housley September 2002 ASCII 73072 41 security draft-ietf-smime-aes-keywrap-00 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3394 10.17487/RFC3394 RFC3395 Remote Network Monitoring MIB Protocol Identifier Reference Extensions A. Bierman C. Bucci R. Dietz A. Warth September 2002 ASCII 43862 21 RMON-MIB management information base draft-ietf-rmonmib-appverbs-04 RFC2895 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3395 RFC3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) T. Lemon S. Cheshire November 2002 ASCII 18779 9 octet packet code draft-ietf-dhc-concat-05 RFC2131 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3396 RFC3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option B. Aboba S. Cheshire November 2002 ASCII 15446 8 dns client client server draft-aboba-dhc-domsearch-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3397 RFC3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping G. Camarillo A. B. Roach J. Peterson L. Ong December 2002 ASCII 166197 68 signaling system no. 7 ss7 pstn public switched telephone network draft-ietf-sipping-isup-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3398 10.17487/RFC3398 RFC3400 RFC3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS M. Mealling October 2002 ASCII 10172 6 NAPTR domain name system RR

This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community.

draft-ietf-urn-ddds-toc-03 RFC2915 RFC2168 RFC2276 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3401 10.17487/RFC3401
RFC3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm M. Mealling October 2002 ASCII 38925 17 NAPTR domain name system RR

This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

draft-ietf-urn-ddds-07 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn 10.17487/RFC3402
RFC3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database M. Mealling October 2002 ASCII 31058 14 NAPTR domain name system RR

This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

draft-ietf-urn-dns-ddds-database-09 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3403 10.17487/RFC3403
RFC3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) M. Mealling October 2002 ASCII 40124 18 NAPTR domain name system RR

This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

draft-ietf-urn-uri-res-ddds-07 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3404 10.17487/RFC3404
RFC3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures M. Mealling October 2002 ASCII 19469 10 uniform resource identifiers

This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-urn-net-procedures-11 BCP0065 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3405 10.17487/RFC3405
RFC3406 Uniform Resource Names (URN) Namespace Definition Mechanisms L. Daigle D. van Gulik R. Iannella P. Faltstrom October 2002 ASCII 43707 22 namespaces applications structure

This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-urn-rfc2611bis-04 RFC2611 BCP0066 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3406 10.17487/RFC3406
RFC3407 Session Description Protocol (SDP) Simple Capability Declaration F. Andreasen October 2002 ASCII 21133 10 SDPng

This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. [STANDARDS-TRACK]

draft-andreasen-mmusic-sdp-simcap-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3407 10.17487/RFC3407
RFC3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile Z. Liu K. Le December 2002 ASCII 14805 7 single-octet packet size

This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. [STANDARDS-TRACK]

draft-ietf-rohc-rtp-lla-r-mode-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3408
RFC3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression K. Svanbro December 2002 ASCII 25815 11 rohc algorithms

This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. This memo provides information for the Internet community.

draft-ietf-rohc-rtp-lower-layer-guidelines-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3409
RFC3410 Introduction and Applicability Statements for Internet-Standard Management Framework J. Case R. Mundy D. Partain B. Stewart December 2002 ASCII 61461 27 snmp simple protocol snmpv3

The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.

draft-ietf-snmpv3-rfc2570bis-03 RFC2570 INFORMATIONAL INFORMATIONAL IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3410 10.17487/RFC3410
RFC3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks D. Harrington R. Presuhn B. Wijnen December 2002 ASCII 140096 64 ARCH-SNMP simple protocol network management

This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]

draft-ietf-snmpv3-arch-v2-02 RFC2571 RFC5343 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3411
RFC3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen December 2002 ASCII 95710 43 MPD-SNMP processing models multiple

This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. [STANDARDS-TRACK]

draft-ietf-snmpv3-mpd-v2-02 RFC2572 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3412
RFC3413 Simple Network Management Protocol (SNMP) Applications D. Levi P. Meyer B. Stewart December 2002 ASCII 153719 74 SNMP-APP simple network management protocol proxy operations command

This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. [STANDARDS-TRACK]

draft-ietf-snmpv3-appl-v3-01 RFC2573 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3413 10.17487/RFC3413
RFC3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen December 2002 ASCII 193558 88 USM-SNMPV3 message level mib information base

This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS-TRACK]

draft-ietf-snmpv3-usm-v2-rfc2574bis-01 RFC2574 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3414 10.17487/RFC3414
RFC3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie December 2002 ASCII 82046 39 VACM-SNMP mib information base

This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View- based Access Control Model. This document obsoletes RFC 2575. [STANDARDS-TRACK]

draft-ietf-snmpv3-vacm-v2-01 RFC2575 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3415 10.17487/RFC3415
RFC3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII 70043 31 OPS-MIB Simple Network Management Protocol Version 2

This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905. [STANDARDS-TRACK]

draft-ietf-snmpv3-update-proto-08 RFC1905 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3416 10.17487/RFC3416
RFC3417 Transport Mappings for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII 38650 19 TRANS-MIB Simple Network Management Protocol Version 2

This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. [STANDARDS-TRACK]

draft-ietf-snmpv3-update-transmap-08 RFC1906 RFC4789 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3417
RFC3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII 49096 26 SNMPv2-MIB Simple Network Management Protocol Version 2

This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]

draft-ietf-snmpv3-update-mib-07 RFC1907 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3418 10.17487/RFC3418
RFC3419 Textual Conventions for Transport Addresses M. Daniele J. Schoenwaelder December 2002 ASCII 37466 18 mib management information base

This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS-TRACK]

draft-ietf-ops-taddress-mib-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3419
RFC3420 Internet Media Type message/sipfrag R. Sparks November 2002 ASCII 14745 8 mime multipurpose internet mail extesions

This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. [STANDARDS-TRACK]

draft-ietf-sip-sipfrag-00 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3420 10.17487/RFC3420
RFC3421 Select and Sort Extensions for the Service Location Protocol (SLP) W. Zhao H. Schulzrinne E. Guttman C. Bisdikian W. Jerome November 2002 ASCII 15260 8 user agent url service reply ua svrrply

This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. This memo defines an Experimental Protocol for the Internet community.

draft-zhao-slp-customization-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3421
RFC3422 Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS) O. Okamoto M. Maruyama T. Sajima November 2002 ASCII 37576 19 tunneling ethernet frames

This memo describes a method for forwarding media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network (LAN) environment. This memo provides information for the Internet community.

draft-okamoto-mac-over-mapos-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3422
RFC3423 XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0 K. Zhang E. Elkin November 2002 ASCII 97731 45 data delivery message format template-based client/server

This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources. This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. This memo provides information for the Internet community.

draft-kzhang-crane-protocol-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3423
RFC3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation L. Daigle Editor IAB November 2002 ASCII 18165 9 nat middleboxes

As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community.

draft-iab-unsaf-considerations-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3424 10.17487/RFC3424
RFC3425 Obsoleting IQUERY D. Lawrence November 2002 ASCII 8615 5 dns lookups domain

The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS-TRACK]

draft-ietf-dnsext-obsolete-iquery-04 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3425
RFC3426 General Architectural and Policy Considerations S. Floyd November 2002 ASCII 54868 23 internet architecture

This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. This memo provides information for the Internet community.

draft-iab-considerations-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3426
RFC3427 Change Process for the Session Initiation Protocol (SIP) A. Mankin S. Bradner R. Mahy D. Willis J. Ott B. Rosen December 2002 ASCII 26234 12 sipping

This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-tsvarea-sipchange-03 RFC5727 RFC3968 RFC3969 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3427
RFC3428 Session Initiation Protocol (SIP) Extension for Instant Messaging B. Campbell Editor J. Rosenberg H. Schulzrinne C. Huitema D. Gurle December 2002 ASCII 41475 18 im message method

Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS-TRACK]

draft-ietf-sip-message-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3428 10.17487/RFC3428
RFC3429 Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions H. Ohta November 2002 ASCII 10903 6 reserved lavel values

This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. This memo provides information for the Internet community.

draft-ohta-mpls-label-value-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3429
RFC3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping J. Schoenwaelder December 2002 ASCII 21527 10 snmp tcp

This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-nmrg-snmp-tcp-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3430
RFC3431 Sieve Extension: Relational Tests W. Segmuller December 2002 ASCII 12849 8 sieve mail filtering language

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. [STANDARDS-TRACK]

draft-segmuller-sieve-relation-02 RFC5231 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3431
RFC3432 Network performance measurement with periodic streams V. Raisanen G. Grotefeld A. Morton November 2002 ASCII 52493 23 cbr constant bit rate periodic sampling poisson sampling

This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS-TRACK]

draft-ietf-ippm-npmps-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC3432
RFC3433 Entity Sensor Management Information Base A. Bierman D. Romascanu K.C. Norseth December 2002 ASCII 31857 17 mib physical sensors snmp

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). [STANDARDS-TRACK]

draft-ietf-entmib-sensor-mib-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=3433 10.17487/RFC3433
RFC3434 Remote Monitoring MIB Extensions for High Capacity Alarms A. Bierman K. McCloghrie December 2002 ASCII 51072 24 rmon counter64 smiv2 snmp

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. [STANDARDS-TRACK]

draft-ietf-rmonmib-hc-alarm-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3434
RFC3435 Media Gateway Control Protocol (MGCP) Version 1.0 F. Andreasen B. Foster January 2003 ASCII 467084 210 voice IP internet VoIP

This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control "intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP. Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints. The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. This memo provides information for the Internet community.

draft-andreasen-mgcp-rfc2705bis-05 RFC2705 RFC3661 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3435 10.17487/RFC3435
RFC3436 Transport Layer Security over Stream Control Transmission Protocol A. Jungmaier E. Rescorla M. Tuexen December 2002 ASCII 16333 9 sctp tls

This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS-TRACK]

draft-ietf-tsvwg-tls-over-sctp-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3436
RFC3437 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation W. Palter W. Townsley December 2002 ASCII 20820 10 l2tp lcp

This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS-TRACK]

draft-ietf-l2tpext-link-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3437
RFC3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update W. Townsley December 2002 ASCII 9135 5 L2TP ppp point-to-point protocol packets

This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-l2tpext-rfc2661-iana-01 BCP0068 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int l2tpext 10.17487/RFC3438
RFC3439 Some Internet Architectural Guidelines and Philosophy R. Bush D. Meyer December 2002 ASCII 70333 28 IAB

This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. This memo provides information for the Internet community.

draft-ymbk-arch-guidelines-03 RFC1958 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3439 10.17487/RFC3439
RFC3440 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines F. Ly G. Bathrick December 2002 ASCII 76058 36 simple network management protocol mib adsl asymmetric digital subscriber line

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). [STANDARDS-TRACK]

draft-ietf-adslmib-adslext-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3440
RFC3441 Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP) R. Kumar January 2003 ASCII 122455 50 connection codec profile

This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. This memo provides information for the Internet community.

draft-rajeshkumar-mgcp-atm-package-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3441
RFC3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 T. Lemon S. Cheshire B. Volz December 2002 ASCII 19370 9 Dynamic Host Configuration Protocol Bootstrap

This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS-TRACK]

draft-ietf-dhc-csr-07 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3442
RFC3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks P. Agarwal B. Akyol January 2003 ASCII 18749 10 label stack encoding uniform model pipe model

This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. [STANDARDS-TRACK]

draft-ietf-mpls-ttl-04 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3443
RFC3444 On the Difference between Information Models and Data Models A. Pras J. Schoenwaelder January 2003 ASCII 18596 8 network management

There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.

draft-irtf-nmrg-im-dm-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3444
RFC3445 Limiting the Scope of the KEY Resource Record (RR) D. Massey S. Rose December 2002 ASCII 20947 10 DNS-SECEXT dns authentication

This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. [STANDARDS-TRACK]

draft-ietf-dnsext-restrict-key-for-dnssec-04 RFC4033 RFC4034 RFC4035 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3445 10.17487/RFC3445
RFC3446 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) D. Kim D. Meyer H. Kilmer D. Farinacci January 2003 ASCII 14792 7 sparse mode single shared-tree

This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community.

draft-ietf-mboned-anycast-rp-08 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3446
RFC3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 J. Jonsson B. Kaliski February 2003 ASCII 143173 72 data public key cryptosystem

This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.

draft-jonsson-pkcs1-v2dot1-00 RFC2437 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3447 10.17487/RFC3447
RFC3448 TCP Friendly Rate Control (TFRC): Protocol Specification M. Handley S. Floyd J. Padhye J. Widmer January 2003 ASCII 52657 24 congestion unicast streaming media

This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS-TRACK]

draft-ietf-tsvwg-tfrc-05 RFC5348 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3448 10.17487/RFC3448
RFC3449 TCP Performance Implications of Network Path Asymmetry H. Balakrishnan V. Padmanabhan G. Fairhurst M. Sooriyabandara December 2002 ASCII 108839 41 links sender receiver ack

This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self- clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-asym-08 BCP0069 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3449
RFC3450 Asynchronous Layered Coding (ALC) Protocol Instantiation M. Luby J. Gemmell L. Vicisano L. Rizzo J. Crowcroft December 2002 ASCII 86022 34 content delivery congestion control receivers

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-pi-alc-08 RFC5775 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3450
RFC3451 Layered Coding Transport (LCT) Building Block M. Luby J. Gemmell L. Vicisano L. Rizzo M. Handley J. Crowcroft December 2002 ASCII 72594 29 content stream delivery multicast internet protocol

Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-lct-04 RFC5651 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3451
RFC3452 Forward Error Correction (FEC) Building Block M. Luby L. Vicisano J. Gemmell L. Rizzo M. Handley J. Crowcroft December 2002 ASCII 38368 16 content stream delivery multicast internet protocol

This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast". This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-fec-07 RFC5052 RFC5445 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3452
RFC3453 The Use of Forward Error Correction (FEC) in Reliable Multicast M. Luby L. Vicisano J. Gemmell L. Rizzo M. Handley J. Crowcroft December 2002 ASCII 46853 18 ip internet protocol data transport

This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. This memo provides information for the Internet community.

draft-ietf-rmt-info-fec-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3453
RFC3454 Preparation of Internationalized Strings ("stringprep") P. Hoffman M. Blanchet December 2002 ASCII 138684 91 unicode text internationalization

This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS-TRACK]

draft-hoffman-stringprep-07 RFC7564 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3454 10.17487/RFC3454
RFC3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) M. Garcia-Martin E. Henrikson D. Mills January 2003 ASCII 79620 34

This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community.

draft-garcia-sipping-3gpp-p-headers-02 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3455 10.17487/RFC3455
RFC3456 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode B. Patel B. Aboba S. Kelly V. Gupta January 2003 ASCII 40340 18 security internet protocol

This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, DHCP provides for such remote host configuration. [STANDARDS-TRACK]

draft-ietf-ipsec-dhcp-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsra 10.17487/RFC3456
RFC3457 Requirements for IPsec Remote Access Scenarios S. Kelly S. Ramamoorthi January 2003 ASCII 75167 31 ipsra common remote access scenarios

IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. This memo provides information for the Internet community.

draft-ietf-ipsra-reqmts-05 INFORMATIONAL INFORMATIONAL IETF sec ipsra 10.17487/RFC3457
RFC3458 Message Context for Internet Mail E. Burger E. Candell C. Eliot G. Klyne January 2003 ASCII 34181 17 user agent ua

This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]

draft-ietf-vpim-hint-08 RFC3938 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3458
RFC3459 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter E. Burger January 2003 ASCII 54282 24 body parts content-disposition

This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204. By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. [STANDARDS-TRACK]

draft-ietf-vpim-cc-08 RFC3204 RFC5621 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3459
RFC3460 Policy Core Information Model (PCIM) Extensions B. Moore Editor January 2003 ASCII 212453 93 CIM common schema object-oriented

This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. [STANDARDS-TRACK]

draft-ietf-policy-pcim-ext-08 RFC3060 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3460
RFC3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) K. Moore January 2003 ASCII 76076 38 SMTP-DSN simple mail transfer protocol

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

draft-moore-rfc1891bis-02 RFC1891 RFC3798 RFC3885 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3461 10.17487/RFC3461
RFC3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages G. Vaudreuil January 2003 ASCII 12186 7 MIME-RPT Multipurpose Internet Mail Extensions

The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. [STANDARDS-TRACK]

draft-vaudreuil-1892bis-02 RFC1892 RFC6522 RFC5337 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3462
RFC3463 Enhanced Mail System Status Codes G. Vaudreuil January 2003 ASCII 31832 16 EMS-CODE simple mail transfer protocol SMTP

This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS-TRACK]

draft-vaudreuil-1893bis-03 RFC1893 RFC3886 RFC4468 RFC4865 RFC4954 RFC5248 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3463 10.17487/RFC3463
RFC3464 An Extensible Message Format for Delivery Status Notifications K. Moore G. Vaudreuil January 2003 ASCII 83060 40 DSN Multipurpose Internet Mail Extensions Content Type

This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. [STANDARDS-TRACK]

draft-vaudreuil-1894bis-02 RFC1894 RFC4865 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3464 10.17487/RFC3464
RFC3465 TCP Congestion Control with Appropriate Byte Counting (ABC) M. Allman February 2003 ASCII 23486 10 transmission control protocol security performance

This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. This memo defines an Experimental Protocol for the Internet community.

draft-allman-tcp-abc-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3465
RFC3466 A Model for Content Internetworking (CDI) M. Day B. Cain G. Tomlinson P. Rzewski February 2003 ASCII 37684 17 distribution peering

Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called "content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. This memo provides information for the Internet community.

draft-ietf-cdi-model-02 RFC7336 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3466
RFC3467 Role of the Domain Name System (DNS) J. Klensin February 2003 ASCII 84570 31 history internationalization unicode ascii multilingual names

This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. This memo provides information for the Internet community.

draft-klensin-dns-role-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3467
RFC3468 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols L. Andersson G. Swallow February 2003 ASCII 22072 11 rsvp-te ldp resource reservation protocol label distribution

This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label- Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. This memo provides information for the Internet community.

draft-andersson-mpls-sig-decision-03 RFC3212 RFC3472 RFC3475 RFC3476 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3468 10.17487/RFC3468
RFC3469 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery V. Sharma Editor F. Hellstrand Editor February 2003 ASCII 89331 40 routing traffic

Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. This memo provides information for the Internet community.

draft-ietf-mpls-recovery-frmwrk-08 RFC5462 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3469
RFC3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols S. Hollenbeck M. Rose L. Masinter January 2003 ASCII 64252 28 data documents structure

The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hollenbeck-ietf-xml-guidelines-07 BCP0070 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3470 10.17487/RFC3470
RFC3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description L. Berger Editor January 2003 ASCII 72105 34 mpls sonet/sdh

This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]

draft-ietf-mpls-generalized-signaling-09 RFC4201 RFC4328 RFC4872 RFC6002 RFC6003 RFC6205 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3471 10.17487/RFC3471
RFC3472 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions P. Ashwood-Smith Editor L. Berger Editor January 2003 ASCII 49006 23 mpls sonet/sdh

This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]

draft-ietf-mpls-generalized-cr-ldp-07 RFC3468 RFC4201 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC3472
RFC3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions L. Berger Editor January 2003 ASCII 91808 42 mpls sonet/sdh

This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]

draft-ietf-mpls-generalized-rsvp-te-09 RFC4003 RFC4201 RFC4420 RFC4783 RFC4874 RFC4873 RFC4974 RFC5063 RFC5151 RFC5420 RFC6002 RFC6003 RFC6780 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3473 10.17487/RFC3473
RFC3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON) Z. Lin D. Pendarakis March 2003 ASCII 52551 25 sonet sdh

The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. This memo provides information for the Internet community.

draft-lin-ccamp-gmpls-ason-rsvpte-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3474
RFC3475 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON) O. Aboul-Magd March 2003 ASCII 29995 13 label switching protocol itu-t

Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. This memo provides information for the Internet community.

draft-aboulmagd-ccamp-crldp-ason-ext-02 RFC3468 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3475
RFC3476 Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling B. Rajagopalan March 2003 ASCII 22009 11 oif optical interworking forum uni user network interface

The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling. These extensions consist of a set of new data objects and error codes. This document describes these extensions. This memo provides information for the Internet community.

draft-bala-uni-ldp-rsvp-extensions-04 RFC3468 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3476
RFC3477 Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) K. Kompella Y. Rekhter January 2003 ASCII 19899 9 mpls-te traffic engineering

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-unnum-08 RFC6107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3477
RFC3478 Graceful Restart Mechanism for Label Distribution Protocol M. Leelanivas Y. Rekhter R. Aggarwal February 2003 ASCII 29248 12 ldp mpls

This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-restart-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3478
RFC3479 Fault Tolerance for the Label Distribution Protocol (LDP) A. Farrel Editor February 2003 ASCII 115778 52 mpls multiprotocol label switching cr-ldp high availability restart

Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDS-TRACK]

draft-ietf-mpls-ldp-ft-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3479
RFC3480 Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) K. Kompella Y. Rekhter A. Kullberg February 2003 ASCII 17076 8 mpls multiprotocol label switching traffic engineering mpls-te

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3480
RFC3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks H. Inamura Editor G. Montenegro Editor R. Ludwig A. Gurtov F. Khafizov February 2003 ASCII 61528 26 paths algorithm stacks

This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-2.5g3g-12 BCP0071 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3481
RFC3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview M. Foster T. McGarry J. Yu February 2003 ASCII 78552 30 e.164 telephony routing

This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. This memo provides information for the Internet community.

draft-ietf-enum-e164-gstn-np-05 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC3482
RFC3483 Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR) D. Rawlins A. Kulkarni M. Bokaemper K. Chan March 2003 ASCII 19869 10 accounting policy decision point bdp

Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point (PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. This memo provides information for the Internet community.

draft-ietf-rap-feedback-frwk-04 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3483
RFC3484 Default Address Selection for Internet Protocol version 6 (IPv6) R. Draves February 2003 ASCII 55076 24 source address destination

This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS-TRACK]

draft-ietf-ipv6-default-addr-select-09 RFC6724 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3484
RFC3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) M. Garcia-Martin C. Bormann J. Ott R. Price A. B. Roach February 2003 ASCII 80195 30 algorithm

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS-TRACK]

draft-ietf-sipping-sigcomp-sip-dictionary-05 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3485
RFC3486 Compressing the Session Initiation Protocol (SIP) G. Camarillo February 2003 ASCII 24181 12

This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. [STANDARDS-TRACK]

draft-ietf-sip-compression-02 RFC5049 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3486
RFC3487 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) H. Schulzrinne February 2003 ASCII 39615 17 circuit switched network resources end system resources proxy resources emergency preparedness communications

This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). This memo provides information for the Internet community.

draft-ietf-ieprep-sip-reqs-03 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3487
RFC3488 Cisco Systems Router-port Group Management Protocol (RGMP) I. Wu T. Eckert February 2003 ASCII 37152 17 multicast switches packet

This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. This memo provides information for the Internet community.

draft-wu-rgmp-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3488
RFC3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) J. Rosenberg J. Weinberger C. Huitema R. Mahy March 2003 ASCII 117562 47 lightweight applications firewalls

Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS-TRACK]

draft-ietf-midcom-stun-05 RFC5389 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC3489
RFC3490 Internationalizing Domain Names in Applications (IDNA) P. Faltstrom P. Hoffman A. Costello March 2003 ASCII 51943 22 idn ascii characters

Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]

draft-ietf-idn-idna-14 RFC5890 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn http://www.rfc-editor.org/errata_search.php?rfc=3490 10.17487/RFC3490
RFC3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) P. Hoffman M. Blanchet March 2003 ASCII 10316 7 idna applications

This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS-TRACK]

draft-ietf-idn-nameprep-11 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn 10.17487/RFC3491
RFC3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) A. Costello March 2003 ASCII 67439 35 syntax string host label

Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]

draft-ietf-idn-punycode-03 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn http://www.rfc-editor.org/errata_search.php?rfc=3492 10.17487/RFC3492
RFC3493 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound J. McCann W. Stevens February 2003 ASCII 82570 39 internet protocol api application program interface tcp transmission control

The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community.

RFC2553 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3493
RFC3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status K. Zeilenga March 2003 ASCII 9225 5 DAP interactive access X.500 LDAP lightweight directory protocol STR-REP directory names representing names

This document recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. This memo provides information for the Internet community.

draft-zeilenga-ldapv2-04 RFC1484 RFC1485 RFC1487 RFC1777 RFC1778 RFC1779 RFC1781 RFC2559 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3494 10.17487/RFC3494
RFC3495 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration B. Beser P. Duffy Editor March 2003 ASCII 26817 13 packetcable media terminal adapter mta

This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. [STANDARDS-TRACK]

draft-ietf-dhc-packetcable-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3495 10.17487/RFC3495
RFC3496 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering A. G. Malis T. Hsiao March 2003 ASCII 11431 6 diff-serv diffserv rsvp-te resource reservation protocol

This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. This memo provides information for the Internet community.

draft-malis-diff-te-serviceclass-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3496
RFC3497 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video L. Gharai C. Perkins G. Goncher A. Mankin March 2003 ASCII 26094 12 real-time transport protocol hdtv high definition television

This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS-TRACK]

draft-ietf-avt-smpte292-video-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3497
RFC3498 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures J. Kuhfeld J. Johnson M. Thatcher March 2003 ASCII 78701 43 mib management information base tcp/ip transmission control protocol internet protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. [STANDARDS-TRACK]

draft-ietf-atommib-sonetaps-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3498
RFC3499 Request for Comments Summary RFC Numbers 3400-3499 S. Ginoza December 2003 ASCII 88033 38 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3499 RFC3500 RFC3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 M. Crispin March 2003 ASCII 227640 108 IMAPv4 imap imapv4rev1

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]

draft-crispin-imapv-20 RFC2060 RFC4466 RFC4469 RFC4551 RFC5032 RFC5182 RFC5738 RFC6186 RFC6858 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3501 10.17487/RFC3501
RFC3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension M. Crispin March 2003 ASCII 13379 7 IMAPv4 imap imapv4rev1

This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of "MULTIAPPEND". [STANDARDS-TRACK]

draft-crispin-imap-multiappend-07 RFC4466 RFC4469 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3502
RFC3503 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP) A. Melnikov March 2003 ASCII 16937 9 mua mail user agent imap4

The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment. This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products. [STANDARDS-TRACK]

draft-melnikov-imap-mdn-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3503
RFC3504 Internet Open Trading Protocol (IOTP) Version 1, Errata D. Eastlake March 2003 ASCII 8655 6 commerce payment system merchant system xml extensible markup language security

Since the publication of the RFCs specifying Version 1.0 of the Internet Open Trading Protocol (IOTP), some errors have been noted. This informational document lists these errors and provides corrections for them. This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1-errata-01 INFORMATIONAL INFORMATIONAL IETF app trade http://www.rfc-editor.org/errata_search.php?rfc=3504 10.17487/RFC3504
RFC3505 Electronic Commerce Modeling Language (ECML): Version 2 Requirements D. Eastlake March 2003 ASCII 13915 8 xml extensible markup language

This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to Extensible Markup Language (XML) syntax, data model, format, and payment processing. This memo provides information for the Internet community.

draft-ietf-trade-ecml2-req-05 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3505
RFC3506 Requirements and Design for Voucher Trading System (VTS) K. Fujimura D. Eastlake March 2003 ASCII 30945 15 generic voucher language gvl

Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described. This memo provides information for the Internet community.

draft-ietf-trade-drt-requirements-04 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3506
RFC3507 Internet Content Adaptation Protocol (ICAP) J. Elson A. Cerpa April 2003 ASCII 98772 49 http hyper-text markup protocol request response client server

ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses. This memo provides information for the Internet community.

draft-elson-icap-00 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3507 10.17487/RFC3507
RFC3508 H.323 Uniform Resource Locator (URL) Scheme Registration O. Levin April 2003 ASCII 10983 6 itu-t packet networks

ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.

draft-levin-iptel-h323-url-scheme-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3508
RFC3509 Alternative Implementations of OSPF Area Border Routers A. Zinin A. Lindem D. Yeung April 2003 ASCII 24326 12 traffic backbone

Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers. This memo provides information for the Internet community.

draft-ietf-ospf-abr-alt-05 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC3509
RFC3510 Internet Printing Protocol/1.1: IPP URL Scheme R. Herriot I. McDonald April 2003 ASCII 22009 16 IPP-E-T IPP application media-type media type

This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service. [STANDARDS-TRACK]

draft-ietf-ipp-url-scheme-05 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3510
RFC3511 Benchmarking Methodology for Firewall Performance B. Hickman D. Newman S. Tadjudin T. Martin April 2003 ASCII 67916 34 client server traffic authentication web caching

This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.

draft-ietf-bmwg-firewall-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3511
RFC3512 Configuring Networks and Devices with Simple Network Management Protocol (SNMP) M. MacFaden D. Partain J. Saperia W. Tackabury April 2003 ASCII 196529 83 internet standard framework

This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. This memo provides information for the Internet community.

draft-ietf-snmpconf-bcp-12 INFORMATIONAL INFORMATIONAL IETF ops snmpconf 10.17487/RFC3512
RFC3513 Internet Protocol Version 6 (IPv6) Addressing Architecture R. Hinden S. Deering April 2003 ASCII 53920 26 internet protocol unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS-TRACK]

draft-ietf-ipngwg-addr-arch-v3-11 RFC2373 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3513
RFC3514 The Security Flag in the IPv4 Header S. Bellovin April 1 2003 ASCII 11211 6 evil evil bit

Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3514 10.17487/RFC3514
RFC3515 The Session Initiation Protocol (SIP) Refer Method R. Sparks April 2003 ASCII 47788 23 resource request call transfer

This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK]

draft-ietf-sip-refer-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3515
RFC3516 IMAP4 Binary Content Extension L. Nerenberg April 2003 ASCII 14598 8 internet message acess procotol

This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer- encoding. [STANDARDS-TRACK]

draft-nerenberg-imap-binary-07 RFC4466 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3516 10.17487/RFC3516
RFC3517 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP E. Blanton M. Allman K. Fall L. Wang April 2003 ASCII 27855 13 transmission control protocol retransmission congestion control

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. [STANDARDS-TRACK]

draft-allman-tcp-sack-13 RFC6675 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3517
RFC3518 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) M. Higashiyama F. Baker T. Liao April 2003 ASCII 82102 40 PPP-BCP point-to-point datagrams network

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 2878, which was based on the IEEE 802.1D- 1993 MAC Bridge. This document extends that specification by improving support for bridge control packets. [STANDARDS-TRACK]

draft-ietf-pppext-rfc2878bis-01 RFC2878 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3518
RFC3519 Mobile IP Traversal of Network Address Translation (NAT) Devices H. Levkowetz S. Vaarala April 2003 ASCII 80522 34 Internet Protocol datagram traffic Mobile IP NAT NAPT traversal tunnelling tunneling UDP private address space keepalives port 434 MIP MIPv4 network address translation

Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS-TRACK]

draft-ietf-mobileip-nat-traversal-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3519 10.17487/RFC3519
RFC3520 Session Authorization Policy Element L-N. Hamer B. Gage B. Kosinski H. Shieh April 2003 ASCII 63445 30 admission control resource reservation

This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-authsession-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3520
RFC3521 Framework for Session Set-up with Media Authorization L-N. Hamer B. Gage H. Shieh April 2003 ASCII 59548 25 qos quality of service streams linkage policy control admission theft service resource reservation token

Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in- line with the media streams requested (and authorized) for the session. This memo provides information for the Internet community.

draft-ietf-rap-session-auth-04 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3521
RFC3522 The Eifel Detection Algorithm for TCP R. Ludwig M. Meyer April 2003 ASCII 33731 14 transmission control protocol loss recovery timestamps

The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-tcp-eifel-alg-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3522
RFC3523 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology J. Polk April 2003 ASCII 10190 6 naming convetions phone

This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREP Working Group during discussions and when writing requirements, gap analysis and other solutions documents. This memo provides information for the Internet community.

draft-polk-ieprep-scenarios-03 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3523
RFC3524 Mapping of Media Streams to Resource Reservation Flows G. Camarillo A. Monrad April 2003 ASCII 11249 6 sdp session description protocol srf single

This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). [STANDARDS-TRACK]

draft-ietf-mmusic-reservation-flows-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3524
RFC3525 Gateway Control Protocol Version 1 C. Groves M. Pantaleo T. Anderson T. Taylor Editors June 2003 ASCII 439674 213 MEGACO H.248 media gateway control

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. [STANDARDS-TRACK]

draft-ietf-megaco-3015corr-02 RFC3015 RFC5125 HISTORIC PROPOSED STANDARD IETF rai megaco http://www.rfc-editor.org/errata_search.php?rfc=3525 10.17487/RFC3525
RFC3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) T. Kivinen M. Kojo May 2003 ASCII 19166 10 bit groups

This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK]

draft-ietf-ipsec-ike-modp-groups-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3526
RFC3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4 K. Kinnear M. Stapp R. Johnson J. Kumarasamy April 2003 ASCII 16831 9 dynamic host configuration protocol

This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. [STANDARDS-TRACK]

draft-ietf-dhc-agent-subnet-selection-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3527
RFC3528 Mesh-enhanced Service Location Protocol (mSLP) W. Zhao H. Schulzrinne E. Guttman April 2003 ASCII 35208 15 da directory agent slpda service agent sa slpv2

This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti- entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. This memo defines an Experimental Protocol for the Internet community.

draft-zhao-slp-da-interaction-16 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3528
RFC3529 Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) W. Harold April 2003 ASCII 23314 15 format messages clients servers

Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. This memo defines an Experimental Protocol for the Internet community.

draft-harold-beep-xmlrpc-03 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3529
RFC3530 Network File System (NFS) version 4 Protocol S. Shepler B. Callaghan D. Robinson R. Thurlow C. Beame M. Eisler D. Noveck April 2003 ASCII 600988 275 NFSv4 network file system

The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document replaces RFC 3010 as the definition of the NFS version 4 protocol. [STANDARDS-TRACK]

draft-ietf-nfsv4-rfc3010bis-04 RFC3010 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=3530 10.17487/RFC3530
RFC3531 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block M. Blanchet April 2003 ASCII 11314 7 address plan addressing range space internet protocol

This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments. This memo provides information for the Internet community.

draft-ietf-ipv6-ipaddressassign-06 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3531
RFC3532 Requirements for the Dynamic Partitioning of Switching Elements T. Anderson J. Buerkle May 2003 ASCII 25119 11 atm asynchronous transfer mode

This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element (e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party. This memo provides information for the Internet community.

draft-ietf-gsmp-dyn-part-reqs-03 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3532
RFC3533 The Ogg Encapsulation Format Version 0 S. Pfeiffer May 2003 ASCII 32045 15 bitstream media streams video audio xiph.org multimedia media interleading format video bitstream packaging audio bitstream packaging free encapsulation format stream based storage of codec data framed bitstream

This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. This memo provides information for the Internet community. This memo provides information for the Internet community.

draft-pfeiffer-ogg-fileformat-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3533
RFC3534 The application/ogg Media Type L. Walleij May 2003 ASCII 10013 6 mime multipurpose internet mail extenstions

The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the Ogg Bitstream Format developers that it be usable without intellectual property concerns. [STANDARDS-TRACK]

draft-walleij-ogg-mediatype-08 RFC5334 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3534
RFC3535 Overview of the 2002 IAB Network Management Workshop J. Schoenwaelder May 2003 ASCII 42566 20 Internet Architecture Board

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. This memo provides information for the Internet community.

draft-iab-nm-workshop-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3535
RFC3536 Terminology Used in Internationalization in the IETF P. Hoffman May 2003 ASCII 64284 30 internet engineering task force

This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo provides information for the Internet community.

draft-hoffman-i18n-terms-11 RFC6365 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3536
RFC3537 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key J. Schaad R. Housley May 2003 ASCII 16885 9

This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). [PROPOSED STANDARD]

draft-ietf-smime-hmac-key-wrap-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3537 10.17487/RFC3537
RFC3538 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP) Y. Kawatsura June 2003 ASCII 103475 56 payment input output parameter

This document describes detailed Input/Output parameters for the Internet Open Trading Protocol (IOTP) Payment Application Programming Interface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP. This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1.0-set-02 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3538
RFC3539 Authentication, Authorization and Accounting (AAA) Transport Profile B. Aboba J. Wood June 2003 ASCII 93110 41

This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK]

draft-ietf-aaa-transport-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa 10.17487/RFC3539
RFC3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces N. Spring D. Wetherall D. Ely June 2003 ASCII 30081 13 congestion control tcp traffic control protocol

This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-tcp-nonce-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3540
RFC3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D) A. Walsh May 2003 ASCII 11358 6 virtual reality monitoring language vrml extensible markup language x3d xml dtd document type definition

This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality Modeling Language (VRML) and Extensible 3D (X3D) files and resources, Extensible Markup Language (XML) Document Type Definitions (DTDs), XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D. This memo provides information for the Internet community.

draft-walsh-urn-web3d-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3541
RFC3542 Advanced Sockets Application Program Interface (API) for IPv6 W. Stevens M. Thomas E. Nordmark T. Jinmei May 2003 ASCII 173028 77 application program interface

This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community.

draft-ietf-ipngwg-rfc2292bis-09 RFC2292 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3542 10.17487/RFC3542
RFC3543 Registration Revocation in Mobile IPv4 S. Glass M. Chandra August 2003 ASCII 81805 33 internet protocol

This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well. Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding. [STANDARDS-TRACK]

draft-ietf-mobileip-reg-revok-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3543
RFC3544 IP Header Compression over PPP T. Koren S. Casner C. Bormann July 2003 ASCII 27627 14 IPCOM-PPP internet protocol point-to-point datagrams

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS-TRACK]

draft-koren-pppext-rfc2509bis-03 RFC2509 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3544
RFC3545 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering T. Koren S. Casner J. Geevarghese B. Thompson P. Ruddy July 2003 ASCII 48278 22 point to point header

This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. [STANDARDS-TRACK]

draft-ietf-avt-crtp-enhance-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3545
RFC3546 Transport Layer Security (TLS) Extensions S. Blake-Wilson M. Nystrom D. Hopwood J. Mikkelsen T. Wright June 2003 ASCII 63437 29 transport protocol layer authentication privacy

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]

draft-ietf-tls-extensions-06 RFC4366 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3546
RFC3547 The Group Domain of Interpretation M. Baugher B. Weis T. Hardjono H. Harney July 2003 ASCII 108901 48 isamkp doi key management security encryption

This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. [STANDARDS-TRACK]

draft-ietf-msec-gdoi-07 RFC6407 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC3547
RFC3548 The Base16, Base32, and Base64 Data Encodings S. Josefsson Editor July 2003 ASCII 26363 13 schemes data line-feeds alphabets base encoding hex

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. This memo provides information for the Internet community.

draft-josefsson-base-encoding-04 RFC4648 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3548 10.17487/RFC3548
RFC3549 Linux Netlink as an IP Services Protocol J. Salim H. Khosravi A. Kleen A. Kuznetsov July 2003 ASCII 72161 33 internet protocol messaging system

This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter- process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group. This memo provides information for the Internet community.

draft-ietf-forces-netlink-04 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC3549
RFC3550 RTP: A Transport Protocol for Real-Time Applications H. Schulzrinne S. Casner R. Frederick V. Jacobson July 2003 ASCII 259985 104 PS 630740 PDF 504117 RTP end-to-end network audio video RTCP

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]

draft-ietf-avt-rtp-new-12 RFC1889 RFC5506 RFC5761 RFC6051 RFC6222 RFC7022 RFC7160 RFC7164 STD0064 INTERNET STANDARD DRAFT STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3550 10.17487/RFC3550
RFC3551 RTP Profile for Audio and Video Conferences with Minimal Control H. Schulzrinne S. Casner July 2003 ASCII 106621 44 PS 317286 PDF 237831 RTP-AV end-to-end network conference

This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]

draft-ietf-avt-profile-new-13 RFC1890 RFC5761 RFC7007 STD0065 INTERNET STANDARD DRAFT STANDARD IETF rai avt 10.17487/RFC3551
RFC3552 Guidelines for Writing RFC Text on Security Considerations E. Rescorla B. Korver July 2003 ASCII 110393 44 Request for Comment

All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-sec-cons-03 BCP0072 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=3552 10.17487/RFC3552
RFC3553 An IETF URN Sub-namespace for Registered Protocol Parameters M. Mealling L. Masinter T. Hardie G. Klyne June 2003 ASCII 14815 8 syntax uniform resource names

This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-mealling-iana-urn-04 BCP0073 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3553
RFC3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec S. Bellovin J. Ioannidis A. Keromytis R. Stewart July 2003 ASCII 20102 9 ike internet key exchange security

This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic. [STANDARDS-TRACK]

draft-ietf-ipsec-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3554
RFC3555 MIME Type Registration of RTP Payload Formats S. Casner P. Hoschka July 2003 ASCII 56618 45 real time transport protocol multipurpose internet mail extensions

This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text- based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mime-06 RFC4855 RFC4856 RFC3625 RFC4629 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3555
RFC3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth S. Casner July 2003 ASCII 15310 8 real time transport protocol real-time

This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS-TRACK]

draft-ietf-avt-rtcp-bw-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3556
RFC3557 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding Q. Xie Editor July 2003 ASCII 29692 15 real time transport protocol real-time dsr

This document specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]

draft-ietf-avt-dsr-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3557
RFC3558 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) A. Li July 2003 ASCII 49787 23 real time transport protocol real-time bundled interleaved

This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. [STANDARDS-TRACK]

draft-ietf-avt-evrc-smv-03 RFC4788 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3558
RFC3559 Multicast Address Allocation MIB D. Thaler June 2003 ASCII 68239 37 maas management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. [STANDARDS-TRACK]

draft-ietf-malloc-malloc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC3559
RFC3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS) R. Housley July 2003 ASCII 37381 18 security encryption

This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS-TRACK]

draft-ietf-smime-cms-rsaes-oaep-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3560
RFC3561 Ad hoc On-Demand Distance Vector (AODV) Routing C. Perkins E. Belding-Royer S. Das July 2003 ASCII 90356 37 unicast multiple nodes

The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-manet-aodv-13 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3561
RFC3562 Key Management Considerations for the TCP MD5 Signature Option M. Leech July 2003 ASCII 14965 7 bgp border gateway protocol security encryption

The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. This memo provides information for the Internet community.

draft-ietf-idr-md5-keys-00 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC3562
RFC3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development A. Zinin July 2003 ASCII 14974 8

This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. This memo provides information for the Internet community.

draft-zinin-ietf-jtc1-aggr-01 RFC6233 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3563
RFC3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering F. Le Faucheur W. Lai July 2003 ASCII 50808 22 multi-protocol label switching bandwidth constraints model overbooking

This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS- TE). Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document. A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. This memo provides information for the Internet community.

draft-ietf-tewg-diff-te-reqts-07 RFC5462 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3564
RFC3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS) J. Schaad July 2003 ASCII 26773 14 security data encoding

This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]

draft-ietf-smime-aes-alg-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3565
RFC3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec S. Frankel H. Herbert September 2003 ASCII 24645 11 authentication hash security

A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. [STANDARDS-TRACK]

draft-ietf-ipsec-ciph-aes-xcbc-mac-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3566
RFC3567 Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication T. Li R. Atkinson July 2003 ASCII 13467 6 iso international standards organization

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. This memo provides information for the Internet community.

draft-ietf-isis-hmac-04 RFC5304 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3567
RFC3568 Known Content Network (CN) Request-Routing Mechanisms A. Barbir B. Cain R. Nair O. Spatscheck July 2003 ASCII 42443 19 metrics routing redirection

This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. This memo provides information for the Internet community.

draft-ietf-cdi-known-request-routing-03 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3568
RFC3569 An Overview of Source-Specific Multicast (SSM) S. Bhattacharyya Editor July 2003 ASCII 29387 14 routing applications deployment interoperability

The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. This memo provides information for the Internet community.

draft-ietf-ssm-overview-05 INFORMATIONAL INFORMATIONAL IETF rtg ssm 10.17487/RFC3569
RFC3570 Content Internetworking (CDI) Scenarios P. Rzewski M. Day D. Gilletti July 2003 ASCII 42432 20 production networks

In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. This memo provides information for the Internet community.

draft-ietf-cdi-scenarios-01 RFC6770 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3570
RFC3571 Framework Policy Information Base for Usage Feedback D. Rawlins A. Kulkarni K. Ho Chan M. Bokaemper D. Dutt August 2003 ASCII 70894 35 pib

This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected. This memo provides information for the Internet community.

draft-ietf-rap-feedback-fr-pib-06 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3571
RFC3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH) T. Ogura M. Maruyama T. Yoshida July 2003 ASCII 30607 14 ipv6 synchronous optical network synchronous digital hierarchy

Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH). This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages. This memo provides information for the Internet community.

draft-ogura-ipv6-mapos-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3572
RFC3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) I. Goyret July 2003 ASCII 22758 13 ppp point to point point-to-point pstn public switched telephone network

The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network. One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls. The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. [STANDARDS-TRACK]

draft-ietf-l2tpext-v92-moh-05 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3573
RFC3574 Transition Scenarios for 3GPP Networks J. Soininen Editor August 2003 ASCII 23359 12 third generation parnership project packet ipv6 ipv4 internet

This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This memo provides information for the Internet community.

draft-ietf-v6ops-3gpp-cases-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3574
RFC3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service) B. Aboba July 2003 ASCII 15539 8 internet assigned numbers authority encryption NAS Network Access Server

This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS-TRACK]

draft-aboba-radius-iana-07 RFC2865 RFC2868 RFC6929 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3575 10.17487/RFC3575
RFC3576 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) M. Chiba G. Dommety M. Eklund D. Mitton B. Aboba July 2003 ASCII 70027 30 nas network access server

This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.

draft-chiba-radius-dynamic-authorization-20 RFC5176 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3576
RFC3577 Introduction to the Remote Monitoring (RMON) Family of MIB Modules S. Waldbusser R. Cole C. Kalbfleisch D. Romascanu August 2003 ASCII 68551 31 management information base

The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another. This memo provides information for the Internet community.

draft-ietf-rmonmib-framework-05 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC3577
RFC3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) G. Camarillo A. B. Roach J. Peterson L. Ong August 2003 ASCII 26667 13 pstn public switched telephone network

This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). [STANDARDS-TRACK]

draft-ietf-sipping-overlap-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3578
RFC3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) B. Aboba P. Calhoun September 2003 ASCII 104469 46 RADIUS encryption NAS Network Access Server

This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community.

draft-aboba-radius-rfc2869bis-22 RFC2869 RFC5080 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3579
RFC3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines P. Congdon B. Aboba A. Smith G. Zorn J. Roese September 2003 ASCII 66136 30 AAA authentication authorization and accounting

This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.

draft-congdon-radius-8021x-29 RFC7268 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3580 10.17487/RFC3580
RFC3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing J. Rosenberg H. Schulzrinne August 2003 ASCII 66133 13 report client server

The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated. [STANDARDS-TRACK]

draft-ietf-sip-symmetric-response-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3581
RFC3582 Goals for IPv6 Site-Multihoming Architectures J. Abley B. Black V. Gill August 2003 ASCII 17045 9 internet protocol multi6

This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. This memo provides information for the Internet community.

draft-ietf-multi6-multihoming-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC3582
RFC3583 Requirements of a Quality of Service (QoS) Solution for Mobile IP H. Chaskar Editor September 2003 ASCII 22541 10 internet protocol routing packets node

Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. This memo provides information for the Internet community.

draft-ietf-nsis-qos-requirements-01 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC3583
RFC3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework R. Frye D. Levi S. Routhier B. Wijnen August 2003 ASCII 115222 51 SNMP simple network management protocol mib information base

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-snmpv3-coex-v2-04 RFC2576 BCP0074 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops snmpv3 10.17487/RFC3584
RFC3585 IPsec Configuration Policy Information Model J. Jason L. Rafalow E. Vyncke August 2003 ASCII 187308 88 ike internet key exchange protocol core pcim

This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task- specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model. This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the Policy Core Information Model Extensions (PCIMe). [STANDARDS-TRACK]

draft-ietf-ipsp-config-policy-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsp 10.17487/RFC3585
RFC3586 IP Security Policy (IPSP) Requirements M. Blaze A. Keromytis M. Richardson L. Sanchez August 2003 ASCII 22068 10 data integrity authentication host network

This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements. [STANDARDS-TRACK]

draft-ietf-ipsp-requirements-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsp 10.17487/RFC3586
RFC3587 IPv6 Global Unicast Address Format R. Hinden S. Deering E. Nordmark August 2003 ASCII 8783 5 internet protocol architecture routing

This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community.

draft-ietf-ipv6-unicast-aggr-v2-03 RFC2374 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3587
RFC3588 Diameter Base Protocol P. Calhoun J. Loughney E. Guttman G. Zorn J. Arkko September 2003 ASCII 341261 147 aaa authentication authorization accounting ip mobility

The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-17 RFC6733 RFC5729 RFC5719 RFC6408 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=3588 10.17487/RFC3588
RFC3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5 J. Loughney September 2003 ASCII 8010 5 iana allocation

This document describes the IANA's allocation of a block of Diameter Command Codes for the Third Generation Partnership Project (3GPP) Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. This memo provides information for the Internet community.

draft-loughney-aaa-cc-3gpp-01 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3589 10.17487/RFC3589
RFC3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol B. Haberman September 2003 ASCII 11554 6 MLD-IPv6 internet protocol routher packets

It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. [STANDARDS-TRACK]

draft-ietf-magma-mld-source-07 RFC2710 PROPOSED STANDARD PROPOSED STANDARD IETF int magma 10.17487/RFC3590
RFC3591 Definitions of Managed Objects for the Optical Interface Type H-K. Lam M. Stewart A. Huynh September 2003 ASCII 310815 174 management information base mib snmp simple network management protocol otn optical transport network itu-t performance monitoring configuration dwdm optical tranmission session optical multiplex section optical channel otuk odukt oduk

This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP-based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. [STANDARDS-TRACK]

draft-ietf-atommib-opticalmib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib http://www.rfc-editor.org/errata_search.php?rfc=3591 10.17487/RFC3591
RFC3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type K. Tesink September 2003 ASCII 143588 73 MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]

draft-ietf-atommib-rfc2558bis-01 RFC2558 DRAFT STANDARD DRAFT STANDARD IETF ops atommib http://www.rfc-editor.org/errata_search.php?rfc=3592 10.17487/RFC3592
RFC3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals K. Tesink Editor September 2003 ASCII 20363 10 management information base data

This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals. This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]

draft-ietf-atommib-rfc2493bis-01 RFC2493 DRAFT STANDARD DRAFT STANDARD IETF ops atommib 10.17487/RFC3593
RFC3594 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option P. Duffy September 2003 ASCII 12521 7 dynamic host configuration protocol

This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets). [STANDARDS-TRACK]

draft-ietf-dhc-pktc-kerb-tckt-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3594
RFC3595 Textual Conventions for IPv6 Flow Label B. Wijnen September 2003 ASCII 11746 6 mib management information base

This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-ops-ipv6-flowlabel-01 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3595
RFC3596 DNS Extensions to Support IP Version 6 S. Thomson C. Huitema V. Ksinant M. Souissi October 2003 ASCII 14093 8 internet protocol domain name system DNS zone

This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]

draft-ietf-dnsext-rfc1886bis-03 RFC3152 RFC1886 DRAFT STANDARD DRAFT STANDARD IETF int dnsext 10.17487/RFC3596
RFC3597 Handling of Unknown DNS Resource Record (RR) Types A. Gustafsson September 2003 ASCII 17559 8 domain name system name server software compression transparency

Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]

draft-ietf-dnsext-unknown-rrs-06 RFC2163 RFC2535 RFC4033 RFC4034 RFC4035 RFC5395 RFC6195 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3597 10.17487/RFC3597
RFC3598 Sieve Email Filtering -- Subaddress Extension K. Murchison September 2003 ASCII 11151 6 users detailed addressing language address part test detail filter mailbox

On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. [STANDARDS-TRACK]

draft-murchison-sieve-subaddress-06 RFC5233 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3598
RFC3599 Request for Comments Summary RFC Numbers 3500-3599 S. Ginoza December 2003 ASCII 76893 34

This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. This is a status report on these RFCs.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3599
RFC3600 Internet Official Protocol Standards J. Reynolds Editor S. Ginoza Editor November 2003 ASCII 134338 50

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.

RFC3300 RFC3700 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3600 10.17487/RFC3600
RFC3601 Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses C. Allocchio September 2003 ASCII 18572 10 notations dtmf dual tone multifrequency telephony e-mail addresses urls integrated messaging 3gpp

This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional "actions" (such as "wait for dialtone", "pause for N secs", etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.

draft-allocchio-gstn-05 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3601
RFC3602 The AES-CBC Cipher Algorithm and Its Use with IPsec S. Frankel R. Glenn S. Kelly September 2003 ASCII 30254 15 ipsec encapsulating security payload

This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).

draft-ietf-ipsec-ciph-aes-cbc-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3602
RFC3603 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture W. Marshall Editor F. Andreasen Editor October 2003 ASCII 67509 28 network access coordination

In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.

draft-dcsgroup-sipping-proxy-proxy-03 RFC5503 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3603
RFC3604 Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3) H. Khosravi G. Kullgren S. Shew J. Sadler A. Watanabe October 2003 ASCII 30805 16 controllers routers formats codes

This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.

draft-ietf-gsmp-reqs-06 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3604
RFC3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) C. Huitema October 2003 ASCII 17270 8 nat network access translation port mapping

The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.

draft-ietf-mmusic-sdp4nat-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3605 10.17487/RFC3605
RFC3606 Definitions of Supplemental Managed Objects for ATM Interface F. Ly M. Noto A. Smith E. Spiegel K. Tesink November 2003 ASCII 183610 94 asynchronous transfer mode mib management information base

This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, the ATM-MIB, to provide additional support for the management of ATM Switched Virtual Connections (SVCs) and ATM Permanent Virtual Connections (PVCs).

draft-ietf-atommib-atm2-19 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3606
RFC3607 Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool M. Leech September 2003 ASCII 14526 8 security encryption des data standard distributed cryptanalysis computer virus network worm codebreaking

This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences.

draft-leech-chinese-lottery-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3607
RFC3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration D. Willis B. Hoeneisen October 2003 ASCII 35628 17 user agent domain register

This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.

draft-ietf-sip-scvrtdisco-04 RFC5630 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3608
RFC3609 Tracing Requirements for Generic Tunnels R. Bonica K. Kompella D. Meyer September 2003 ASCII 17859 9 traceroute application IP internet protocol

This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding. The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers. Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by an IP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.

draft-ietf-ccamp-tracereq-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC3609
RFC3610 Counter with CBC-MAC (CCM) D. Whiting R. Housley N. Ferguson September 2003 ASCII 64509 26 authentication encryption security ciphers

Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).

draft-housley-ccm-mode-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3610
RFC3611 RTP Control Protocol Extended Reports (RTCP XR) T. Friedman Editor R. Caceres Editor A. Clark Editor November 2003 ASCII 126736 55 real time transport protocol packet type sdp session description blocks

This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.

draft-ietf-avt-rtcp-report-extns-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3611 10.17487/RFC3611
RFC3612 Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) A. Farrel September 2003 ASCII 35677 16 mpls fault tolerence high availability multiprotocol label switching cr-ldp high availability restart

This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP".

draft-ietf-mpls-ldp-restart-applic-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3612
RFC3613 Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE) R. Morgan K. Hazelton October 2003 ASCII 14296 8 internet2 middleware

This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE). This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates.

draft-hazelton-mace-urn-namespace-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3613
RFC3614 A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG) J. Smith September 2003 ASCII 10457 6 iso international organization standardization multimedia metadata xml classification schemes digital rights management

This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG.

draft-smith-urn-mpeg-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3614
RFC3615 A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging J. Gustin A. Goyens September 2003 ASCII 7352 5 messaging service interface software

This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.

draft-gustin-goyens-urn-id-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3615
RFC3616 A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA) F. Bellifemine I. Constantinescu S. Willmott September 2003 ASCII 13352 8 URN NID Uniform Resource Name Namespace Identification

This document describes a Uniform Resource Name Namespace Identification (URN NID) for the Foundation for Intelligent Physical Agents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.

draft-bellifemine-urn-fipa-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3616
RFC3617 Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) E. Lear October 2003 ASCII 11848 7

The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time. While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.

draft-lear-tftp-uri-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3617
RFC3618 Multicast Source Discovery Protocol (MSDP) B. Fenner Editor D. Meyer Editor October 2003 ASCII 42238 19 ipv4 pim-sm independent multicast sparse-mode rp rendezvous point

The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.

draft-ietf-msdp-spec-20 EXPERIMENTAL EXPERIMENTAL IETF rtg msdp http://www.rfc-editor.org/errata_search.php?rfc=3618 10.17487/RFC3618
RFC3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1 S. Shah M. Yip October 2003 ASCII 14440 7 ethernet rings robust

This document describes the Ethernet Automatic Protection Switching (EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at a lower cost and with fewer constraints (e.g., ring size).

draft-shah-extreme-eaps-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3619
RFC3620 The TUNNEL Profile D. New October 2003 ASCII 35365 18 beep blocks extensible exchange protocol firewall application layer

This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.

draft-ietf-idwg-beep-tunnel-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec idwg 10.17487/RFC3620
RFC3621 Power Ethernet MIB A. Berger D. Romascanu December 2003 ASCII 37294 20 management information base data terminal equipment power dte power sourcing equipment pse

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing Power Sourcing Equipment (PSE).

draft-ietf-hubmib-power-ethernet-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3621
RFC3622 A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project M. Mealling February 2004 ASCII 11432 7 federated network identity

This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.

draft-mealling-liberty-urn-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3622
RFC3623 Graceful OSPF Restart J. Moy P. Pillay-Esnault A. Lindem November 2003 ASCII 38757 18 open shortest path first non-stop forwarding

This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called "graceful restart" or "non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.

draft-ietf-ospf-hitless-restart-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3623
RFC3624 The Media Gateway Control Protocol (MGCP) Bulk Audit Package B. Foster D. Auerbach F. Andreasen November 2003 ASCII 34391 19 call agent endpoints naming conventions

The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints. It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.

draft-foster-mgcp-bulkaudits-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3624
RFC3625 The QCP File Format and Media Types for Speech Data R. Gellens H. Garudadri September 2003 ASCII 28603 15 13k qcelp audio multimedia voip real time transport protocol multipurpose internet mail extensions

RFC 2658 specifies the streaming format for 3GPP2 13KK vocoder (High Rate Speech Service Option 17 for Wideband Spread Spectrum Communications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the "QCP" file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder (EVRC) and Selectable Mode Vocoders (SMV) data. (For example, Eudora(r), QuickTime(r), and cmda2000(r) handsets). This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types for EVRC and SMV (respectively) data stored in this format.

draft-gellens-qcp-01 RFC3555 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3625 10.17487/RFC3625
RFC3626 Optimized Link State Routing Protocol (OLSR) T. Clausen Editor P. Jacquet Editor October 2003 ASCII 161265 75 mobile ad hoc wireless multipoint relays mpr mprs

This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.

draft-ietf-manet-olsr-11 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3626
RFC3627 Use of /127 Prefix Length Between Routers Considered Harmful P. Savola September 2003 ASCII 12436 6 address space anycast

In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.

draft-savola-ipv6-127-prefixlen-04 RFC6547 HISTORIC INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3627 10.17487/RFC3627
RFC3628 Policy Requirements for Time-Stamping Authorities (TSAs) D. Pinkas N. Pope J. Ross November 2003 ASCII 92941 43 tokens public key certificates

This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document.

draft-ietf-pkix-pr-tsa-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3628
RFC3629 UTF-8, a transformation format of ISO 10646 F. Yergeau November 2003 ASCII 33856 14 UTF-8 UCS Transformation Format

ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.

draft-yergeau-rfc2279bis-05 RFC2279 STD0063 INTERNET STANDARD INTERNET STANDARD INDEPENDENT 10.17487/RFC3629
RFC3630 Traffic Engineering (TE) Extensions to OSPF Version 2 D. Katz K. Kompella D. Yeung September 2003 ASCII 27717 14 open-shortest path first ink state advertisement

This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.

draft-katz-yeung-ospf-traffic-10 RFC2370 RFC4203 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3630
RFC3631 Security Mechanisms for the Internet S. Bellovin Editor J. Schiller Editor C. Kaufman Editor December 2003 ASCII 47064 20 protocol host compromise dos denial of service

Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself. However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.

draft-iab-secmech-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3631
RFC3632 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 S. Hollenbeck S. Veeramachaneni S. Yalamanchilli November 2003 ASCII 13490 8 RRP shared registration system gLTD ccTLD top level domain

This document updates version 1.1.0 of the Network Solutions Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol.

draft-hollenbeck-rfc2832bis-02 RFC2832 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3632
RFC3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 O. Troan R. Droms December 2003 ASCII 45308 19 automated delegation router

The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). This mechanism is intended for delegating a long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.

draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 RFC6603 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3633 10.17487/RFC3633
RFC3634 Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option K. Luehrs R. Woundy J. Bevilacqua N. Davoust December 2003 ASCII 13163 7

This document defines a new sub-option for the CableLabs Client Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center (KDC) servers.

draft-ietf-dhc-suboptions-kdc-serveraddress-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3634
RFC3635 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick September 2003 ASCII 154476 64 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.

draft-ietf-hubmib-etherif-mib-v3-03 RFC2665 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3635
RFC3636 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) J. Flick September 2003 ASCII 139990 62 MAU-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.

draft-ietf-hubmib-mau-mib-v3-04 RFC2668 RFC1515 RFC4836 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3636
RFC3637 Definitions of Managed Objects for the Ethernet WAN Interface Sublayer C.M. Heard Editor September 2003 ASCII 78785 37 mib management information base

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB.

draft-ietf-hubmib-wis-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3637
RFC3638 Applicability Statement for Reclassification of RFC 1643 to Historic Status J. Flick C. M. Heard September 2003 ASCII 8676 5 ETHER-MIB MIB Network Management SNMP Ethernet

This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.

draft-ietf-hubmib-1643-to-historic-01 RFC1643 INFORMATIONAL INFORMATIONAL IETF ops hubmib 10.17487/RFC3638
RFC3639 Considerations on the use of a Service Identifier in Packet Headers M. St. Johns Editor G. Huston Editor IAB October 2003 ASCII 15389 8 port fields protocol number

This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.

draft-iab-service-id-considerations-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3639
RFC3640 RTP Payload Format for Transport of MPEG-4 Elementary Streams J. van der Meer D. Mackie V. Swaminathan D. Singer P. Gentric November 2003 ASCII 102606 43 real time transport protocol audio video streams

The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.

draft-ietf-avt-mpeg4-simple-08 RFC5691 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3640
RFC3641 Generic String Encoding Rules (GSER) for ASN.1 Types S. Legg October 2003 ASCII 34207 16 asn.1 abstract syntax notation

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.

draft-legg-ldap-gser-04 RFC4792 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3641
RFC3642 Common Elements of Generic String Encoding Rules (GSER) Encodings S. Legg October 2003 ASCII 27774 13 asn.1 abstract syntax notation

The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes.

draft-legg-ldap-gser-abnf-07 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3642
RFC3643 Fibre Channel (FC) Frame Encapsulation R. Weber M. Rajagopal F. Travostino M. O'Donnell C. Monia M. Merhar December 2003 ASCII 39980 20 ips ip storage frame header

This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.

draft-ietf-ips-fcencapsulation-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3643
RFC3644 Policy Quality of Service (QoS) Information Model Y. Snir Y. Ramberg J. Strassner R. Cohen B. Moore November 2003 ASCII 170150 73 integrated differentiated object oriented

This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.

draft-ietf-policy-qos-info-model-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3644
RFC3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) S. Kwan P. Garg J. Gilroy L. Esibov J. Westhead R. Hall October 2003 ASCII 56162 26 TSIG domain name system transaction signature

The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.

draft-ietf-dnsext-gss-tsig-06 RFC2845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3645
RFC3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms Editor December 2003 ASCII 13312 7 domain name system service server client

This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.

draft-ietf-dhc-dhcpv6-opt-dnsconfig-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3646
RFC3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework S. Chokhani W. Ford R. Sabett C. Merrill S. Wu November 2003 ASCII 228124 94 pkix encryption security authentication

This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.

draft-ietf-pkix-ipki-new-rfc2527-02 RFC2527 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3647 10.17487/RFC3647
RFC3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol J. Whitehead J. Reschke Editor December 2003 ASCII 57147 30 server client semantics ordering orderpatch method position header ordering-type header

This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.

draft-ietf-webdav-ordering-protocol-10 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav 10.17487/RFC3648
RFC3649 HighSpeed TCP for Large Congestion Windows S. Floyd December 2003 ASCII 79801 34 transmission control protocol round-trip rate packet

The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address his limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.

draft-ietf-tsvwg-highspeed-01 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3649
RFC3650 Handle System Overview S. Sun L. Lannom B. Boesch November 2003 ASCII 54927 21 name service

This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. The Handle System is a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.

draft-sun-handle-system-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3650
RFC3651 Handle System Namespace and Service Definition S. Sun S. Reilly L. Lannom November 2003 ASCII 104479 41 name service

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle System namespace, and its data, service, and operation models. The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.

draft-sun-handle-system-def-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3651 10.17487/RFC3651
RFC3652 Handle System Protocol (ver 2.1) Specification S. Sun S. Reilly L. Lannom J. Petrone November 2003 ASCII 124380 53 name service

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.

draft-sun-handle-system-protocol-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3652
RFC3653 XML-Signature XPath Filter 2.0 J. Boyer M. Hughes J. Reagle December 2003 ASCII 32258 15 extensible markup language digital signature

XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles. This document is the W3C XML Signature XPath-Filter 2.0 Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

draft-ietf-xmldsig-xpf2-01 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC3653
RFC3654 Requirements for Separation of IP Control and Forwarding H. Khosravi Editor T. Anderson Editor November 2003 ASCII 40418 18 forces forwarding control element separation data

This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.

draft-ietf-forces-requirements-10 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC3654
RFC3655 Redefinition of DNS Authenticated Data (AD) bit B. Wellington O. Gudmundsson November 2003 ASCII 15646 8 DNS-SECEXT dns authentication

This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.

draft-ietf-dnsext-ad-is-secure-06 RFC4033 RFC4034 RFC4035 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3655
RFC3656 The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol R. Siemborski December 2003 ASCII 35509 19 imap pop3 post office protocol internet message access

As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery. The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.

draft-siemborski-mupdate-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3656
RFC3657 Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS) S. Moriai A. Kato January 2004 ASCII 26282 14 security mail content key

This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).

draft-ietf-smime-camellia-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3657
RFC3658 Delegation Signer (DS) Resource Record (RR) O. Gudmundsson December 2003 ASCII 42120 19 zone cut zone key security dns domain name system

The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.

draft-ietf-dnsext-delegation-signer-15 RFC4033 RFC4034 RFC4035 RFC3090 RFC3008 RFC2535 RFC1035 RFC3755 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3658
RFC3659 Extensions to FTP P. Hethmon March 2007 ASCII 137962 61 FTP file transfer protocol stream mode data transfer storage

This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. [STANDARDS-TRACK]

draft-ietf-ftpext-mlst-16 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext http://www.rfc-editor.org/errata_search.php?rfc=3659 10.17487/RFC3659
RFC3660 Basic Media Gateway Control Protocol (MGCP) Packages B. Foster F. Andreasen December 2003 ASCII 145147 64 generic line trunk handset dtmf dual tone multifrequency

This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.

draft-foster-mgcp-basic-packages-10 RFC2705 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3660
RFC3661 Media Gateway Control Protocol (MGCP) Return Code Usage B. Foster C. Sivachelvan December 2003 ASCII 49898 24 guidelines call agent implementation

This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP) Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that the Call Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency.

draft-foster-mgcp-returncodes-03 RFC3435 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3661
RFC3662 A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services R. Bless K. Nichols K. Wehrle December 2003 ASCII 39029 17 traffic network ds le

This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.

draft-bless-diffserv-pdb-le-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3662
RFC3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP) A. Newton December 2003 ASCII 42260 21 referral types well-known

Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP) Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available.

draft-newton-ldap-whois-03 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3663
RFC3664 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) P. Hoffman January 2004 ASCII 6711 4 security ipsec advanced encryption standard mac message authentication code

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128.

draft-ietf-ipsec-aes-xcbc-prf-01 RFC4434 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3664
RFC3665 Session Initiation Protocol (SIP) Basic Call Flow Examples A. Johnston S. Donovan R. Sparks C. Cunningham K. Summers December 2003 ASCII 163159 94 user agent client proxy redirect

This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown.

draft-ietf-sipping-basic-call-flows-02 BCP0075 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3665 10.17487/RFC3665
RFC3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows A. Johnston S. Donovan R. Sparks C. Cunningham K. Summers December 2003 ASCII 200478 118 user proxy gateway telephony

This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown.

draft-ietf-sipping-pstn-call-flows-02 BCP0076 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3666 10.17487/RFC3666
RFC3667 IETF Rights in Contributions S. Bradner February 2004 ASCII 43297 18 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-submission-rights-08 RFC3978 RFC2026 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3667
RFC3668 Intellectual Property Rights in IETF Technology S. Bradner February 2004 ASCII 41365 17 ipr copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-technology-rights-12 RFC3979 RFC2026 RFC2028 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3668
RFC3669 Guidelines for Working Groups on Intellectual Property Issues S. Brim February 2004 ASCII 40946 17 ipr copyright

This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. This memo provides information for the Internet community.

draft-ietf-ipr-wg-guidelines-05 INFORMATIONAL INFORMATIONAL IETF gen ipr 10.17487/RFC3669
RFC3670 Information Model for Describing Network Device QoS Datapath Mechanisms B. Moore D. Durham J. Strassner A. Westerinen W. Weiss January 2004 ASCII 221687 97 quality of service host netowrk devices traffic

The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository

draft-ietf-policy-qos-device-info-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3670
RFC3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII 17912 10 x.500 information model schema

X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This document provides schema definitions for collective attributes for use in LDAP.

draft-zeilenga-ldap-collective-08 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3671
RFC3672 Subentries in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII 24447 12 special subtree

In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP).

draft-zeilenga-ldap-subentry-07 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3672
RFC3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes K. Zeilenga December 2003 ASCII 10003 5 user mechanisms extension

The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes.

draft-zeilenga-ldap-opattrs-05 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3673
RFC3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII 10282 5 elective extensions mechanisms

The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms.

draft-zeilenga-ldap-features-05 RFC4512 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3674
RFC3675 .sex Considered Dangerous D. Eastlake 3rd February 2004 ASCII 53211 22 top level domains tld ip addresses internet protocol filters

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.

draft-eastlake-xxx-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3675
RFC3676 The Text/Plain Format and DelSp Parameters R. Gellens February 2004 ASCII 42441 20 media type mime multipurpose internet mail extension

This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting. This document supersedes the one specified in RFC 2646, "The Text/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely. [STANDARDS-TRACK]

draft-gellens-format-bis-04 RFC2646 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3676
RFC3677 IETF ISOC Board of Trustee Appointment Procedures L. Daigle Editor Internet Architecture Board December 2003 ASCII 13008 7 internet society bot engineering task force

This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.

draft-iab-isocbot-01 BCP0077 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=3677 10.17487/RFC3677
RFC3678 Socket Interface Extensions for Multicast Source Filters D. Thaler B. Fenner B. Quinn January 2004 ASCII 36320 18 ip internet protocol application program interface apis input output

The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.

draft-ietf-magma-msf-api-05 INFORMATIONAL INFORMATIONAL IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=3678 10.17487/RFC3678
RFC3679 Unused Dynamic Host Configuration Protocol (DHCP) Option Codes R. Droms January 2004 ASCII 13804 8 dynamic host configuration protocol internet assigned numbers authority

Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic Host Configuration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.

draft-ietf-dhc-unused-optioncodes-07 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC3679
RFC3680 A Session Initiation Protocol (SIP) Event Package for Registrations J. Rosenberg March 2004 ASCII 35403 26 REGISTER event package name event package parameters

This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. [STANDARDS-TRACK]

draft-ietf-sipping-reg-event-00 RFC6140 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3680 10.17487/RFC3680
RFC3681 Delegation of E.F.F.3.IP6.ARPA R. Bush R. Fink January 2004 ASCII 7137 4 dns domain name system

This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this.

draft-ymbk-6bone-arpa-delegation-01 BCP0080 BEST CURRENT PRACTICE BEST CURRENT PRACTICE INDEPENDENT 10.17487/RFC3681
RFC3682 The Generalized TTL Security Mechanism (GTSM) V. Gill J. Heasley D. Meyer February 2004 ASCII 23321 11 time to live packet hop limit

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. This memo defines an Experimental Protocol for the Internet community.

draft-gill-gtsh-04 RFC5082 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3682
RFC3683 A Practice for Revoking Posting Rights to IETF Mailing Lists M. Rose March 2004 ASCII 15698 13

All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-mrose-ietf-posting-04 BCP0083 BEST CURRENT PRACTICE BEST CURRENT PRACTICE INDEPENDENT 10.17487/RFC3683
RFC3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) R. Ogier F. Templin M. Lewis February 2004 ASCII 107963 46 proactive routing ad-hoc networks neighbor discovery link-state routing mobile ad-hoc network mobile mesh network packet radio network wireless communications

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-manet-tbrpf-11 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3684
RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions C. Daboo February 2004 ASCII 17436 9 messages portable commands

The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. [PROPOSED STANDARD]

draft-daboo-sieve-spamtest-04 RFC5235 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3685
RFC3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) R. Housley January 2004 ASCII 43777 19 authentication vector cipher block

This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.

draft-ietf-ipsec-ciph-aes-ctr-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3686
RFC3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules S. Legg February 2004 ASCII 96256 42 syntax data schema

The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. [PROPOSED STANDARD]

draft-legg-ldapext-component-matching-11 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3687
RFC3688 The IETF XML Registry M. Mealling January 2004 ASCII 17325 8 extensible markup language

This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.

draft-mealling-iana-xmlns-registry-05 BCP0081 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3688
RFC3689 General Requirements for Emergency Telecommunication Service (ETS) K. Carlberg R. Atkinson February 2004 ASCII 21680 10

This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). This memo provides information for the Internet community.

draft-ietf-ieprep-ets-general-04 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3689
RFC3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS) K. Carlberg R. Atkinson February 2004 ASCII 13919 7

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.

draft-ietf-ieprep-ets-telephony-07 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3690
RFC3691 Internet Message Access Protocol (IMAP) UNSELECT command A. Melnikov February 2004 ASCII 8436 5 mailbox session client

This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version 4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable. [STANDARDS-TRACK]

draft-melnikov-imap-unselect-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3691
RFC3692 Assigning Experimental and Testing Numbers Considered Useful T. Narten January 2004 ASCII 15054 7 iana internet assigned numbers authority values implementations

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.

draft-narten-iana-experimental-allocations-05 RFC2434 BCP0082 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3692
RFC3693 Geopriv Requirements J. Cuellar J. Morris D. Mulligan J. Peterson J. Polk February 2004 ASCII 68881 30 security privacy lo location object

Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved. This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. This memo provides information for the Internet community.

draft-ietf-geopriv-reqs-04 RFC6280 RFC7459 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC3693
RFC3694 Threat Analysis of the Geopriv Protocol M. Danley D. Mulligan J. Morris J. Peterson February 2004 ASCII 44364 18 privacy security data information

This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. This memo provides information for the Internet community.

draft-ietf-geopriv-threat-analysis-01 RFC6280 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC3694
RFC3695 Compact Forward Error Correction (FEC) Schemes M. Luby L. Vicisano February 2004 ASCII 32012 13 content stream delivery multicast internet protocol

This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead. This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-fec-supp-compact-01 RFC5445 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3695
RFC3696 Application Techniques for Checking and Transformation of Names J. Klensin February 2004 ASCII 39238 16 top-level domains tlds

Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards. This memo provides information for the Internet community.

draft-klensin-name-filters-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3696 10.17487/RFC3696
RFC3697 IPv6 Flow Label Specification J. Rajahalme A. Conta B. Carpenter S. Deering March 2004 ASCII 21296 9 nodes packets

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]

draft-ietf-ipv6-flow-label-09 RFC6437 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3697
RFC3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules K. Zeilenga Editor February 2004 ASCII 17562 9 lightweight directory access protocol directory services

This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. [STANDARDS-TRACK]

draft-zeilenga-ldap-user-schema-mr-00 RFC2798 RFC4517 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3698
RFC3700 Internet Official Protocol Standards J. Reynolds Editor S. Ginoza Editor July 2004 ASCII 148273 54

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]

RFC3600 RFC5000 HISTORIC INTERNET STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3700 10.17487/RFC3700
RFC3701 6bone (IPv6 Testing Address Allocation) Phaseout R. Fink R. Hinden March 2004 ASCII 12019 6 internet protocol protocotype software architecture

The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic. This memo provides information for the Internet community.

draft-fink-6bone-phaseout-04 RFC2471 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3701
RFC3702 Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) J. Loughney G. Camarillo February 2004 ASCII 31243 15

As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work. This memo provides information for the Internet community.

draft-ietf-sipping-aaa-req-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3702
RFC3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema J. Strassner B. Moore R. Moats E. Ellesson February 2004 ASCII 142983 61 mapping classes

This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol. This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information. These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. [STANDARDS-TRACK]

draft-ietf-policy-core-schema-16 RFC4104 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3703
RFC3704 Ingress Filtering for Multihomed Networks F. Baker P. Savola March 2004 ASCII 35942 16 ISP Internet Service Provider Internet Protocol DOS

BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-savola-bcp38-multihoming-update-03 RFC2827 BCP0084 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3704
RFC3705 High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals B. Ray R. Abbi February 2004 ASCII 24158 11 management information base

This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. [STANDARDS-TRACK]

draft-ietf-adslmib-hc-tc-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3705
RFC3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers G. Huang S. Beaulieu D. Rochefort February 2004 ASCII 30196 13 security authentication dead peer detection dpd keepalive

This document describes the method detecting a dead Internet Key Exchange (IKE) peer that is presently in use by a number of vendors. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources. This memo provides information for the Internet community.

draft-ietf-ipsec-dpd-04 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3706 10.17487/RFC3706
RFC3707 Cross Registry Internet Service Protocol (CRISP) Requirements A. Newton February 2004 ASCII 52411 26 directory services domain

Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. This memo provides information for the Internet community.

draft-ietf-crisp-requirements-06 INFORMATIONAL INFORMATIONAL IETF app crisp 10.17487/RFC3707
RFC3708 Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions E. Blanton M. Allman February 2004 ASCII 20818 9

TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-dsack-use-02 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3708
RFC3709 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates S. Santesson R. Housley T. Freeman February 2004 ASCII 46453 21 authentication security identification

This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS-TRACK]

draft-ietf-pkix-logotypes-13 RFC6170 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3709 10.17487/RFC3709
RFC3710 An IESG charter H. Alvestrand February 2004 ASCII 24912 12 internet engineering steering group

This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community.

draft-iesg-charter-03 RFC3932 RFC5742 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC3710
RFC3711 The Secure Real-time Transport Protocol (SRTP) M. Baugher D. McGrew M. Naslund E. Carrara K. Norrman March 2004 ASCII 134270 56 authentication traffic cryptographic

This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]

draft-ietf-avt-srtp-09 RFC5506 RFC6904 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3711 10.17487/RFC3711
RFC3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services P. Fleming I. McDonald February 2004 ASCII 62301 33 object classes attributes

This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). This memo provides information for the Internet community.

draft-fleming-ldap-printer-schema-02 RFC7612 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3712 10.17487/RFC3712
RFC3713 A Description of the Camellia Encryption Algorithm M. Matsui J. Nakajima S. Moriai April 2004 ASCII 25031 15 security key cryptographic

This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. This memo provides information for the Internet community.

draft-nakajima-camellia-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3713
RFC3714 IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet S. Floyd J. Kempf Editors March 2004 ASCII 81368 32 end-to-end qos qualify of service voip internet protocol

This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service (QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice over Internet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in the Internet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic. This memo provides information for the Internet community.

draft-iab-congestion-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3714
RFC3715 IPsec-Network Address Translation (NAT) Compatibility Requirements B. Aboba W. Dixon March 2004 ASCII 43476 18 virtual private networks vpns intranet

This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This memo provides information for the Internet community.

draft-ietf-ipsec-nat-reqts-06 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3715 10.17487/RFC3715
RFC3716 The IETF in the Large: Administration and Execution IAB Advisory Committee March 2004 ASCII 91326 40

In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF. The AdvComm mandate did not include the standards process itself. This memo provides information for the Internet community.

draft-iab-advcomm-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3716
RFC3717 IP over Optical Networks: A Framework B. Rajagopalan J. Luciani D. Awduche March 2004 ASCII 124421 48 transport infrastructure routers high-speed

The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks"). This memo provides information for the Internet community.

draft-ietf-ipo-framework-05 INFORMATIONAL INFORMATIONAL IETF subip ipo 10.17487/RFC3717
RFC3718 A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access R. McGowan February 2004 ASCII 25865 11

This memo describes various internal workings of the Unicode Consortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding & standardization processes.

draft-rmcgowan-unicode-procs-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3718
RFC3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) J. Parker Editor February 2004 ASCII 33941 15 routing routeing interior gateway protocol igp conformance ip traffic

This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic. This memo provides information for the Internet community.

draft-ietf-isis-iso-interoperable-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3719
RFC3720 Internet Small Computer Systems Interface (iSCSI) J. Satran K. Meth C. Sapuntzakis M. Chadalapaka E. Zeidner April 2004 ASCII 578468 257 transport protocol tcp transmission control protocol

This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model. SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-20 RFC7143 RFC3980 RFC4850 RFC5048 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3720 10.17487/RFC3720
RFC3721 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery M. Bakke J. Hafner J. Hufferd K. Voruganti M. Krueger April 2004 ASCII 47564 22 targets environments scalibilty target initiator scsi device name

This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. This memo provides information for the Internet community.

draft-ietf-ips-iscsi-name-disc-10 RFC7143 INFORMATIONAL INFORMATIONAL IETF tsv ips 10.17487/RFC3721
RFC3722 String Profile for Internet Small Computer Systems Interface (iSCSI) Names M. Bakke April 2004 ASCII 14702 8 transport unique global

This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-string-prep-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3722
RFC3723 Securing Block Storage Protocols over IP B. Aboba J. Tseng J. Walker V. Rangan F. Travostino April 2004 ASCII 171673 70 internet threat models performance security

This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed. [STANDARDS-TRACK]

draft-ietf-ips-security-19 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3723
RFC3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture J. Kempf R. Austein Editors IAB March 2004 ASCII 37206 14 architectural guideline

The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. This memo provides information for the Internet community.

draft-iab-e2e-futures-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3724
RFC3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) J. Rosenberg J. Peterson H. Schulzrinne G. Camarillo April 2004 ASCII 77308 31

Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-3pcc-06 BCP0085 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC3725
RFC3726 Requirements for Signaling Protocols M. Brunner Editor April 2004 ASCII 98020 42 rsvp resource reservation protocol middleboxes nsis

This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. This memo provides information for the Internet community.

draft-ietf-nsis-req-09 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC3726
RFC3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules S. Legg February 2004 ASCII 8297 5 lightweight directory access protocol

This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. [STANDARDS-TRACK]

draft-legg-ldap-cmr-module-00 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3727
RFC3728 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) B. Ray R. Abbi February 2004 ASCII 147232 76 management information base mib

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces. [STANDARDS-TRACK]

draft-ietf-adslmib-vdsl-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=3728 10.17487/RFC3728
RFC3729 Application Performance Measurement MIB S. Waldbusser March 2004 ASCII 131354 61

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for measuring the application performance as experienced by end-users. [STANDARDS-TRACK]

draft-ietf-rmonmib-apm-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3729
RFC3730 Extensible Provisioning Protocol (EPP) S. Hollenbeck March 2004 ASCII 134337 69 shared framework mapping

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. [STANDARDS-TRACK]

draft-ietf-provreg-epp-09 RFC4930 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg http://www.rfc-editor.org/errata_search.php?rfc=3730 10.17487/RFC3730
RFC3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck March 2004 ASCII 92527 45 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. [STANDARDS-TRACK]

draft-ietf-provreg-epp-domain-07 RFC4931 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3731
RFC3732 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck March 2004 ASCII 57082 28 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. [STANDARDS-TRACK]

draft-ietf-provreg-epp-host-07 RFC4932 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3732
RFC3733 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck March 2004 ASCII 83091 41 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. [STANDARDS-TRACK]

draft-ietf-provreg-epp-contact-07 RFC4933 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg http://www.rfc-editor.org/errata_search.php?rfc=3733 10.17487/RFC3733
RFC3734 Extensible Provisioning Protocol (EPP) Transport Over TCP S. Hollenbeck March 2004 ASCII 19550 9 mapping client server tls transport layer security

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. [STANDARDS-TRACK]

draft-ietf-provreg-epp-tcp-06 RFC4934 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3734
RFC3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP) S. Hollenbeck March 2004 ASCII 27326 13

The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities. This memo provides information for the Internet community.

draft-ietf-provreg-epp-ext-03 INFORMATIONAL INFORMATIONAL IETF app provreg 10.17487/RFC3735
RFC3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 R. Droms April 2004 ASCII 18510 9

Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-stateless-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3736 10.17487/RFC3736
RFC3737 IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules B. Wijnen A. Bierman April 2004 ASCII 13127 7 management information base internet assigned numbers authority

This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring (rmon) root. This memo also documents the currently assigned values. [STANDARDS-TRACK]

draft-ietf-rmonmib-rmon-oid-assignments-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3737
RFC3738 Wave and Equation Based Rate Control (WEBRC) Building Block M. Luby V. Goyal April 2004 ASCII 82584 32 congestion control data delivery multicast ip internet protocol

This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-webrc-04 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3738
RFC3739 Internet X.509 Public Key Infrastructure: Qualified Certificates Profile S. Santesson M. Nystrom T. Polk March 2004 ASCII 67436 34 syntax

This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons. The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates. However, the profile does not define any legal requirements for such Qualified Certificates. The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to Qualified Certificates and further profiling may facilitate specific local needs. [STANDARDS-TRACK]

draft-ietf-pkix-sonof3039-06 RFC3039 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3739 10.17487/RFC3739
RFC3740 The Multicast Group Security Architecture T. Hardjono B. Weis March 2004 ASCII 65531 26 data packets

This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. This memo provides information for the Internet community.

draft-ietf-msec-arch-05 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC3740
RFC3741 Exclusive XML Canonicalization, Version 1.0 J. Boyer D. Eastlake 3rd J. Reagle March 2004 ASCII 35403 16 extensible markup language namespace

Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the "xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. This memo provides information for the Internet community.

draft-ietf-xmldsig-xc14n-02 INFORMATIONAL INFORMATIONAL IETF sec xmldsig http://www.rfc-editor.org/errata_search.php?rfc=3741 10.17487/RFC3741
RFC3742 Limited Slow-Start for TCP with Large Congestion Windows S. Floyd March 2004 ASCII 14840 7 transmission control protocol

This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-slowstart-00 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3742 10.17487/RFC3742
RFC3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean K. Konishi K. Huang H. Qian Y. Ko April 2004 ASCII 74963 33

Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration. The IETF Standards for Internationalized Domain Names, known as "IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts. This memo provides information for the Internet community.

draft-jseng-idn-admin-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3743
RFC3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol G. Clemm J. Reschke E. Sedlar J. Whitehead May 2004 ASCII 146623 72

This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. [STANDARDS-TRACK]

draft-ietf-webdav-acl-13 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=3744 10.17487/RFC3744
RFC3745 MIME Type Registrations for JPEG 2000 (ISO/IEC 15444) D. Singer R. Clark D. Lee April 2004 ASCII 31224 14 multipurpose internet mail extensions joint photographic experts group

This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG 2000 (Joint Photographic Experts Group). [STANDARDS-TRACK]

draft-singer-jp2-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3745
RFC3746 Forwarding and Control Element Separation (ForCES) Framework L. Yang R. Dantu T. Anderson R. Gopal April 2004 ASCII 98660 40 network elements

This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions. This is memo provides information for the Internet community.

draft-ietf-forces-framework-13 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC3746
RFC3747 The Differentiated Services Configuration MIB H. Hazewinkel Editor D. Partain Editor April 2004 ASCII 51659 24 management information base diffserv

This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. [PROPOSED STANDARD]

draft-ietf-snmpconf-diffpolicy-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpconf 10.17487/RFC3747
RFC3748 Extensible Authentication Protocol (EAP) B. Aboba L. Blunk J. Vollbrecht J. Carlson H. Levkowetz Editor June 2004 ASCII 157994 67 PPP-EAP data link layers ppp point-to-point ieee 802

This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]

draft-ietf-eap-rfc2284bis-09 RFC2284 RFC5247 RFC7057 PROPOSED STANDARD PROPOSED STANDARD IETF int eap 10.17487/RFC3748
RFC3749 Transport Layer Security Protocol Compression Methods S. Hollenbeck May 2004 ASCII 16411 8 tls lossless data compression handshake protocol

The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]

draft-ietf-tls-compression-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3749
RFC3750 Unmanaged Networks IPv6 Transition Scenarios C. Huitema R. Austein S. Satapati R. van der Pol April 2004 ASCII 48153 20 single subnet gateway isp internet service provider

This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. This memo provides information for the Internet community.

draft-ietf-v6ops-unman-scenarios-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3750
RFC3751 Omniscience Protocol Requirements S. Bradner April 1 2004 ASCII 20771 9

There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts. This memo provides information for the Internet community.

draft-bradner-op-req-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3751
RFC3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios A. Barbir E. Burger R. Chen S. McHenry H. Orman R. Penno April 2004 ASCII 29481 14 application data services

This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. This memo provides information for the Internet community.

draft-ietf-opes-scenarios-01 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3752
RFC3753 Mobility Related Terminology J. Manner Editor M. Kojo Editor June 2004 ASCII 74143 36 networks ip internet protocol

There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology. This memo provides information for the Internet community.

draft-ietf-seamoby-mobility-terminology-06 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3753
RFC3754 IP Multicast in Differentiated Services (DS) Networks R. Bless K. Wehrle April 2004 ASCII 86533 34 internet protocol

This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results. This memo provides information for the Internet community.

draft-bless-diffserv-multicast-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3754
RFC3755 Legacy Resolver Compatibility for Delegation Signer (DS) S. Weiler May 2004 ASCII 19812 9 dnssec DNS Security rr resource record DNS-SECEXT dns authentication nsec nextsecure

As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-2535typecode-change-06 RFC4033 RFC4034 RFC4035 RFC3658 RFC2535 RFC3757 RFC3845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3755
RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats P. Nikander Editor J. Kempf E. Nordmark May 2004 ASCII 56674 23 authentication security key management

The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. This memo provides information for the Internet community.

draft-ietf-send-psreq-04 INFORMATIONAL INFORMATIONAL IETF int send http://www.rfc-editor.org/errata_search.php?rfc=3756 10.17487/RFC3756
RFC3757 Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag O. Kolkman J. Schlyter E. Lewis April 2004 ASCII 16868 8 dnssec

With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755. [STANDARDS-TRACK]

draft-ietf-dnsext-keyrr-key-signing-flag-12 RFC4033 RFC4034 RFC4035 RFC3755 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3757 10.17487/RFC3757
RFC3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension R. Stewart M. Ramalho Q. Xie M. Tuexen P. Conrad May 2004 ASCII 50999 22 init init ack forward tsn

This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism. [STANDARDS-TRACK]

draft-ietf-tsvwg-prsctp-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3758
RFC3759 RObust Header Compression (ROHC): Terminology and Channel Mapping Examples L-E. Jonsson April 2004 ASCII 50168 20 encapsulating security payload real-time transport protocol user datagram

This document aims to clarify terms and concepts presented in RFC 3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues. This memo provides information for the Internet community.

draft-ietf-rohc-terminology-and-examples-02 RFC3095 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3759
RFC3760 Securely Available Credentials (SACRED) - Credential Server Framework D. Gustafson M. Just M. Nystrom April 2004 ASCII 49910 22

As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework. This memo provides information for the Internet community.

draft-ietf-sacred-framework-07 INFORMATIONAL INFORMATIONAL IETF sec sacred 10.17487/RFC3760
RFC3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) P. Faltstrom M. Mealling April 2004 ASCII 41559 18 domain name system

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. [STANDARDS-TRACK]

draft-ietf-enum-rfc2916bis-07 RFC2916 RFC6116 RFC6117 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3761
RFC3762 Telephone Number Mapping (ENUM) Service Registration for H.323 O. Levin April 2004 ASCII 8450 5 multimedia packet based network

The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone Number Mapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. [STANDARDS-TRACK]

draft-ietf-enum-h323-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3762
RFC3763 One-way Active Measurement Protocol (OWAMP) Requirements S. Shalunov B. Teitelbaum April 2004 ASCII 23360 11 performance metrics delay unidirectional

With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This memo provides information for the Internet community.

draft-ietf-ippm-owdp-reqs-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3763
RFC3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record J. Peterson April 2004 ASCII 17604 8 aor electronic number

This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. [STANDARDS-TRACK]

draft-ietf-enum-sip-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3764
RFC3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control G. Huston April 2004 ASCII 16500 7 peer connections propagated

This document describes the use of a scope control Border Gateway Protocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. This memo provides information for the Internet community.

draft-ietf-ptomaine-nopeer-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3765
RFC3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys H. Orman P. Hoffman April 2004 ASCII 55939 23 security cryptography algorithms integers

Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage. While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-orman-public-key-lengths-08 BCP0086 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3766
RFC3767 Securely Available Credentials Protocol S. Farrell Editor June 2004 ASCII 49552 25 beep blocks extensible exchange protocol xml extensible mark up language

This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS-TRACK]

draft-ietf-sacred-protocol-bss-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec sacred 10.17487/RFC3767
RFC3768 Virtual Router Redundancy Protocol (VRRP) R. Hinden Editor April 2004 ASCII 59969 27 VRRP vrrp lan local area network ip internet protocol

This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK]

draft-ietf-vrrp-spec-v2-10 RFC2338 RFC5798 DRAFT STANDARD DRAFT STANDARD IETF rtg vrrp 10.17487/RFC3768
RFC3769 Requirements for IPv6 Prefix Delegation S. Miyakawa R. Droms June 2004 ASCII 10287 6 internet protocol version 6

This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site"). This memo provides information for the Internet community.

draft-ietf-ipv6-prefix-delegation-requirement-04 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3769
RFC3770 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) R. Housley T. Moore May 2004 ASCII 18635 9 ssid system service identifiers eap

This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). [STANDARDS-TRACK]

draft-ietf-pkix-wlan-extns-05 RFC4334 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3770 10.17487/RFC3770
RFC3771 The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message R. Harrison K. Zeilenga April 2004 ASCII 17114 8 LDAPv3 LDAv3 x.500

This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). The IntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAP ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. [STANDARDS-TRACK]

draft-rharrison-ldap-intermediate-resp-01 RFC4511 RFC4510 RFC2251 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3771
RFC3772 Point-to-Point Protocol (PPP) Vendor Protocol J. Carlson R. Winslow May 2004 ASCII 19846 10 link control protocol lcp

The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor-specific Network, Authentication, and Control Protocols. [STANDARDS-TRACK]

draft-ietf-pppext-vendor-protocol-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3772
RFC3773 High-Level Requirements for Internet Voice Mail E. Candell June 2004 ASCII 19156 9 ivm internet voice messaging voice profile for internet mail vpim

This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This document does not include goals that were met fully by VPIM version 2. This memo provides information for the Internet community.

draft-ietf-vpim-ivm-goals-06 INFORMATIONAL INFORMATIONAL IETF app vpim 10.17487/RFC3773
RFC3774 IETF Problem Statement E. Davies Editor May 2004 ASCII 55172 22 ietf process problem analysis

This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections. This memo provides information for the Internet community.

draft-ietf-problem-issue-statement-05 INFORMATIONAL INFORMATIONAL IETF gen problem 10.17487/RFC3774
RFC3775 Mobility Support in IPv6 D. Johnson C. Perkins J. Arkko June 2004 ASCII 393514 165 internet protocol nodes

This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. [STANDARDS-TRACK]

draft-ietf-mobileip-ipv6-24 RFC6275 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3775
RFC3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents J. Arkko V. Devarapalli F. Dupont June 2004 ASCII 87076 40 security internet protocol

Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. [STANDARDS-TRACK]

draft-ietf-mobileip-mipv6-ha-ipsec-06 RFC4877 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3776
RFC3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin Editor June 2004 ASCII 76395 34 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-nomcom-rfc2727bis-09 RFC2727 RFC7437 RFC5078 RFC5633 RFC5680 RFC6859 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen nomcom http://www.rfc-editor.org/errata_search.php?rfc=3777 10.17487/RFC3777
RFC3778 The application/pdf Media Type E. Taft J. Pravetz S. Zilles L. Masinter May 2004 ASCII 29891 14 portable document format document exchange digital signatures

PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. This memo provides information for the Internet community.

draft-zilles-pdf-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3778
RFC3779 X.509 Extensions for IP Addresses and AS Identifiers C. Lynn S. Kent K. Seo June 2004 ASCII 60732 27 allocation atrribute certificate authorization autonomous system number authorization certificate delegation internet registry ip address authorization public key infrastructure right-to-use secure allocation

This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]

draft-ietf-pkix-x509-ipaddr-as-extn-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3779 10.17487/RFC3779
RFC3780 SMIng - Next Generation Structure of Management Information F. Strauss J. Schoenwaelder May 2004 ASCII 141049 64 data definition language

This memo defines the base SMIng (Structure of Management Information, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-nmrg-sming-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3780
RFC3781 Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP) F. Strauss J. Schoenwaelder May 2004 ASCII 112267 49 data definition language

SMIng (Structure of Management Information, Next Generation) (RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-nmrg-sming-snmp-05 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3781 10.17487/RFC3781
RFC3782 The NewReno Modification to TCP's Fast Recovery Algorithm S. Floyd T. Henderson A. Gurtov April 2004 ASCII 49603 19 Transmission Control Protocol

The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status. The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno TCP. [STANDARDS-TRACK]

draft-ietf-tsvwg-newreno-02 RFC2582 RFC6582 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3782 10.17487/RFC3782
RFC3783 Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI M. Chadalapaka R. Elliott May 2004 ASCII 32358 14 Internet Small Computer Systems Interface iscsi

Internet Small Computer Systems Interface (iSCSI) is a Small Computer Systems Interface (SCSI) transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the classic SCSI "I_T nexus", which represents the logical relationship between an Initiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. This memo provides information for the Internet community.

draft-ietf-ips-command-ordering-02 INFORMATIONAL INFORMATIONAL IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3783 10.17487/RFC3783
RFC3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) H. Smit T. Li June 2004 ASCII 27422 13 link state protocol lsp

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. This memo provides information for the Internet community.

draft-ietf-isis-traffic-05 RFC5305 RFC4205 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3784
RFC3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric F. Le Faucheur R. Uppili A. Vedrenne P. Merckx T. Telkamp May 2004 ASCII 17475 8 link bandwidth router

This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-tewg-te-metric-igp-02 BCP0087 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF subip tewg 10.17487/RFC3785
RFC3786 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit A. Hermelin S. Previdi M. Shand May 2004 ASCII 29164 14

This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. This memo provides information for the Internet community.

draft-ietf-isis-ext-lsp-frags-02 RFC5311 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3786
RFC3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) J. Parker Editor May 2004 ASCII 25426 11 routing traffic

This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice. This memo provides information for the Internet community.

draft-ietf-isis-ip-interoperable-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3787
RFC3788 Security Considerations for Signaling Transport (SIGTRAN) Protocols J. Loughney M. Tuexen Editor J. Pastor-Balbas June 2004 ASCII 27125 13

This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional. [STANDARDS-TRACK]

draft-ietf-sigtran-security-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3788
RFC3789 Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 22842 10

This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-intro-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3789
RFC3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents C. Mickles Editor P. Nesser II June 2004 ASCII 102694 49

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-int-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3790
RFC3791 Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents C. Olvera P. Nesser II June 2004 ASCII 27567 15

This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-routing-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3791
RFC3792 Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 46398 25

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-sec-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3792
RFC3793 Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 11624 6

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-subip-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3793
RFC3794 Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 60001 31

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-trans-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3794
RFC3795 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents R. Sofia P. Nesser II June 2004 ASCII 92584 50

This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-apps-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3795
RFC3796 Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII 78400 43

This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-ops-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3796
RFC3797 Publicly Verifiable Nominations Committee (NomCom) Random Selection D. Eastlake 3rd June 2004 ASCII 39883 19 Internet Engineering Task Force IETF

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. This memo provides information for the Internet community.

draft-eastlake-rfc2777bis-selection-04 RFC2777 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3797
RFC3798 Message Disposition Notification T. Hansen Editor G. Vaudreuil Editor May 2004 ASCII 64049 30 EMF-MDN MDN media-type MIME multipurpose internet mail extensions

This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. [STANDARDS-TRACK]

draft-vaudreuil-mdnbis-05 RFC2298 RFC3461 RFC2046 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3798 10.17487/RFC3798
RFC3801 Voice Profile for Internet Mail - version 2 (VPIMv2) G. Vaudreuil G. Parsons June 2004 ASCII 118122 55 MIME-VP2 vpim messaging

This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems. This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM. [STANDARDS-TRACK]

draft-ietf-vpim-vpimv2r2-05 RFC2421 RFC2423 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3801
RFC3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration G. Vaudreuil G. Parsons June 2004 ASCII 11686 7 MIME-ADPCM multipurpose internet mail extensions audio

This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. [STANDARDS-TRACK]

draft-ietf-vpim-vpimv2r2-32k-03 RFC2422 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3802
RFC3803 Content Duration MIME Header Definition G. Vaudreuil G. Parsons June 2004 ASCII 8213 5 CONT-DUR multipurpose internet mail extensions time media

This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). [STANDARDS-TRACK]

draft-ietf-vpim-vpimv2r2-dur-03 RFC2424 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3803
RFC3804 Voice Profile for Internet Mail (VPIM) Addressing G. Parsons June 2004 ASCII 26122 15 formats

This document lists the various Voice Profile for Internet Mail (VPIM) email address formats that are currently in common use and defines several new address formats for special case usage. Requirements are imposed on the formats of addresses used in VPIM submission mode. [STANDARDS-TRACK]

draft-ietf-vpim-address-03 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3804
RFC3805 Printer MIB v2 R. Bergman H. Lewis I. McDonald June 2004 ASCII 366952 171 Print-MIB Management Information Base snmp management

This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759. [STANDARDS-TRACK]

draft-ietf-printmib-mib-info-15 RFC1759 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3805
RFC3806 Printer Finishing MIB R. Bergman H. Lewis I. McDonald June 2004 ASCII 109654 53 finisher snmp

This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a Printer System. This memo provides information for the Internet community.

draft-ietf-printmib-finishing-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3806
RFC3807 V5.2-User Adaptation Layer (V5UA) E. Weilandt N. Khanchandani S. Rao June 2004 ASCII 49748 24 v5 v5.1 v5.2 backhauling imap sctp isdn access network c-path c-channel efa envelope function address lapv5 pstn v5ptm mgc gateway controller gateway

This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface. This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. [STANDARDS-TRACK]

draft-ietf-sigtran-v5ua-04 RFC3057 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3807
RFC3808 IANA Charset MIB I. McDonald June 2004 ASCII 25245 14 management information base IANACharset

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used by IANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset Registration Procedures (RFC 2978). This memo provides information for the Internet community.

draft-mcdonald-iana-charset-mib-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3808
RFC3809 Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN) A. Nagarajan Editor June 2004 ASCII 60576 25 service engineering

This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. This memo provides information for the Internet community.

draft-ietf-l3vpn-generic-reqts-03 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC3809
RFC3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 R. Vida Editor L. Costa Editor June 2004 ASCII 153579 62 ssm source filtering igmp group management mld

This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]

draft-vida-mld-v2-08 RFC2710 RFC4604 PROPOSED STANDARD PROPOSED STANDARD IETF int magma 10.17487/RFC3810
RFC3811 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management T. Nadeau Editor J. Cucchiara Editor June 2004 ASCII 40353 20 management information base

This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-mpls-tc-mib-10 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3811 10.17487/RFC3811
RFC3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) C. Srinivasan A. Viswanathan T. Nadeau June 2004 ASCII 136475 68

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). [STANDARDS-TRACK]

draft-ietf-mpls-te-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3812
RFC3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) C. Srinivasan A. Viswanathan T. Nadeau June 2004 ASCII 116120 60

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). [STANDARDS-TRACK]

draft-ietf-mpls-lsr-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3813 10.17487/RFC3813
RFC3814 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) T. Nadeau C. Srinivasan A. Viswanathan June 2004 ASCII 87518 42

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]

draft-ietf-mpls-ftn-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3814
RFC3815 Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) J. Cucchiara H. Sjostrand J. Luciani June 2004 ASCII 215916 106

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). [STANDARDS-TRACK]

draft-ietf-mpls-ldp-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3815 10.17487/RFC3815
RFC3816 Definitions of Managed Objects for RObust Header Compression (ROHC) J. Quittek M. Stiemerling H. Hartenstein June 2004 ASCII 104947 53 mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. [STANDARDS-TRACK]

draft-ietf-rohc-mib-rtp-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=3816 10.17487/RFC3816
RFC3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) W. Townsley R. da Silva June 2004 ASCII 37765 17 point-to-point

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet. L2TP Active Discovery Relay for PPPoE describes a method to relay Active Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs (AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP. This memo provides information for the Internet community.

draft-dasilva-l2tp-relaysvc-08 INFORMATIONAL INFORMATIONAL IETF int l2tpext 10.17487/RFC3817
RFC3818 IANA Considerations for the Point-to-Point Protocol (PPP) V. Schryver June 2004 ASCII 6321 4

The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served." This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-schryver-pppext-iana-01 BCP0088 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int pppext 10.17487/RFC3818
RFC3819 Advice for Internet Subnetwork Designers P. Karn Editor C. Bormann G. Fairhurst D. Grossman R. Ludwig J. Mahdavi G. Montenegro J. Touch L. Wood July 2004 ASCII 152174 60 digital communication equipment link-layer protocols packet-switched local networks

This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-link-design-15 BCP0089 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc http://www.rfc-editor.org/errata_search.php?rfc=3819 10.17487/RFC3819
RFC3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile S. Tuecke V. Welch D. Engert L. Pearlman M. Thompson June 2004 ASCII 86374 37 authentication security credentials restricted delegation single-signon delegation of rights

This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. [STANDARDS-TRACK]

draft-ietf-pkix-proxy-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3820 10.17487/RFC3820
RFC3821 Fibre Channel Over TCP/IP (FCIP) M. Rajagopal E. Rodriguez R. Weber July 2004 ASCII 165907 74 storage area networks IP-based networks unified storage area network

Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. [STANDARDS-TRACK]

draft-ietf-ips-fcovertcpip-12 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3821
RFC3822 Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2) D. Peterson July 2004 ASCII 22859 11 dynamic discovery

This document defines the use of Service Location Protocol version 2 (SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. [STANDARDS-TRACK]

draft-ietf-ips-fcip-slp-09 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3822 10.17487/RFC3822
RFC3823 MIME Media Type for the Systems Biology Markup Language (SBML) B. Kovitz June 2004 ASCII 14577 8 sub-type application/sbml+xml systems biology community

This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community. This memo provides information for the Internet community.

draft-sbml-media-type-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3823
RFC3824 Using E.164 numbers with the Session Initiation Protocol (SIP) J. Peterson H. Liu J. Yu B. Campbell June 2004 ASCII 36535 16 telephone records applications

There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. This memo provides information for the Internet community.

draft-ietf-sipping-e164-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3824
RFC3825 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information J. Polk J. Schnizlein M. Linsner July 2004 ASCII 31715 15 dhcp lci geographic location

This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included. [STANDARDS-TRACK]

draft-ietf-geopriv-dhcp-lci-option-03 RFC6225 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC3825
RFC3826 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model U. Blumenthal F. Maino K. McCloghrie June 2004 ASCII 32821 16 management information base simple network management protocol

This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]

draft-blumenthal-aes-usm-08 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3826
RFC3827 Additional Snoop Datalink Types K. Sarcar June 2004 ASCII 6344 4

The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media. This memo provides information for the Internet community.

draft-sarcar-snoop-new-types-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3827
RFC3828 The Lightweight User Datagram Protocol (UDP-Lite) L-A. Larzon M. Degermark S. Pink L-E. Jonsson Editor G. Fairhurst Editor July 2004 ASCII 27193 12

This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. [STANDARDS-TRACK]

draft-ietf-tsvwg-udp-lite-02 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3828
RFC3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls R. Weltman M. Smith M. Wahl July 2004 ASCII 11986 6 bind operation

This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation. This memo provides information for the Internet community.

draft-weltman-ldapv3-auth-response-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3829 10.17487/RFC3829
RFC3830 MIKEY: Multimedia Internet KEYing J. Arkko E. Carrara F. Lindholm M. Naslund K. Norrman August 2004 ASCII 145238 66 key management scheme real-time applications

This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail. Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. [STANDARDS-TRACK]

draft-ietf-msec-mikey-08 RFC4738 RFC6309 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=3830 10.17487/RFC3830
RFC3831 Transmission of IPv6 Packets over Fibre Channel C. DeSanti July 2004 ASCII 53328 24 addresses link-local internet protocol

This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. [STANDARDS-TRACK]

draft-ietf-imss-ipv6-over-fibre-channel-02 RFC4338 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC3831
RFC3832 Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV W. Zhao H. Schulzrinne E. Guttman C. Bisdikian W. Jerome July 2004 ASCII 15602 8 DNS-SRV domain name system resource record

Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. This memo defines an Experimental Protocol for the Internet community.

draft-zhao-slp-remote-da-discovery-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3832
RFC3833 Threat Analysis of the Domain Name System (DNS) D. Atkins R. Austein August 2004 ASCII 39303 16 data disclosure security authentication

Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community.

draft-ietf-dnsext-dns-threats-07 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC3833
RFC3834 Recommendations for Automatic Responses to Electronic Mail K. Moore August 2004 ASCII 53119 22 automatic mail responders

This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. [STANDARDS-TRACK]

draft-moore-auto-email-response-05 RFC5436 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3834 10.17487/RFC3834
RFC3835 An Architecture for Open Pluggable Edge Services (OPES) A. Barbir R. Penno R. Chen M. Hofmann H. Orman August 2004 ASCII 36113 17 application service data stream service data consumer data dispatcher architecture

This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. This memo provides information for the Internet community.

draft-ietf-opes-architecture-04 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3835
RFC3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols A. Beck M. Hofmann H. Orman R. Penno A. Terzis August 2004 ASCII 28438 13 callout protocol remote execution OPES services

This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols. This memo provides information for the Internet community.

draft-ietf-opes-protocol-reqs-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3836
RFC3837 Security Threats and Risks for Open Pluggable Edge Services (OPES) A. Barbir O. Batuner B. Srinivas M. Hofmann H. Orman August 2004 ASCII 31883 14 threat discovery threat analysis

The document investigates the security threats associated with the Open Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. This memo provides information for the Internet community.

draft-ietf-opes-threats-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3837
RFC3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES) A. Barbir O. Batuner A. Beck T. Chan H. Orman August 2004 ASCII 38739 17 opes flow

This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow. This memo provides information for the Internet community.

draft-ietf-opes-authorization-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3838
RFC3839 MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files R. Castagno D. Singer July 2004 ASCII 15645 7 standard MIME types 3GPP multimedia file format ISO Media File Format

This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

draft-singer-avt-3gpp-mime-01 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3839
RFC3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne P. Kyzivat August 2004 ASCII 81360 36 ua contact header field

This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS-TRACK]

draft-ietf-sip-callee-caps-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3840
RFC3841 Caller Preferences for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne P. Kyzivat August 2004 ASCII 61382 26 Uniform Resource Identifiers URI Accept-Contact Reject-Contact Request-Disposition

This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences. [STANDARDS-TRACK]

draft-ietf-sip-callerprefs-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3841
RFC3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) R. Mahy August 2004 ASCII 36877 19 message waiting status message summary

This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. [STANDARDS-TRACK]

draft-ietf-sipping-mwi-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3842
RFC3843 RObust Header Compression (ROHC): A Compression Profile for IP L-E. Jonsson G. Pelletier June 2004 ASCII 33549 16 compression protocols

The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. [STANDARDS-TRACK]

draft-ietf-rohc-ip-only-05 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3843
RFC3844 IETF Problem Resolution Process E. Davies J. Hofmann Editors August 2004 ASCII 44841 20 ietf process problem analysis

This Informational document records the history of discussions in the Problem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes. The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG. While there was working group consensus on the processes for short-term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group. This memo provides information for the Internet community.

draft-ietf-problem-process-04 INFORMATIONAL INFORMATIONAL IETF gen problem 10.17487/RFC3844
RFC3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format J. Schlyter Editor August 2004 ASCII 14793 7 dnssec DNS Security rr resource record DNS-SECEXT dns authentication nsec nextsecure

This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. [STANDARDS-TRACK]

draft-ietf-dnsext-nsec-rdata-06 RFC4033 RFC4034 RFC4035 RFC3755 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3845
RFC3846 Mobile IPv4 Extension for Carrying Network Access Identifiers F. Johansson T. Johansson June 2004 ASCII 16834 8 nai internet protocol home aaa server ha server home agents

When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multiple Authentication Authorization and Accounting (AAA) servers and Home Agents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of the Home AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes. [STANDARDS-TRACK]

draft-ietf-mip4-aaa-nai-02 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC3846
RFC3847 Restart Signaling for Intermediate System to Intermediate System (IS-IS) M. Shand L. Ginsberg July 2004 ASCII 50023 21 LSP database synchronization transient routing disruption database synchronization

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This memo provides information for the Internet community.

draft-ietf-isis-restart-05 RFC5306 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3847
RFC3848 ESMTP and LMTP Transmission Types Registration C. Newman July 2004 ASCII 7916 4 smtp simple mail transfer protocol

This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message. [STANDARDS-TRACK]

draft-newman-esmtpsa-01 DRAFT STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3848
RFC3849 IPv6 Address Prefix Reserved for Documentation G. Huston A. Lord P. Smith July 2004 ASCII 7872 4 unicast site-local link-local

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. This memo provides information for the Internet community.

draft-huston-ipv6-documentation-prefix-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3849
RFC3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling B. Ramsdell Editor July 2004 ASCII 37446 16 x.509 encryption certificate multipurpose internet mail extensions secure

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. [STANDARDS-TRACK]

draft-ietf-smime-rfc2632bis-07 RFC2632 RFC5750 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3850
RFC3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification B. Ramsdell Editor July 2004 ASCII 53328 36 secure multipurpose internet mail extensions encryption

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. [STANDARDS-TRACK]

draft-ietf-smime-rfc2633bis-09 RFC2633 RFC5751 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3851
RFC3852 Cryptographic Message Syntax (CMS) R. Housley July 2004 ASCII 15541 56 digitally sign authenticate encrypt arbitrary message content

This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]

draft-ietf-smime-rfc3369bis-04 RFC3369 RFC5652 RFC4853 RFC5083 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3852 10.17487/RFC3852
RFC3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP) J. Peterson July 2004 ASCII 10687 6 SIP application-layer application layer multimedia multicast unicast

RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME. [STANDARDS-TRACK]

draft-ietf-sip-smime-aes-01 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3853
RFC3854 Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME) P. Hoffman C. Bonatti A. Eggen July 2004 ASCII 32801 15 encryption cryptographic signature

This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/Multipurpose Internet Mail Extensions (S/MIME). [STANDARDS-TRACK]

draft-ietf-smime-x400wrap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3854
RFC3855 Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400 P. Hoffman C. Bonatti July 2004 ASCII 25774 12 cms cryptographic message syntax message

This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system. [STANDARDS-TRACK]

draft-ietf-smime-x400transport-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3855
RFC3856 A Presence Event Package for the Session Initiation Protocol (SIP) J. Rosenberg August 2004 ASCII 62956 27 subscription notification

This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. [STANDARDS-TRACK]

draft-ietf-simple-presence-10 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3856 10.17487/RFC3856
RFC3857 A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) J. Rosenberg August 2004 ASCII 46221 20

This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. [STANDARDS-TRACK]

draft-ietf-simple-winfo-package-05 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3857
RFC3858 An Extensible Markup Language (XML) Based Format for Watcher Information J. Rosenberg August 2004 ASCII 26416 13 xml

Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an Extensible Markup Language (XML) document format for such state. [STANDARDS-TRACK]

draft-ietf-simple-winfo-format-04 PROPOSED STANDARD PROPOSED STANDARD INDEPENDENT 10.17487/RFC3858
RFC3859 Common Profile for Presence (CPP) J. Peterson August 2004 ASCII 30537 15 data formats semantics instant messaging

At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. [STANDARDS-TRACK]

draft-ietf-impp-pres-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3859
RFC3860 Common Profile for Instant Messaging (CPIM) J. Peterson August 2004 ASCII 26486 13 data formats semantics instant messaging

At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. [STANDARDS-TRACK]

draft-ietf-impp-im-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3860
RFC3861 Address Resolution for Instant Messaging and Presence J. Peterson August 2004 ASCII 15764 8 uri schemes universal resource identifier impp instant messaging and presence protocol presentity instant inbox

Presence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS-TRACK]

draft-ietf-impp-srv-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3861
RFC3862 Common Presence and Instant Messaging (CPIM): Message Format G. Klyne D. Atkins August 2004 ASCII 56133 30 instant messaging and presence protocol message/cpim

This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. [STANDARDS-TRACK]

draft-ietf-impp-cpim-msgfmt-09 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3862 10.17487/RFC3862
RFC3863 Presence Information Data Format (PIDF) H. Sugano S. Fujimoto G. Klyne A. Bateman W. Carr J. Peterson August 2004 ASCII 56956 28 instant messaging and presence protocol cpp common profile for presence presence data format application/pidf+xml

This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type "application/pidf+xml" to represent the XML MIME entity for PIDF. [STANDARDS-TRACK]

draft-ietf-impp-cpim-pidf-08 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3863 10.17487/RFC3863
RFC3864 Registration Procedures for Message Header Fields G. Klyne M. Nottingham J. Mogul September 2004 ASCII 36231 17 Internet mail HTTP Netnews

This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klyne-msghdr-registry-07 BCP0090 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3864
RFC3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension C. Malamud September 2004 ASCII 40717 19 unsolicited bulk email ube no soliciting solicitation class keywords solicitation mail header trace fields

This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. [STANDARDS-TRACK]

draft-malamud-no-soliciting-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3865
RFC3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga Editor July 2004 ASCII 31501 15 lightweight directory access protocol servers

It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). [STANDARDS-TRACK]

draft-zeilenga-ldap-rfc2596-05 RFC2596 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3866 10.17487/RFC3866
RFC3867 Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP) Y. Kawatsura M. Hiroya H. Beykirch November 2004 ASCII 234572 106 modules data format exchange

The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.

This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores.

Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1.0-papi-06 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3867
RFC3868 Signalling Connection Control Part User Adaptation Layer (SUA) J. Loughney Editor G. Sidebottom L. Coene G. Verwimp J. Keller B. Bidulock October 2004 ASCII 294116 131 sctp stream control transmission protocol modular symmetric signalling gateway signalling endpoint architecture

This document defines a protocol for the transport of any Signalling Connection Control Part-User signalling over IP using the Stream Control Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture. [STANDARDS-TRACK]

draft-ietf-sigtran-sua-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3868
RFC3869 IAB Concerns and Recommendations Regarding Internet Research and Evolution R. Atkinson Editor S. Floyd Editor Internet Architecture Board August 2004 ASCII 78250 30 internet architecture board internet infrastructure non-commercial funding

This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. This memo provides information for the Internet community.

draft-iab-research-funding-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3869
RFC3870 application/rdf+xml Media Type Registration A. Swartz September 2004 ASCII 14195 8 xml extensible markup language mime multipurpose internet mail extensions rdf resource description framework

This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of the Resource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization. This memo provides information for the Internet community.

draft-swartz-rdfcore-rdfxml-mediatype-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3870
RFC3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure G. Jones Editor September 2004 ASCII 151101 81

This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. This memo provides information for the Internet community.

draft-jones-opsec-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3871
RFC3872 Management Information Base for Telephony Routing over IP (TRIP) D. Zinman D. Walker J. Jiang September 2004 ASCII 98614 53 mib

This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices. [STANDARDS-TRACK]

draft-ietf-iptel-trip-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC3872
RFC3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB) J. Pastor M. Belinchon September 2004 ASCII 82403 46

The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications.

This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. [STANDARDS-TRACK]

draft-ietf-sigtran-sctp-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3873
RFC3874 A 224-bit One-way Hash Function: SHA-224 R. Housley September 2004 ASCII 11600 6 secure standard

This document specifies a 224-bit one-way hash function, called SHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits. This memo provides information for the Internet community.

draft-ietf-pkix-sha224-01 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3874
RFC3875 The Common Gateway Interface (CGI) Version 1.1 D. Robinson K. Coar October 2004 ASCII 80728 36 PDF 121026 www world wide web

The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.

The interface has been in use by the World-Wide Web (WWW) since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. This memo provides information for the Internet community.

draft-coar-cgi-v11-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3875 10.17487/RFC3875
RFC3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3) D. Chadwick S. Mullan September 2004 ASCII 24233 12 attribute filter

This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. [STANDARDS-TRACK]

draft-ietf-ldapext-matchedval-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3876
RFC3877 Alarm Management Information Base (MIB) S. Chisholm D. Romascanu September 2004 ASCII 149783 75 alarm mib iana-itu-alarm-tc-mib itu-alarm-tc-mib itu-alarm-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for modelling and storing alarms. [STANDARDS-TRACK]

draft-ietf-disman-alarm-mib-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=3877 10.17487/RFC3877
RFC3878 Alarm Reporting Control Management Information Base (MIB) H. Lam A. Huynh D. Perkins September 2004 ASCII 31093 16 alarm condition probably cause

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. [STANDARDS-TRACK]

draft-ietf-disman-conditionmib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3878
RFC3879 Deprecating Site Local Addresses C. Huitema B. Carpenter September 2004 ASCII 24142 10 ipv6 architecture

This document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. [STANDARDS-TRACK]

draft-ietf-ipv6-deprecate-site-local-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3879
RFC3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services J. Lennox X. Wu H. Schulzrinne October 2004 ASCII 154991 74

This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. [STANDARDS-TRACK]

draft-ietf-iptel-cpl-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC3880
RFC3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications G. Marshall September 2004 ASCII 86130 47

This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data. This memo provides information for the Internet community.

draft-marshall-security-audit-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3881
RFC3882 Configuring BGP to Block Denial-of-Service Attacks D. Turk September 2004 ASCII 19637 8 dos border gateway protocol

This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. This memo provides information for the Internet community.

draft-turk-bgp-dos-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3882
RFC3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC) S. Rao A. Zinin A. Roy October 2004 ASCII 13100 6 OSPF-DC Open Shortest Path First

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to minimize the amount of overhead traffic. A part of the OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem. [STANDARDS-TRACK]

draft-ietf-ospf-dc-07 RFC1793 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3883
RFC3884 Use of IPsec Transport Mode for Dynamic Routing J. Touch L. Eggert Y. Wang September 2004 ASCII 59437 25

IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). This memo provides information for the Internet community.

draft-touch-ipsec-vpn-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3884
RFC3885 SMTP Service Extension for Message Tracking E. Allman T. Hansen September 2004 ASCII 17458 9 simple mail transfer protocol

This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS-TRACK]

draft-ietf-msgtrk-smtpext-05 RFC3461 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk 10.17487/RFC3885
RFC3886 An Extensible Message Format for Message Tracking Responses E. Allman September 2004 ASCII 21746 11 Delivery Status Notifications DSN Message Disposition Notifications MDN

Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.

This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo. [STANDARDS-TRACK]

draft-ietf-msgtrk-trkstat-05 RFC3463 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk http://www.rfc-editor.org/errata_search.php?rfc=3886 10.17487/RFC3886
RFC3887 Message Tracking Query Protocol T. Hansen September 2004 ASCII 42763 23 mtqp ESMTP

Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. [STANDARDS-TRACK]

draft-ietf-msgtrk-mtqp-12 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk http://www.rfc-editor.org/errata_search.php?rfc=3887 10.17487/RFC3887
RFC3888 Message Tracking Model and Requirements T. Hansen September 2004 ASCII 20950 11

Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. This memo provides information for the Internet community.

draft-ietf-msgtrk-model-07 INFORMATIONAL INFORMATIONAL IETF app msgtrk 10.17487/RFC3888
RFC3889 RFC3890 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) M. Westerlund September 2004 ASCII 49894 22 tias application specific maximum

This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.

The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-bwparam-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3890
RFC3891 The Session Initiation Protocol (SIP) "Replaces" Header R. Mahy B. Biggs R. Dean September 2004 ASCII 34180 16 multi-party applications call control

This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative. [STANDARDS-TRACK]

draft-ietf-sip-replaces-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3891 10.17487/RFC3891
RFC3892 The Session Initiation Protocol (SIP) Referred-By Mechanism R. Sparks September 2004 ASCII 52441 25 REFER

The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. [STANDARDS-TRACK]

draft-ietf-sip-referredby-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3892
RFC3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format J. Peterson September 2004 ASCII 28500 13 authenticated identity body digitally-signed SIP message message fragment Authenticated Identity Bodies AIB

RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. [STANDARDS-TRACK]

draft-ietf-sip-authid-body-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3893
RFC3894 Sieve Extension: Copying Without Side Effects J. Degener October 2004 ASCII 9018 5 client server

The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox". Actions such as "fileinto" and "redirect" cancel this default behavior.

This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script. [STANDARDS-TRACK]

draft-degener-sieve-copy-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3894
RFC3895 Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types O. Nicklass Editor September 2004 ASCII 163841 84 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2495. [STANDARDS-TRACK]

draft-ietf-atommib-rfc2495bis-06 RFC2495 RFC4805 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3895
RFC3896 Definitions of Managed Objects for the DS3/E3 Interface Type O. Nicklass Editor September 2004 ASCII 129547 63 DS3-E3-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2496. [STANDARDS-TRACK]

draft-ietf-atommib-rfc2496bis-06 RFC2496 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3896
RFC3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication A. Barbir September 2004 ASCII 33890 14 tracing non-blocking bypass

This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). This memo provides information for the Internet community.

draft-ietf-opes-end-comm-08 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3897
RFC3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) V. Kalusivalingam October 2004 ASCII 13955 7 NIS Servers NIS+ Servers NIS Client Domain Name NIS+ Client Domain name

This document describes four options for Network Information Service (NIS) related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-opt-nisconfig-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3898
RFC3901 DNS IPv6 Transport Operational Guidelines A. Durand J. Ihren September 2004 ASCII 10025 5 domain name system internet protocol

This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsop-ipv6-transport-guidelines-02 BCP0091 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC3901
RFC3902 The "application/soap+xml" media type M. Baker M. Nottingham September 2004 ASCII 10575 5

This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. This memo provides information for the Internet community.

draft-baker-soap-media-reg-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3902
RFC3903 Session Initiation Protocol (SIP) Extension for Event State Publication A. Niemi Editor October 2004 ASCII 72062 32 presence information package

This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. [STANDARDS-TRACK]

draft-ietf-sip-publish-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3903
RFC3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks C. Huitema R. Austein S. Satapati R. van der Pol September 2004 ASCII 46844 19 home office internet protocol

This document analyzes issues involved in the transition of "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed. This memo provides information for the Internet community.

draft-ietf-v6ops-unmaneval-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3904
RFC3905 A Template for IETF Patent Disclosures and Licensing Declarations V. See Editor September 2004 ASCII 16110 9 ipr

This document describes a proposal for one form of a template for IETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668. This memo provides information for the Internet community.

draft-ietf-ipr-template-09 INFORMATIONAL INFORMATIONAL IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=3905 10.17487/RFC3905
RFC3906 Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels N. Shen H. Smit October 2004 ASCII 18410 8 hop-by-hop link-state routing protocols SPF shortest path first

This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering. This memo provides information for the Internet community.

draft-ietf-rtgwg-igp-shortcut-01 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC3906
RFC3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation K. Zeilenga October 2004 ASCII 13423 7 abandon operation outstanding operation

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. [STANDARDS-TRACK]

draft-zeilenga-ldap-cancel-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3909
RFC3910 The SPIRITS (Services in PSTN requesting Internet Services) Protocol V. Gurbani Editor A. Brusilovsky I. Faynberg J. Gato H. Lu M. Unmehopa October 2004 ASCII 110515 50 pstn sip services event notification eventpackages internet call waiting xml wireless intelligent network in detection point dp

This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built. [STANDARDS-TRACK]

draft-ietf-spirits-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv spirits 10.17487/RFC3910
RFC3911 The Session Initiation Protocol (SIP) "Join" Header R. Mahy D. Petrie October 2004 ASCII 35373 17

This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring". Note that definition of these example features is non-normative. [STANDARDS-TRACK]

draft-ietf-sip-join-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3911
RFC3912 WHOIS Protocol Specification L. Daigle September 2004 ASCII 7770 4 NICNAME

This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK]

draft-daigle-rfc954bis-01 RFC0954 RFC0812 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3912
RFC3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification D. Thaler September 2004 ASCII 97443 41 enter-domain source-specific multicast ssm

This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants. This memo provides information for the Internet community.

draft-ietf-bgmp-spec-06 HISTORIC INFORMATIONAL IETF rtg bgmp 10.17487/RFC3913
RFC3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations A. Barbir A. Rousskov October 2004 ASCII 37411 16

IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. This memo provides information for the Internet community.

draft-ietf-opes-iab-05 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3914
RFC3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck September 2004 ASCII 45467 23 dns name system

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. [STANDARDS-TRACK]

draft-hollenbeck-epp-rgp-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3915
RFC3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) X. Xiao Editor D. McPherson Editor P. Pate Editor September 2004 ASCII 43856 19

This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. This memo provides information for the Internet community.

draft-ietf-pwe3-requirements-08 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC3916
RFC3917 Requirements for IP Flow Information Export (IPFIX) J. Quittek T. Zseby B. Claise S. Zander October 2004 ASCII 81615 33 ipfix routers measurment middleboxes

This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. This memo provides information for the Internet community.

draft-ietf-ipfix-reqs-16 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC3917
RFC3918 Methodology for IP Multicast Benchmarking D. Stopp B. Hickman October 2004 ASCII 64652 31

The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.

The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. This memo provides information for the Internet community.

draft-ietf-bmwg-mcastm-14 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3918
RFC3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS) E. Stephan J. Palet October 2004 ASCII 14228 8 mib

This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895].

This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information. This memo provides information for the Internet community.

draft-ietf-rmonmib-pi-ipv6-04 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC3919
RFC3920 Extensible Messaging and Presence Protocol (XMPP): Core P. Saint-Andre Editor October 2004 ASCII 194313 30 instant messaging im extensible markup language xml jabber

This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]

draft-ietf-xmpp-core-24 RFC6120 RFC6122 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp http://www.rfc-editor.org/errata_search.php?rfc=3920 10.17487/RFC3920
RFC3921 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence P. Saint-Andre Editor October 2004 ASCII 217527 107 instant messaging im extensible markup language xml jabber

This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. [STANDARDS-TRACK]

draft-ietf-xmpp-im-22 RFC6121 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp 10.17487/RFC3921
RFC3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) P. Saint-Andre October 2004 ASCII 70790 34 xml extensible markup language im instant messaging jabber

This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS-TRACK]

draft-ietf-xmpp-cpim-05 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp 10.17487/RFC3922
RFC3923 End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre October 2004 ASCII 51828 27 xml extensible markup language im instant messaging jabber

This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

draft-ietf-xmpp-e2e-09 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp http://www.rfc-editor.org/errata_search.php?rfc=3923 10.17487/RFC3923
RFC3924 Cisco Architecture for Lawful Intercept in IP Networks F. Baker B. Foster C. Sharp October 2004 ASCII 40826 18

For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. This memo provides information for the Internet community.

draft-baker-slem-architecture-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3924
RFC3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) J. Littlefield October 2004 ASCII 17999 9 dhc dhcp class vendor-specific

The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. [STANDARDS-TRACK]

draft-ietf-dhc-vendor-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3925
RFC3926 FLUTE - File Delivery over Unidirectional Transport T. Paila M. Luby R. Lehtonen V. Roca R. Walsh October 2004 ASCII 81224 35

This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-flute-08 RFC6726 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=3926 10.17487/RFC3926
RFC3927 Dynamic Configuration of IPv4 Link-Local Addresses S. Cheshire B. Aboba E. Guttman May 2005 ASCII 83102 33 ip network ip address 169.254/16

To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.

IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK]

draft-ietf-zeroconf-ipv4-linklocal-17 PROPOSED STANDARD PROPOSED STANDARD IETF int zeroconf 10.17487/RFC3927
RFC3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP) R. Megginson Editor M. Smith O. Natkovich J. Parham October 2004 ASCII 36892 30

This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [STANDARDS-TRACK]

draft-ietf-ldup-lcup-06 PROPOSED STANDARD PROPOSED STANDARD IETF app ldup 10.17487/RFC3928
RFC3929 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF T. Hardie October 2004 ASCII 26493 11

This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community.

draft-hardie-alt-consensus-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3929 10.17487/RFC3929
RFC3930 The Protocol versus Document Points of View in Computer Protocols D. Eastlake 3rd October 2004 ASCII 36892 15

This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. This memo provides information for the Internet community.

draft-eastlake-proto-doc-pov-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3930
RFC3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3) J. Lau Editor M. Townsley Editor I. Goyret Editor March 2005 ASCII 214407 94 L2TP ppp point-to-point protocol packets

This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]

draft-ietf-l2tpext-l2tp-base-15 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=3931 10.17487/RFC3931
RFC3932 The IESG and RFC Editor Documents: Procedures H. Alvestrand October 2004 ASCII 17093 8 independent submission

This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.

This document updates procedures described in RFC 2026 and RFC 3710. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iesg-rfced-documents-03 RFC5742 RFC2026 RFC3710 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC3932
RFC3933 A Model for IETF Process Experiments J. Klensin S. Dawkins November 2004 ASCII 14409 7

The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight. This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klensin-process-july14-02 BCP0093 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3933 10.17487/RFC3933
RFC3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists M. Wasserman October 2004 ASCII 8488 5 BCP WG escape clause procedures

This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-wasserman-rfc2418-ml-update-01 RFC2418 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3934
RFC3935 A Mission Statement for the IETF H. Alvestrand October 2004 ASCII 16639 7

This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-alvestrand-ietf-mission-02 BCP0095 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3935
RFC3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP) K. Kompella J. Lang October 2004 ASCII 15314 7 resource reservation protocol label switched paths

This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-kompella-rsvp-change-02 RFC3209 RFC2205 BCP0096 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3936
RFC3937 A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC) M. Steidl October 2004 ASCII 15458 9

This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council (IPTC). These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. This memo provides information for the Internet community.

draft-steidl-iptc-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3937
RFC3938 Video-Message Message-Context T. Hansen October 2004 ASCII 6224 4 user agent ua

The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message". A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]

draft-hansen-lemonade-msgctxt-videomsg-01 RFC3458 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3938
RFC3939 Calling Line Identification for Voice Mail Messages G. Parsons J. Maruszak December 2004 ASCII 22739 11

This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. [STANDARDS-TRACK]

draft-ema-vpim-clid-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3939 10.17487/RFC3939
RFC3940 Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol B. Adamson C. Bormann M. Handley J. Macker November 2004 ASCII 220549 80

This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-pi-norm-10 RFC5740 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3940
RFC3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks B. Adamson C. Bormann M. Handley J. Macker November 2004 ASCII 92785 36

This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-norm-09 RFC5401 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3941
RFC3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options B. Volz November 2004 ASCII 13996 7 DHCP-BOOTP Bootstrap

This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS-TRACK]

draft-ietf-dhc-reclassify-options-01 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3942 10.17487/RFC3942
RFC3943 Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS) R. Friend November 2004 ASCII 28942 13 lossless data compression algorithm TLS Record Protocol

The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. This memo provides information for the Internet community.

draft-friend-tls-lzs-compression-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3943
RFC3944 H.350 Directory Services T. Johnson S. Okubo S. Campos December 2004 ASCII 61160 30 ldap directory services h.350 h.323 h.320 h.235 sip

The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. This memo provides information for the Internet community.

draft-johnson-h350-directory-serv-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3944 10.17487/RFC3944
RFC3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture E. Mannie Editor October 2004 ASCII 166700 69

Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-architecture-07 RFC6002 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3945 10.17487/RFC3945
RFC3946 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control E. Mannie D. Papadimitriou October 2004 ASCII 52205 26

This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-sonet-sdh-08 RFC4606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC3946
RFC3947 Negotiation of NAT-Traversal in the IKE T. Kivinen B. Swander A. Huttunen V. Volpe January 2005 ASCII 34759 16

This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). [STANDARDS-TRACK]

draft-ietf-ipsec-nat-t-ike-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3947
RFC3948 UDP Encapsulation of IPsec ESP Packets A. Huttunen B. Swander V. Volpe L. DiBurro M. Stenberg January 2005 ASCII 30366 15

This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK]

draft-ietf-ipsec-udp-encaps-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3948
RFC3949 File Format for Internet Fax R. Buckley D. Venable L. McIntyre G. Parsons J. Rafferty February 2005 ASCII 204903 84 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.

This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the International Telecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group (JBIG) profiles (Profiles S, F, J) for black-and-white fax and base JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. [STANDARDS-TRACK]

draft-ietf-fax-tiff-fx-14 RFC2301 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3949
RFC3950 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration L. McIntyre G. Parsons J. Rafferty February 2005 ASCII 13884 8 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]

draft-ietf-fax-tiff-fx-reg-v2-01 RFC3250 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3950
RFC3951 Internet Low Bit Rate Codec (iLBC) S. Andersen A. Duric H. Astrom R. Hagen W. Kleijn J. Linden December 2004 ASCII 373442 194

This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-avt-ilbc-codec-05 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC3951
RFC3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech A. Duric S. Andersen December 2004 ASCII 28655 13

This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-avt-rtp-ilbc-05 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC3952
RFC3953 Telephone Number Mapping (ENUM) Service Registration for Presence Services J. Peterson January 2005 ASCII 13875 7 uniform resource identifier uri provisioning pres

This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS-TRACK]

draft-ietf-enum-pres-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3953
RFC3954 Cisco Systems NetFlow Services Export Version 9 B. Claise Editor October 2004 ASCII 76360 33

This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community.

draft-claise-netflow-9-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3954 10.17487/RFC3954
RFC3955 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) S. Leinen October 2004 ASCII 55143 23

This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. This memo provides information for the Internet community.

draft-leinen-ipfix-eval-contrib-03 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC3955
RFC3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address P. Savola B. Haberman November 2004 ASCII 40136 18 internet protocol

This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]

draft-ietf-mboned-embeddedrp-07 RFC3306 RFC7371 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC3956
RFC3957 Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4 C. Perkins P. Calhoun March 2005 ASCII 63576 27

Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. [STANDARDS-TRACK]

draft-ietf-mip4-aaa-key-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC3957
RFC3958 Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) L. Daigle A. Newton January 2005 ASCII 54568 25

This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]

draft-daigle-snaptr-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3958 10.17487/RFC3958
RFC3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII 22160 11

This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. [STANDARDS-TRACK]

draft-ietf-sipping-early-disposition-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3959 10.17487/RFC3959
RFC3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) G. Camarillo H. Schulzrinne December 2004 ASCII 31692 13

This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community.

draft-ietf-sipping-early-media-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3960
RFC3961 Encryption and Checksum Specifications for Kerberos 5 K. Raeburn February 2005 ASCII 111865 50

This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". [STANDARDS-TRACK]

draft-ietf-krb-wg-crypto-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=3961 10.17487/RFC3961
RFC3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5 K. Raeburn February 2005 ASCII 32844 16 kerberos cryptosystem suite

The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. [STANDARDS-TRACK]

draft-raeburn-krb-rijndael-krb-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC3962
RFC3963 Network Mobility (NEMO) Basic Support Protocol V. Devarapalli R. Wakikawa A. Petrescu P. Thubert January 2005 ASCII 75955 33 mobile ipv6 session continuity

This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]

draft-ietf-nemo-basic-support-03 PROPOSED STANDARD PROPOSED STANDARD IETF int nemo 10.17487/RFC3963
RFC3964 Security Considerations for 6to4 P. Savola C. Patel December 2004 ASCII 83360 41

The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. This memo provides information for the Internet community.

draft-ietf-v6ops-6to4-security-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=3964 10.17487/RFC3964
RFC3965 A Simple Mode of Facsimile Using Internet Mail K. Toyoda H. Ohno J. Murai D. Wing December 2004 ASCII 28157 14 SMFAX-IM data file format e-mail

This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them.

This document is a revision of RFC 2305. There have been no technical changes. [STANDARDS-TRACK]

draft-ietf-fax-service-v2-05 RFC2305 DRAFT STANDARD DRAFT STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=3965 10.17487/RFC3965
RFC3966 The tel URI for Telephone Numbers H. Schulzrinne December 2004 ASCII 40783 17 uniform resource locator schemes

This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK]

draft-ietf-iptel-rfc2806bis-09 RFC2806 RFC5341 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=3966 10.17487/RFC3966
RFC3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level R. Bush T. Narten December 2004 ASCII 12251 6

IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ymbk-downref-03 RFC4897 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3967 10.17487/RFC3967
RFC3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII 20615 8

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sip-parameter-registry-02 RFC3427 BCP0098 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sip 10.17487/RFC3968
RFC3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII 12119 6

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sip-uri-parameter-reg-02 RFC3427 RFC5727 BCP0099 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sip 10.17487/RFC3969
RFC3970 A Traffic Engineering (TE) MIB K. Kompella January 2005 ASCII 88833 44

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths. [STANDARDS-TRACK]

draft-ietf-tewg-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF subip tewg http://www.rfc-editor.org/errata_search.php?rfc=3970 10.17487/RFC3970
RFC3971 SEcure Neighbor Discovery (SEND) J. Arkko Editor J. Kempf B. Zill P. Nikander March 2005 ASCII 123372 56 Neighbor Discovery Protocol NDP

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]

draft-ietf-send-ndopt-06 RFC6494 RFC6495 RFC6980 PROPOSED STANDARD PROPOSED STANDARD IETF int send http://www.rfc-editor.org/errata_search.php?rfc=3971 10.17487/RFC3971
RFC3972 Cryptographically Generated Addresses (CGA) T. Aura March 2005 ASCII 51473 22 Secure Neighbor Discovery SEND

This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK]

draft-ietf-send-cga-06 RFC4581 RFC4982 PROPOSED STANDARD PROPOSED STANDARD IETF int send 10.17487/RFC3972
RFC3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) A. Adams J. Nicholas W. Siadak January 2005 ASCII 136708 61 multicast routing protocol prune messages

This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pim-dm-new-v2-05 EXPERIMENTAL EXPERIMENTAL IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=3973 10.17487/RFC3973
RFC3974 SMTP Operational Experience in Mixed IPv4/v6 Environments M. Nakamura J. Hagino January 2005 ASCII 22729 10 simple mail transfer protocol dual stack dualstack ipv4 ipv6

This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.

This document does not define any new protocol. This memo provides information for the Internet community.

draft-motonori-dualstack-smtp-requirement-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3974
RFC3975 OMA-IETF Standardization Collaboration G. Huston Editor I. Leuca Editor January 2005 ASCII 16926 9 oopen mobile alliance ietf internet engineering task force

This document describes the standardization collaboration between the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.

draft-iab-oma-liaison-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3975
RFC3976 Interworking SIP and Intelligent Network (IN) Applications V. K. Gurbani F. Haerens V. Rastogi January 2005 ASCII 60191 25 sip intelligent network call models call model mapping telephony services public switched telephone network pstn

Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). This memo provides information for the Internet community.

draft-gurbani-sin-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3976
RFC3977 Network News Transfer Protocol (NNTP) C. Feather October 2006 ASCII 247440 125 usenet netnews

The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP. [STANDARDS-TRACK]

draft-ietf-nntpext-base-27 RFC0977 RFC2980 RFC6048 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=3977 10.17487/RFC3977
RFC3978 IETF Rights in Contributions S. Bradner Editor March 2005 ASCII 43574 18 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-subm-rights-fix-00 RFC3667 RFC5378 RFC2026 RFC4748 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=3978 10.17487/RFC3978
RFC3979 Intellectual Property Rights in IETF Technology S. Bradner Editor March 2005 ASCII 41366 17 ipr copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC3668 RFC2026 RFC2028 RFC4879 BCP0079 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3979
RFC3980 T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names M. Krueger M. Chadalapaka R. Elliott February 2005 ASCII 14056 8 internet small computer systems interface scsi transport protocol

Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) worldwide naming format defined by the InterNational Committee for Information Technology Standards (INCITS) T11 - Fibre Channel (FC) protocols and used by Serial Attached SCSI (SAS). This document updates RFC 3720. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-name-ext-05 RFC7143 RFC3720 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3980
RFC3981 IRIS: The Internet Registry Information Service (IRIS) Core Protocol A. Newton M. Sanz January 2005 ASCII 101359 52

This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in the Extensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. [STANDARDS-TRACK]

draft-ietf-crisp-iris-core-07 RFC4992 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=3981 10.17487/RFC3981
RFC3982 IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS) A. Newton M. Sanz January 2005 ASCII 90901 50

This document describes an Internet Registry Information Service (IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. [STANDARDS-TRACK]

draft-ietf-crisp-iris-dreg-07 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=3982 10.17487/RFC3982
RFC3983 Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) A. Newton M. Sanz January 2005 ASCII 23466 12

This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS). [STANDARDS-TRACK]

draft-ietf-crisp-iris-beep-07 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp 10.17487/RFC3983
RFC3984 RTP Payload Format for H.264 Video S. Wenger M.M. Hannuksela T. Stockhammer M. Westerlund D. Singer February 2005 ASCII 205093 83 ITU-T Recommendation H.264 ISO/IEC International Standard 14496-10

This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. [STANDARDS-TRACK]

draft-ietf-avt-rtp-h264-11 RFC6184 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3984
RFC3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture S. Bryant Editor P. Pate Editor March 2005 ASCII 95062 42

This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.

draft-ietf-pwe3-arch-07 RFC5462 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC3985
RFC3986 Uniform Resource Identifier (URI): Generic Syntax T. Berners-Lee R. Fielding L. Masinter January 2005 ASCII 141811 61 Internet protocol uniform resource identifier www world wide web

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]

draft-fielding-uri-rfc2396bis-07 RFC2732 RFC2396 RFC1808 RFC1738 RFC6874 RFC7320 STD0066 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3986 10.17487/RFC3986
RFC3987 Internationalized Resource Identifiers (IRIs) M. Duerst M. Suignard January 2005 ASCII 111190 46 uri uniform resource identifier Universal Character Set

This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.

The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.

draft-duerst-iri-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3987 10.17487/RFC3987
RFC3988 Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol B. Black K. Kompella January 2005 ASCII 18841 9 mtu ldp lsp label switched path label switching router lsr

Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent off-line mechanisms. This document specifies experimental extensions to LDP in support of LSP MTU discovery. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mpls-ldp-mtu-extensions-03 EXPERIMENTAL EXPERIMENTAL IETF rtg mpls 10.17487/RFC3988
RFC3989 Middlebox Communications (MIDCOM) Protocol Semantics M. Stiemerling J. Quittek T. Taylor February 2005 ASCII 160606 70 nat network address translator firewall

This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This memo provides information for the Internet community.

draft-ietf-midcom-semantics-08 RFC5189 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC3989
RFC3990 Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement B. O'Hara P. Calhoun J. Kempf February 2005 ASCII 11854 5

This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. This memo provides information for the Internet community.

draft-ietf-capwap-problem-statement-02 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC3990
RFC3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package B. Foster F. Andreasen February 2005 ASCII 22951 11 voice IP internet VoIP

The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order. This memo provides information for the Internet community.

draft-foster-mgcp-redirect-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3991
RFC3992 Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism B. Foster F. Andreasen February 2005 ASCII 9718 5 fault recovery

A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. This memo provides information for the Internet community.

draft-foster-mgcp-lockstep-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3992
RFC3993 Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option R. Johnson T. Palaniappan M. Stapp March 2005 ASCII 13938 7

This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable "Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]

draft-ietf-dhc-subscriber-id-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3993
RFC3994 Indication of Message Composition for Instant Messaging H. Schulzrinne January 2005 ASCII 27472 13 im status message content type xml extensible markup language

In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. [STANDARDS-TRACK]

draft-ietf-simple-iscomposing-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC3994
RFC3995 Internet Printing Protocol (IPP): Event Notifications and Subscriptions R. Herriot T. Hastings March 2005 ASCII 223294 95 optional subscription events subscription objects asynchronous even notification

This document describes an OPTIONAL extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol). A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting a Job with subscription information. A client associates Subscription Objects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for Subscription Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription. [STANDARDS-TRACK]

draft-ietf-ipp-not-spec-12 RFC2911 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3995
RFC3996 Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications R. Herriot T. Hastings H. Lewis March 2005 ASCII 73638 31 pull delivery method event notifications event subscriptions

This document describes an extension to the Internet Printing Protocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this document. [STANDARDS-TRACK]

draft-ietf-ipp-notify-get-10 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3996
RFC3997 Internet Printing Protocol (IPP): Requirements for IPP Notifications T. Hastings Editor R. K. deBry H. Lewis March 2005 ASCII 38185 17 model directory services notification requirements

This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service. This memo provides information for the Internet community.

draft-ietf-ipp-not-07 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC3997
RFC3998 Internet Printing Protocol (IPP): Job and Printer Administrative Operations C. Kugler H. Lewis T. Hastings Editor March 2005 ASCII 109658 46 system administration operations Enable-Printer and Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs and Release-Held-New-Jobs Deactivate-Printer and Activate-Printer Restart-Printer Shutdown-Printer and Startup-Printer Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Promote-Job Schedule-Job-After

This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet Printing Protocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in. (Printer operations: Enable-Printer and Disable-Printer, Pause-Printer-After-Current-Job, Hold-New-Jobs and Release-Held-New-Jobs, Deactivate-Printer and Activate-Printer, Restart-Printer, Shutdown-Printer and Startup-Printer. Job operations: Reprocess-Job, Cancel-Current-Job, Suspend-Current-Job, Resume-Job, Promote-Job, Schedule-Job-After.) [STANDARDS-TRACK]

draft-ietf-ipp-ops-set2-04 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3998 10.17487/RFC3998
RFC4001 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder February 2005 ASCII 45836 22 MIB management information base internet network layer addressing information

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-ops-rfc3291bis-06 RFC3291 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4001
RFC4002 IANA Registration for Enumservice 'web' and 'ft' R. Brandner L. Conroy R. Stastny February 2005 ASCII 18072 10 URI schemes uniform resource identifier enum

This document registers the Enumservices 'web' and 'ft' by using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761). [STANDARDS-TRACK]

draft-ietf-enum-webft-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4002
RFC4003 GMPLS Signaling Procedure for Egress Control L. Berger February 2005 ASCII 10306 5 lsp label switch path gmpls signaling

This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a Label Switched Path (LSP). This control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-egress-control-03 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4003
RFC4004 Diameter Mobile IPv4 Application P. Calhoun T. Johansson C. Perkins T. Hiller Editor P. McCann August 2005 ASCII 128210 53 internet protocol version 4 aaa authentication authorization accounting inter-realm diameter accounting

This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-mobileip-20 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4004 10.17487/RFC4004
RFC4005 Diameter Network Access Server Application P. Calhoun G. Zorn D. Spence D. Mitton August 2005 ASCII 198871 85 aaa authentication authorization accounting nas diameter base transport profile extensible authentication protocol radius

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.

Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations.

The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-nasreq-17 RFC7155 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4005 10.17487/RFC4005
RFC4006 Diameter Credit-Control Application H. Hakala L. Mattila J-P. Koskinen M. Stura J. Loughney August 2005 ASCII 288794 114 real-time credit-control

This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-cc-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4006 10.17487/RFC4006
RFC4007 IPv6 Scoped Address Architecture S. Deering B. Haberman T. Jinmei E. Nordmark B. Zill March 2005 ASCII 53555 24 architectural characteristics expected behavior textual representation

This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK]

draft-ietf-ipv6-scoping-arch-02 RFC7346 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4007
RFC4008 Definitions of Managed Objects for Network Address Translators (NAT) R. Rohit P. Srisuresh R. Raghunarayan N. Pai C. Wang March 2005 ASCII 125696 64 mib management information base

This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. [STANDARDS-TRACK]

draft-ietf-nat-natmib-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4008
RFC4009 The SEED Encryption Algorithm J. Park S. Lee J. Kim J. Lee February 2005 ASCII 32552 17 encryption algorithm seed cbc seed oid

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). This memo provides information for the Internet community.

draft-park-seed-01 RFC4269 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4009 10.17487/RFC4009
RFC4010 Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS) J. Park S. Lee J. Kim J. Lee February 2005 ASCII 22403 13 smime secure/multipurpose internet mail extensions

This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).

SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). One OID class defines the content encryption algorithms and the other defines the key encryption algorithms. [STANDARDS-TRACK]

draft-ietf-smime-cms-seed-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4010 10.17487/RFC4010
RFC4011 Policy Based Management MIB S. Waldbusser J. Saperia T. Hongal March 2005 ASCII 265942 121 management information base Simple Network Management Protocol snmp infrastructures scripting language script execution environment

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol (SNMP) infrastructures, a scripting language, and a script execution environment. [STANDARDS-TRACK]

draft-ietf-snmpconf-pm-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpconf 10.17487/RFC4011
RFC4012 Routing Policy Specification Language next generation (RPSLng) L. Blunk J. Damas F. Parent A. Robachevsky March 2005 ASCII 35217 16

This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS-TRACK]

draft-blunk-rpslng-08 RFC2725 RFC2622 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4012
RFC4013 SASLprep: Stringprep Profile for User Names and Passwords K. Zeilenga February 2005 ASCII 13051 6 unicode strings saslprep stringprep sasl simple authentication and security layer

This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the "SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. [STANDARDS-TRACK]

draft-ietf-sasl-saslprep-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4013 10.17487/RFC4013
RFC4014 Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option R. Droms J. Schnizlein February 2005 ASCII 15416 8

The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. [STANDARDS-TRACK]

draft-ietf-dhc-agentopt-radius-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4014
RFC4015 The Eifel Response Algorithm for TCP R. Ludwig A. Gurtov February 2005 ASCII 31512 13 transmision control protocol

Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. [STANDARDS-TRACK]

draft-ietf-tsvwg-tcp-eifel-response-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4015
RFC4016 Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements M. Parthasarathy March 2005 ASCII 36104 15 authentication network access

This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol. This memo provides information for the Internet community.

draft-ietf-pana-threats-eval-07 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC4016
RFC4017 Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs D. Stanley J. Walker B. Aboba March 2005 ASCII 22183 11 IEEE 802.11 wireless lan

The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.

draft-walker-ieee802-req-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4017
RFC4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) M. Bakke J. Hufferd K. Voruganti M. Krueger T. Sperry April 2005 ASCII 48498 23 scsi slp

The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. [PROPOSED STANDARD]

draft-ietf-ips-iscsi-slp-09 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4018
RFC4019 RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite G. Pelletier April 2005 ASCII 46896 23 rtp udp-lite ip real-time transport protocol user datagram protocol lite internet protocol

This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. [STANDARDS-TRACK]

draft-ietf-rohc-udp-lite-04 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4019
RFC4020 Early IANA Allocation of Standards Track Code Points K. Kompella A. Zinin February 2005 ASCII 13706 7

This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-kompella-zinin-early-allocation-02 RFC7120 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4020
RFC4021 Registration of Mail and MIME Header Fields G. Klyne J. Palme March 2005 ASCII 75452 54 IANA

This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK]

draft-klyne-hdrreg-mail-05 RFC5322 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4021
RFC4022 Management Information Base for the Transmission Control Protocol (TCP) R. Raghunarayan Editor March 2005 ASCII 47360 24 MIB-TCP TCP Simple Network Management Protocol MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2012-update-06 RFC2452 RFC2012 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4022
RFC4023 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) T. Worster Y. Rekhter E. Rosen Editor March 2005 ASCII 31696 14

Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. [STANDARDS-TRACK]

draft-ietf-mpls-in-ip-or-gre-08 RFC5332 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4023
RFC4024 Voice Messaging Client Behaviour G. Parsons J. Maruszak July 2005 ASCII 18560 9 vpim profile internet mail voice profile for internet mail fax message

This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message. This memo provides information for the Internet community.

draft-ema-vpim-cb-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4024
RFC4025 A Method for Storing IPsec Keying Material in DNS M. Richardson March 2005 ASCII 25408 12

This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question.

This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]

draft-ietf-ipseckey-rr-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipseckey 10.17487/RFC4025
RFC4026 Provider Provisioned Virtual Private Network (VPN) Terminology L. Andersson T. Madsen March 2005 ASCII 42124 20 l3vpn l2vpn

The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.

To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.

draft-ietf-l3vpn-ppvpn-terminology-04 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4026 10.17487/RFC4026
RFC4027 Domain Name System Media Types S. Josefsson April 2005 ASCII 11676 6 media type application/dns text/dns

This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035. This memo provides information for the Internet community.

draft-josefsson-mime-dns-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4027
RFC4028 Session Timers in the Session Initiation Protocol (SIP) S. Donovan J. Rosenberg April 2005 ASCII 65363 27 re-invite request update request session-expires min-se

This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a \%re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: \%Session-Expires, which conveys the lifetime of the session, and \%Min-SE, which conveys the minimum allowed value for the session timer. [STANDARDS-TRACK]

draft-ietf-sip-session-timer-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4028 10.17487/RFC4028
RFC4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks M. Lind V. Ksinant S. Park A. Baudot P. Savola March 2005 ASCII 64388 28 internet service provider internet protocol

This document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified. This memo provides information for the Internet community.

draft-ietf-v6ops-isp-scenarios-analysis-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4029 10.17487/RFC4029
RFC4030 The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option M. Stapp T. Lemon March 2005 ASCII 34332 15

The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. [STANDARDS-TRACK]

draft-ietf-dhc-auth-suboption-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4030
RFC4031 Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) M. Carugi Editor D. McDysan Editor April 2005 ASCII 118568 50 l3vpn service provider vpn

This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. This memo provides information for the Internet community.

draft-ietf-l3vpn-requirements-02 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4031
RFC4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework G. Camarillo P. Kyzivat March 2005 ASCII 20492 10 qos quality of service precondition

This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. [STANDARDS-TRACK]

draft-ietf-sip-rfc3312-update-03 RFC3312 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4032
RFC4033 DNS Security Introduction and Requirements R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII 52445 21 domain name system authentication origin integrity dnssec domain name system security extensions

The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-intro-13 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC6014 RFC6840 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4033 10.17487/RFC4033
RFC4034 Resource Records for the DNS Security Extensions R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII 63879 29 domain name system authentication origin integrity dnssec domain name system security extensions

This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-records-11 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC4470 RFC6014 RFC6840 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4034 10.17487/RFC4034
RFC4035 Protocol Modifications for the DNS Security Extensions R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII 130589 53 domain name system authentication origin integrity dnssec domain name system security extensions

This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-protocol-09 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC4470 RFC6014 RFC6840 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4035 10.17487/RFC4035
RFC4036 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management W. Sawyer April 2005 ASCII 57946 27 mib snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. [STANDARDS-TRACK]

draft-ietf-ipcdn-subscriber-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4036
RFC4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core A. Rousskov March 2005 ASCII 131487 56 callout server

This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations. [STANDARDS-TRACK]

draft-ietf-opes-ocp-core-05 PROPOSED STANDARD PROPOSED STANDARD IETF app opes 10.17487/RFC4037
RFC4038 Application Aspects of IPv6 Transition M-K. Shin Editor Y-G. Hong J. Hagino P. Savola E. M. Castro March 2005 ASCII 69727 33

As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. This memo provides information for the Internet community.

draft-ietf-v6ops-application-transition-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4038
RFC4039 Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) S. Park P. Kim B. Volz March 2005 ASCII 22297 10

This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration. [STANDARDS-TRACK]

draft-ietf-dhc-rapid-commit-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4039
RFC4040 RTP Payload Format for a 64 kbit/s Transparent Call R. Kreuter April 2005 ASCII 15363 8 realtime transport protocol

This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called "Clearmode". It also serves as registration for a related MIME type called "audio/clearmode".

"Clearmode" is a basic feature of VoIP Media Gateways. [STANDARDS-TRACK]

draft-ietf-avt-rtp-clearmode-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4040
RFC4041 Requirements for Morality Sections in Routing Area Drafts A. Farrel April 1 2005 ASCII 15249 8 moral values moral code

It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal.

This document specifies a requirement for all new Routing Area Internet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. This memo provides information for the Internet community.

draft-farrel-rtg-morality-requirements-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4041
RFC4042 UTF-9 and UTF-18 Efficient Transformation Formats of Unicode M. Crispin April 1 2005 ASCII 19123 9 universal character set ucs codeopints unicode utf-7 utf-8 utf-16

ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization.

The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet.

This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4042
RFC4043 Internet X.509 Public Key Infrastructure Permanent Identifier D. Pinkas T. Gindin May 2005 ASCII 30092 15 subjectAltName extension dn

This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity.

The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed.

The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK]

draft-ietf-pkix-pi-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4043 10.17487/RFC4043
RFC4044 Fibre Channel Management MIB K. McCloghrie May 2005 ASCII 127148 69 management information base fc-mgmt-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel. [STANDARDS-TRACK]

draft-ietf-ips-fcmgmt-mib-06 RFC2837 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4044
RFC4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP) G. Bourdon April 2005 ASCII 59140 28 ppp point-to-point protocol

The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-l2tpext-mcast-05 EXPERIMENTAL EXPERIMENTAL IETF int l2tpext 10.17487/RFC4045
RFC4046 Multicast Security (MSEC) Group Key Management Architecture M. Baugher R. Canetti L. Dondeti F. Lindholm April 2005 ASCII 97885 38 group security association gsa

This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. This memo provides information for the Internet community.

draft-ietf-msec-gkmarch-08 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC4046
RFC4047 MIME Sub-type Registrations for Flexible Image Transport System (FITS) S. Allen D. Wells April 2005 ASCII 53737 23 multipurpose internet mail extensions astronomical observations

This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible Image Transport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS. This memo provides information for the Internet community.

draft-allen-fitsmime-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4047
RFC4048 RFC 1888 Is Obsolete B. Carpenter April 2005 ASCII 7394 4 Internet Protocol Open Systems Interconnection

This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. This memo provides information for the Internet community.

draft-carpenter-obsolete-1888-01 RFC1888 RFC4548 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4048 10.17487/RFC4048
RFC4049 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 R. Housley April 2005 ASCII 12302 7 signing-time attribute cryptographic message syntax cms SignedData AuthenticatedData

This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. This memo defines an Experimental Protocol for the Internet community.

draft-housley-binarytime-02 RFC6019 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4049
RFC4050 Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures S. Blake-Wilson G. Karlinger T. Kobayashi Y. Wang April 2005 ASCII 35327 19 elliptic curve digital signature algorithm ecdsa elliptic curve cryptography ecc xml digital signatures xml dsig xml

This document specifies how to use Elliptic Curve Digital Signature Algorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. This memo provides information for the Internet community.

draft-blake-wilson-xmldsig-ecdsa-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4050
RFC4051 Additional XML Security Uniform Resource Identifiers (URIs) D. Eastlake 3rd April 2005 ASCII 33368 17 digital signatures encryption canonicalization

A number of Uniform Resource Identifiers (URIs) intended for use with XML Digital Signatures, Encryption, and Canonicalization are defined. These URIs identify algorithms and types of keying information. [STANDARDS-TRACK]

draft-eastlake-xmldsig-uri-09 RFC6931 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4051 10.17487/RFC4051
RFC4052 IAB Processes for Management of IETF Liaison Relationships L. Daigle Editor Internet Architecture Board April 2005 ASCII 18360 9 internet architecture board sdo standards development organization

This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-liaison-mgt-03 BCP0102 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=4052 10.17487/RFC4052
RFC4053 Procedures for Handling Liaison Statements to and from the IETF S. Trowbridge S. Bradner F. Baker April 2005 ASCII 38816 19 sdo standards develoopment organization

This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community.

The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-baker-liaison-statements-04 BCP0103 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC4053
RFC4054 Impairments and Other Constraints on Optical Layer Routing J. Strand Editor A. Chiu Editor May 2005 ASCII 73327 29 diversity routing path selection impariment ase pmd optical control plane gmpls

Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1) Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. This memo provides information for the Internet community.

draft-ietf-ipo-impairments-04 INFORMATIONAL INFORMATIONAL IETF subip ipo 10.17487/RFC4054
RFC4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile J. Schaad B. Kaliski R. Housley June 2005 ASCII 57479 25 ASN.1 RSASSA-PSS RSA probabilistic signature scheme signature algorithm RSAES-OAEP RSA encryption scheme optimal asymmetric encryption padding public-key cryptography standards PKCS pki

This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]

draft-ietf-pkix-rsa-pkalgs-03 RFC3279 RFC5756 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4055 10.17487/RFC4055
RFC4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS) J. Schaad June 2005 ASCII 11514 6 RSA probabilistic signature scheme digital signature

This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]

draft-ietf-smime-pss-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC4056
RFC4057 IPv6 Enterprise Network Scenarios J. Bound Editor June 2005 ASCII 33454 17 internet protocol version 6

This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. This memo provides information for the Internet community.

draft-ietf-v6ops-ent-scenarios-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4057 10.17487/RFC4057
RFC4058 Protocol for Carrying Authentication for Network Access (PANA) Requirements A. Yegin Editor Y. Ohba R. Penno G. Tsirtsis C. Wang May 2005 ASCII 41957 19 network connectivity link layer agnostic protocol

It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure. This memo provides information for the Internet community.

draft-ietf-pana-requirements-09 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC4058
RFC4059 Internet X.509 Public Key Infrastructure Warranty Certificate Extension D. Linsenbardt S. Pontius A. Sturgeon May 2005 ASCII 17904 9 certificate authority ca insurance policy

This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. This memo provides information for the Internet community.

draft-ietf-pkix-warranty-extn-04 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC4059
RFC4060 RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding Q. Xie D. Pearce May 2005 ASCII 39654 19 real-time transport protocol dsr distributed speeech recognition xfe extended front-end xafe extended advanced front-end

This document specifies RTP payload formats for encapsulating European Telecommunications Standards Institute (ETSI) European Standard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSR Extended Front-end (XFE), and ES 202 212 DSR Extended Advanced Front-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]

draft-ietf-avt-rtp-dsr-codecs-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4060 10.17487/RFC4060
RFC4061 Benchmarking Basic OSPF Single Router Control Plane Convergence V. Manral R. White A. Shaikh April 2005 ASCII 32706 16 spf time adjacency formation time

This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance.

NOTE: In this document, the word "convergence" relates to single router control plane convergence only. This memo provides information for the Internet community.

draft-ietf-bmwg-ospfconv-intraarea-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4061
RFC4062 OSPF Benchmarking Terminology and Concepts V. Manral R. White A. Shaikh April 2005 ASCII 15784 9 spf time adjacency formation time

This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere (and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol. This memo provides information for the Internet community.

draft-ietf-bmwg-ospfconv-term-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4062
RFC4063 Considerations When Using Basic OSPF Convergence Benchmarks V. Manral R. White A. Shaikh April 2005 ASCII 23401 11 spf time adjacency formation time

This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested. This memo provides information for the Internet community.

draft-ietf-bmwg-ospfconv-applicability-07 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4063
RFC4064 Experimental Message, Extensions, and Error Codes for Mobile IPv4 A. Patel K. Leung May 2005 ASCII 20748 11 internet protocol message types

Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before a formal standards proposal is issued. [STANDARDS-TRACK]

draft-ietf-mip4-experimental-messages-02 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC4064
RFC4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations J. Kempf July 2005 ASCII 16179 8 candidate access router discovery card context transfer protocol CXTP ICMP

The Seamoby Candidate Access Router Discovery (CARD) protocol and the Context Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, Stream Control Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options. This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-seamoby-iana-02 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4065
RFC4066 Candidate Access Router Discovery (CARD) M. Liebsch Editor A. Singh Editor H. Chaskar D. Funato E. Shim July 2005 ASCII 116733 46 mobile node mn cars candidate ars

To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-seamoby-card-protocol-08 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4066
RFC4067 Context Transfer Protocol (CXTP) J. Loughney Editor M. Nakhjiri C. Perkins R. Koodli July 2005 ASCII 77718 33 mobile node mn

This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-seamoby-ctp-11 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4067
RFC4068 Fast Handovers for Mobile IPv6 R. Koodli Editor July 2005 ASCII 93591 42 internet protocol version 6 access router mobile node mn

Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mipshop-fast-mipv6-03 RFC5268 EXPERIMENTAL EXPERIMENTAL IETF int mipshop 10.17487/RFC4068
RFC4069 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding M. Dodge B. Ray May 2005 ASCII 35712 19 mib management information base VDSL-LINE-MIB VDSL-LINE-EXT-SCM-MIB

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]

draft-ietf-adslmib-vdsl-ext-scm-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4069
RFC4070 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding M. Dodge B. Ray May 2005 ASCII 48561 24 management information base mib VDSL-LINE-MIB VDSL-LINE-EXT-MCM-MIB

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]

draft-ietf-adslmib-vdsl-ext-mcm-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4070
RFC4071 Structure of the IETF Administrative Support Activity (IASA) R. Austein Editor B. Wijnen Editor April 2005 ASCII 48614 20 isoc ietf administrative oversight committee IAOC ietf administrative director iad

This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-iasa-bcp-07 RFC4371 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4071
RFC4072 Diameter Extensible Authentication Protocol (EAP) Application P. Eronen Editor T. Hiller G. Zorn August 2005 ASCII 79965 33 command codes avp nas network access server back-end autentication server

The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. [STANDARDS-TRACK]

draft-ietf-aaa-eap-10 RFC7268 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4072 10.17487/RFC4072
RFC4073 Protecting Multiple Contents with the Cryptographic Message Syntax (CMS) R. Housley May 2005 ASCII 17103 9 content collection

This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. [STANDARDS-TRACK]

draft-housley-contentcollection-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4073 10.17487/RFC4073
RFC4074 Common Misbehavior Against DNS Queries for IPv6 Addresses Y. Morishita T. Jinmei May 2005 ASCII 13073 6 resource records aaaa domain name service

There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects. This memo provides information for the Internet community.

draft-ietf-dnsop-misbehavior-against-aaaa-02 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4074
RFC4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 V. Kalusivalingam May 2005 ASCII 9424 5 dynamic host configuration protocol server addresses

This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-opt-sntp-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4075
RFC4076 Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) T. Chown S. Venaas A. Vijayabhaskar May 2005 ASCII 15745 8 internet protocol stateless address autoconfiguration

IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. This memo provides information for the Internet community.

draft-ietf-dhc-stateless-dhcpv6-renumbering-02 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC4076
RFC4077 A Negative Acknowledgement Mechanism for Signaling Compression A.B. Roach May 2005 ASCII 34250 16 sigcomp negative feedback

This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]

draft-ietf-rohc-sigcomp-nack-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4077
RFC4078 The TV-Anytime Content Reference Identifier (CRID) N. Earnshaw S. Aoki A. Ashley W. Kameyama May 2005 ASCII 21433 10 digital broadcasting tv radio uri uniform resource identifier content referencing storage systems

The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.

The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition.

This document reproduces the \%TV-Anytime CRID definition found in the \%TV-Anytime content referencing specification, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.

draft-earnshaw-tv-anytime-crid-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4078
RFC4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects J. Peterson July 2005 ASCII 16718 7 using protocol

GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV. This memo provides information for the Internet community.

draft-ietf-geopriv-pres-02 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC4079
RFC4080 Next Steps in Signaling (NSIS): Framework R. Hancock G. Karagiannis J. Loughney S. Van den Bosch June 2005 ASCII 122470 49 data flow architectural framework signaling protocols signaling application

The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.

This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application. This memo provides information for the Internet community.

draft-ietf-nsis-fw-07 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4080
RFC4081 Security Threats for Next Steps in Signaling (NSIS) H. Tschofenig D. Kroeselberg June 2005 ASCII 67786 28

This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite. This memo provides information for the Internet community.

draft-ietf-nsis-threats-06 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4081
RFC4082 Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction A. Perrig D. Song R. Canetti J. D. Tygar B. Briscoe June 2005 ASCII 54316 22 data streams

This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.

This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. This memo provides information for the Internet community.

draft-ietf-msec-tesla-intro-04 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC4082
RFC4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP) M. Garcia-Martin May 2005 ASCII 80203 36 3GPP IP multimedia core network subsystem ims cellular networks

The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks. This memo provides information for the Internet community.

draft-ietf-sipping-3gpp-r5-requirements-00 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4083
RFC4084 Terminology for Describing Internet Connectivity J. Klensin May 2005 ASCII 24522 11

As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klensin-ip-service-terms-04 BCP0104 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4084 10.17487/RFC4084
RFC4085 Embedding Globally-Routable Internet Addresses Considered Harmful D. Plonka June 2005 ASCII 22656 10

This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. This document is intended to clarify best current practices in this regard. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grow-embed-addr-05 BCP0105 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC4085
RFC4086 Randomness Requirements for Security D. Eastlake 3rd J. Schiller S. Crocker June 2005 ASCII 114321 48 cryptographic algorithms passwords cryptographic keys pseudo-random random numbers seed

Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.

Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-eastlake-randomness2-10 RFC1750 BCP0106 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4086 10.17487/RFC4086
RFC4087 IP Tunnel MIB D. Thaler June 2005 ASCII 53206 25 management information base internet protocol tunnel-mib

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. [STANDARDS-TRACK]

draft-ietf-ipv6-inet-tunnel-mib-03 RFC2667 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4087
RFC4088 Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP) D. Black K. McCloghrie J. Schoenwaelder June 2005 ASCII 43019 18 uri uniform resource identifiers snmp-uri

The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.

This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances. [STANDARDS-TRACK]

draft-black-snmp-uri-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4088
RFC4089 IAB and IESG Recommendation for IETF Administrative Restructuring S. Hollenbeck Editor IAB and IESG May 2005 ASCII 128660 55 internet architecture board internet engineering steering group internet engineering task force

This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force. The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. This memo provides information for the Internet community.

draft-iab-iesg-adminrest-rec-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4089
RFC4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels P. Pan Editor G. Swallow Editor A. Atlas Editor May 2005 ASCII 83965 38 resource reservation protocol traffic engineering lsp label switch path one-to-one backup facility backup

This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.

Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-lsp-fastreroute-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4090 10.17487/RFC4090
RFC4091 The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework G. Camarillo J. Rosenberg June 2005 ASCII 12931 7

This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. [STANDARDS-TRACK]

draft-ietf-mmusic-anat-02 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4091
RFC4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) G. Camarillo J. Rosenberg June 2005 ASCII 12624 6 sdp-anat option-tag

This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. [STANDARDS-TRACK]

draft-ietf-sip-anat-usage-00 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4092
RFC4093 Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways F. Adrangi Editor H. Levkowetz Editor August 2005 ASCII 44082 19

Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions. This memo provides information for the Internet community.

draft-ietf-mip4-vpn-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int mip4 10.17487/RFC4093
RFC4094 Analysis of Existing Quality-of-Service Signaling Protocols J. Manner X. Fu May 2005 ASCII 103146 45 qos quality of service rsvp nsis yessir boomerang daris insignia bgrp sicap mobility performance security

This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area. This memo provides information for the Internet community.

draft-ietf-nsis-signalling-analysis-05 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4094
RFC4095 Attaching Meaning to Solicitation Class Keywords C. Malamud May 2005 ASCII 23539 11 uri uniform resource identifier no soliciting smtp service extension esmtp service extension dynamic delegation discovery system ddds no-solicit

This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.

This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword. [STANDARDS-TRACK]

draft-malamud-keyword-discovery-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4095
RFC4096 Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best C. Malamud May 2005 ASCII 31618 14

This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, \%standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. This memo provides information for the Internet community.

draft-malamud-subject-line-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4096
RFC4097 Middlebox Communications (MIDCOM) Protocol Evaluation M. Barnes Editor June 2005 ASCII 99303 44 snmp simple network management protocol rsip realm specific internet protocol megaco diameter cops common open policy service

This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. This memo provides information for the Internet community.

draft-ietf-midcom-protocol-eval-06 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC4097
RFC4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane H. Berkowitz E. Davies Editor S. Hares P. Krishnaswamy M. Lepp June 2005 ASCII 66845 36 border gateway protocol benchmarking methodology ebgp

This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices.This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. This memo provides information for the Internet community.

draft-ietf-bmwg-conterm-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4098
RFC4101 Writing Protocol Models E. Rescorla IAB June 2005 ASCII 47287 22 document review

The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. This memo provides information for the Internet community.

draft-iab-model-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4101
RFC4102 Registration of the text/red MIME Sub-Type P. Jones June 2005 ASCII 11337 6 rtp real-time transport protocol

This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]

draft-ietf-avt-text-red-05 RFC6354 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4102 10.17487/RFC4102
RFC4103 RTP Payload for Text Conversation G. Hellstrom P. Jones June 2005 ASCII 44246 20 real-time applications video audio packets

This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK]

draft-ietf-avt-rfc2793bis-09 RFC2793 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4103 10.17487/RFC4103
RFC4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS) M. Pana Editor A. Reyes A. Barba D. Moron M. Brunner June 2005 ASCII 190951 88 policy core lightweight directory access protocol pcim policy core information model mapping classes

This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types. Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703. [STANDARDS-TRACK]

draft-reyes-policy-core-ext-schema-07 RFC3703 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4104
RFC4105 Requirements for Inter-Area MPLS Traffic Engineering J.-L. Le Roux Editor J.-P. Vasseur Editor J. Boyle Editor June 2005 ASCII 50111 22 multiprotocol label switching mpls-te mpls te

This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements. This memo provides information for the Internet community.

draft-ietf-tewg-interarea-mpls-te-req-03 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC4105
RFC4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) J. Viega D. McGrew June 2005 ASCII 23399 11 aes advanced encryption standard

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]

draft-ietf-ipsec-ciph-aes-gcm-00 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4106 10.17487/RFC4106
RFC4107 Guidelines for Cryptographic Key Management S. Bellovin R. Housley June 2005 ASCII 14752 7 automated key management manual key management

The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-bellovin-mandate-keymgmt-03 BCP0107 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4107
RFC4108 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages R. Housley August 2005 ASCII 142060 61 hardward module components digital signature

This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK]

draft-housley-cms-fw-wrap-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4108 10.17487/RFC4108
RFC4109 Algorithms for Internet Key Exchange version 1 (IKEv1) P. Hoffman May 2005 ASCII 9491 5 ike ipsec oakley authentication isakmp internet security key management

The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]

draft-hoffman-ikev1-algorithms-03 RFC2409 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4109
RFC4110 A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) R. Callon M. Suzuki July 2005 ASCII 204159 82

This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. This memo provides information for the Internet community.

draft-ietf-l3vpn-framework-00 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4110
RFC4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) L. Fang Editor July 2005 ASCII 106626 45

This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. This memo provides information for the Internet community.

draft-ietf-l3vpn-security-framework-03 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4111 10.17487/RFC4111
RFC4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification D. Eastlake 3rd June 2005 ASCII 72537 34

Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meet the requirements of RFC 3505. [STANDARDS-TRACK]

draft-ietf-trade-ecml2-spec-13 RFC3106 PROPOSED STANDARD PROPOSED STANDARD IETF app trade 10.17487/RFC4112
RFC4113 Management Information Base for the User Datagram Protocol (UDP) B. Fenner J. Flick June 2005 ASCII 40323 19 MIB-UDP mib UDP-MIB internet protocol ip

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2013-update-04 RFC2454 RFC2013 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4113 10.17487/RFC4113
RFC4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck June 2005 ASCII 31490 17 shared central repository

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. [STANDARDS-TRACK]

draft-ietf-enum-epp-e164-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=4114 10.17487/RFC4114
RFC4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic O. Aboul-Magd S. Rabie July 2005 ASCII 12131 6 data services service scenarios metering algorithm color-blind color-aware

This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community.

draft-aboulmagd-trtcm-inprofile-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4115
RFC4116 IPv4 Multihoming Practices and Limitations J. Abley K. Lindqvist E. Davies B. Black V. Gill July 2005 ASCII 26598 13 internet protocol

Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6). This memo provides information for the Internet community.

draft-ietf-multi6-v4-multihoming-03 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4116
RFC4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) G. Camarillo E. Burger H. Schulzrinne A. van Wijk June 2005 ASCII 37951 19 deaf hard of hearing speech-impaired hearing-impaired

This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. This memo provides information for the Internet community.

draft-ietf-sipping-transc-3pcc-02 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4117 10.17487/RFC4117
RFC4118 Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP) L. Yang P. Zerfos E. Sadot June 2005 ASCII 93695 41 IEEE 802.11 wireless lan

This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing Wireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities. This memo provides information for the Internet community.

draft-ietf-capwap-arch-06 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4118
RFC4119 A Presence-based GEOPRIV Location Object Format J. Peterson December 2005 ASCII 53522 24 pidf presence information data format

This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. [STANDARDS-TRACK]

draft-ietf-geopriv-pidf-lo-03 RFC5139 RFC5491 RFC7459 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4119 10.17487/RFC4119
RFC4120 The Kerberos Network Authentication Service (V5) C. Neuman T. Yu S. Hartman K. Raeburn July 2005 ASCII 340314 138 KERBEROS CAT,Security

This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK]

draft-ietf-krb-wg-kerberos-clarifications-07 RFC1510 RFC4537 RFC5021 RFC5896 RFC6111 RFC6112 RFC6113 RFC6649 RFC6806 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4120 10.17487/RFC4120
RFC4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 L. Zhu K. Jaganathan S. Hartman July 2005 ASCII 340314 20 GSSAPI-KER cryptosystem

This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Kerberos Version 5 mechanism.

RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles. [STANDARDS-TRACK]

draft-ietf-krb-wg-gssapi-cfx-07 RFC1964 RFC6112 RFC6542 RFC6649 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC4121
RFC4122 A Universally Unique IDentifier (UUID) URN Namespace P. Leach M. Mealling R. Salz July 2005 ASCII 59319 32 uniform resource name guid globally unique identifier

This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.

This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]

draft-mealling-uuid-urn-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4122 10.17487/RFC4122
RFC4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements H. Schulzrinne C. Agboh July 2005 ASCII 29244 16 SIP-H.323 IWF

This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323. This memo provides information for the Internet community.

draft-agrawal-sip-h323-interworking-reqs-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4123
RFC4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering F. Le Faucheur Editor June 2005 ASCII 79265 37 DS-TE igp interior gateway protocol extensions rsvp resource reservation protocol

This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK]

draft-ietf-tewg-diff-te-proto-08 PROPOSED STANDARD PROPOSED STANDARD IETF subip tewg 10.17487/RFC4124
RFC4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering F. Le Faucheur W. Lai June 2005 ASCII 22585 12 ds-te maximum allocation model

This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tewg-diff-te-mam-04 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4125
RFC4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons J. Ash June 2005 ASCII 51232 22 diffserv-enabled mpls traffic engineering ds-te mar bandwidth reservation bandwidth allocation bandwidth protection performance evaluation cac network model

This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tewg-diff-te-mar-06 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4126
RFC4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering F. Le Faucheur Editor June 2005 ASCII 23694 13 ds-te russian dolls model multi-protocol label switching

This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tewg-diff-te-russian-07 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4127
RFC4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation W. Lai June 2005 ASCII 58691 25 PDF 201138 label switched path lsp lsp blocking lsp preemption lsp priority traffic overload bandwidth efficiency bandwidth sharing bandwidth protection class isolation maximum allocation model russian dolls model

"Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, the Maximum Allocation and the Russian Dolls, are described therein. This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing. This memo provides information for the Internet community.

draft-wlai-tewg-bcmodel-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4128
RFC4129 Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol R. Mukundan K. Morneault N. Mangalpally September 2005 ASCII 29034 15 backhauling isdn user adaptation pbx private branch exchanges

This document defines a mechanism for backhauling Digital Private Network Signaling System 1 (DPNSS 1) and Digital Access Signaling System 2 (DASS 2) messages over IP by extending the ISDN User Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network. DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN. This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation. [STANDARDS-TRACK]

draft-ietf-sigtran-dua-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC4129
RFC4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) D. Moberg R. Drummond July 2005 ASCII 99857 47 hyper text transfer protocol simple mail transfer protocol

This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335. [STANDARDS-TRACK]

draft-ietf-ediint-as2-20 PROPOSED STANDARD PROPOSED STANDARD IETF app ediint http://www.rfc-editor.org/errata_search.php?rfc=4130 10.17487/RFC4130
RFC4131 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus S. Green K. Ozawa E. Cardona Editor A. Katsnelson September 2005 ASCII 183091 85 mib snmp simple network management protocol docs-ietf-bpi2-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Baseline Privacy Plus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]

draft-ietf-ipcdn-bpiplus-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4131
RFC4132 Addition of Camellia Cipher Suites to Transport Layer Security (TLS) S. Moriai A. Kato M. Kanda July 2005 ASCII 13590 7 camellia encryption algorithm

This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]

draft-ietf-tls-camellia-06 RFC5932 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4132
RFC4133 Entity MIB (Version 3) A. Bierman K. McCloghrie August 2005 ASCII 136711 62 management information base snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). [STANDARDS-TRACK]

draft-ietf-entmib-v3-07 RFC2737 RFC6933 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=4133 10.17487/RFC4133
RFC4134 Examples of S/MIME Messages P. Hoffman Editor July 2005 ASCII 325865 136

This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This memo provides information for the Internet community.

draft-ietf-smime-examples-15 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4134 10.17487/RFC4134
RFC4135 Goals of Detecting Network Attachment in IPv6 JH. Choi G. Daley August 2005 ASCII 20518 9 dna detecting attachment links change detection

When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling. This memo provides information for the Internet community.

draft-ietf-dna-goals-04 INFORMATIONAL INFORMATIONAL IETF int dna 10.17487/RFC4135
RFC4136 OSPF Refresh and Flooding Reduction in Stable Topologies P. Pillay-Esnault July 2005 ASCII 8534 5 open shortest path first link state advertisement lsa donotage

This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies.

Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies. This memo provides information for the Internet community.

draft-pillay-esnault-ospf-flooding-07 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC4136
RFC4137 State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator J. Vollbrecht P. Eronen N. Petroni Y. Ohba August 2005 ASCII 105781 51 PDF 107470 eap stand-alone authenticator eap backend authenticator eap full authenticator

This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.

The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.

The state machine and associated model are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.

draft-ietf-eap-statemachine-06 INFORMATIONAL INFORMATIONAL IETF int eap 10.17487/RFC4137
RFC4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) P. Sarolahti M. Kojo August 2005 ASCII 55538 23 tcp transmission control protocol

Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tcpm-frto-02 RFC5682 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC4138
RFC4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) D. Papadimitriou J. Drake J. Ash A. Farrel L. Ong July 2005 ASCII 36660 16 tdm otn control plane call connection

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).

This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signaling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for the GMPLS signaling protocol to support the ASON functionality. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-ason-reqts-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4139
RFC4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6) H. Soliman C. Castelluccia K. El Malki L. Bellier August 2005 ASCII 71503 29 internet protocol version 6 neighbour discovery neighbor discovery mobility anchor point map

This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mipshop-hmipv6-04 RFC5380 EXPERIMENTAL EXPERIMENTAL IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=4140 10.17487/RFC4140
RFC4141 SMTP and MIME Extensions for Content Conversion K. Toyoda D. Crocker November 2005 ASCII 55606 26 esmtp simple mail transfer protocol extended simple mail transfer protocol multipurpose internet mail extensions

A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information (e.g., changing from color to black and white). In a store-and-forward environment, it may be convenient to have this conversion performed by an intermediary. This specification integrates two ESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries. [STANDARDS-TRACK]

draft-ietf-fax-esmtp-conneg-13 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=4141 10.17487/RFC4141
RFC4142 Full-mode Fax Profile for Internet Mail (FFPIM) D. Crocker G. Klyne November 2005 ASCII 16791 9 facsimile full mode internet mail

Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users. [PROPOSED STANDARD]

draft-ietf-fax-ffpim-08 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC4142
RFC4143 Facsimile Using Internet Mail (IFAX) Service of ENUM K. Toyoda D. Crocker November 2005 ASCII 8642 5 naptr enum naming authority pointer facsimile using internet mail dns domain name system

This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service. IFax is "facsimile using Internet mail". For this use, the Domain Name System (DNS) returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address. [STANDARDS-TRACK]

draft-ietf-fax-faxservice-enum-03 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=4143 10.17487/RFC4143
RFC4144 How to Gain Prominence and Influence in Standards Organizations D. Eastlake 3rd September 2005 ASCII 19529 9

This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations. This memo provides information for the Internet community.

draft-eastlake-prominence-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4144
RFC4145 TCP-Based Media Transport in the Session Description Protocol (SDP) D. Yon G. Camarillo September 2005 ASCII 30225 15 setup connection reestablishment

This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-comedia-10 RFC4572 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4145
RFC4146 Simple New Mail Notification R. Gellens August 2005 ASCII 8561 5 mail client nm_notifyuser

This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client.

In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail. This memo provides information for the Internet community.

draft-gellens-notify-mail-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4146
RFC4147 Proposed Changes to the Format of the IANA IPv6 Registry G. Huston August 2005 ASCII 21196 10 internet protocol version 6 address format address architecture

This document proposes a revised format for the IANA IPv6 address registries. Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format. The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format. This memo provides information for the Internet community.

draft-huston-ip6-iana-registry-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4147 10.17487/RFC4147
RFC4148 IP Performance Metrics (IPPM) Metrics Registry E. Stephan August 2005 ASCII 23074 14 internet protocol object identities iana-ippm-metrics-registry-mib

This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.

This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.

IANA has been assigned to administer this new registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ippm-metrics-registry-08 RFC6248 BCP0108 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ippm 10.17487/RFC4148
RFC4149 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms C. Kalbfleisch R. Cole D. Romascanu August 2005 ASCII 78560 39 sspm mib management information base sspm mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. [STANDARDS-TRACK]

draft-ietf-rmonmib-sspm-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4149
RFC4150 Transport Performance Metrics MIB R. Dietz R. Cole August 2005 ASCII 123144 57 managgement information base tpm tpm-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources. [STANDARDS-TRACK]

draft-ietf-rmonmib-tpm-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4150
RFC4151 The 'tag' URI Scheme T. Kindberg S. Hawke October 2005 ASCII 22555 11 uniform resource identifier entity identifier

This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community.

draft-kindberg-tag-uri-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4151 10.17487/RFC4151
RFC4152 A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code K. Tesink R. Fox August 2005 ASCII 12228 7 ansi ansi t1.213

This document describes a Uniform Resource Name (URN) namespace (RFC 3406) for the assignment of the Common Language Equipment Identifier (CLEI) code, which is used in messages standardized by ANSI. The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. The CLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number). This memo provides information for the Internet community.

draft-tesink-urn-clei-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4152
RFC4153 XML Voucher: Generic Voucher Language K. Fujimura M. Terada D. Eastlake 3rd September 2005 ASCII 41941 21 extensible markup language logical entity

This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions. This memo provides information for the Internet community.

draft-ietf-trade-voucher-lang-07 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC4153
RFC4154 Voucher Trading System Application Programming Interface (VTS-API) M. Terada K. Fujimura September 2005 ASCII 61629 32 wallet transfer redeem

This document specifies the Voucher Trading System Application Programming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates. This process is often necessary in the course of payment and/or delivery transactions. This memo provides information for the Internet community.

draft-ietf-trade-voucher-vtsapi-06 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC4154
RFC4155 The application/mbox Media Type E. Hall September 2005 ASCII 19645 9 mbox database

This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC 2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations. This memo provides information for the Internet community.

draft-hall-mime-app-mbox-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4155
RFC4156 The wais URI Scheme P. Hoffman August 2005 ASCII 6564 4 uniform resource identifier

This document specifies the wais Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.

draft-hoffman-wais-uri-03 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4156 10.17487/RFC4156
RFC4157 The prospero URI Scheme P. Hoffman August 2005 ASCII 7096 4 uniform resource identifier

This document specifies the prospero Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.

draft-hoffman-prospero-uri-03 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4157 10.17487/RFC4157
RFC4158 Internet X.509 Public Key Infrastructure: Certification Path Building M. Cooper Y. Dzambasow P. Hesse S. Joseph R. Nicholas September 2005 ASCII 199297 81 certification path discovery path discovery certificate path building certificate path discovery

This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments. This memo provides information for the Internet community.

draft-ietf-pkix-certpathbuild-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC4158
RFC4159 Deprecation of "ip6.int" G. Huston August 2005 ASCII 5353 3 ipv6 dns domain name system

This document advises of the deprecation of the use of "ip6.int" for Standards Conformant IPv6 implementations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-huston-ip6-int-03 BCP0109 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4159
RFC4160 Internet Fax Gateway Requirements K. Mimura K. Yokoyama T. Satoh C. Kanaide C. Allocchio August 2005 ASCII 24930 13 general switched telephone network facsimile service gstn fax internet fax service i-fax onramp gateway

To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required. This document provides recommendations for the functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN. This memo provides information for the Internet community.

draft-ietf-fax-gateway-protocol-13 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC4160
RFC4161 Guidelines for Optional Services for Internet Fax Gateways K. Mimura K. Yokoyama T. Satoh K. Watanabe C. Kanaide August 2005 ASCII 23189 12 general switched telephone network acsimile service gstn fax internet fax service i-fax offramp gateway onramp gateway

To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN.

This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. This memo provides information for the Internet community.

draft-ietf-fax-gateway-options-08 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC4161
RFC4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS) H.J. Lee J.H. Yoon J.I. Lee August 2005 ASCII 10578 6 encryption algorithm ciphersuite

This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]

draft-lee-tls-seed-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4162
RFC4163 RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression L-E. Jonsson August 2005 ASCII 20587 9 transmission control protocol internet protocol compression performance considerations intellectual property rights ipr

This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC. This memo provides information for the Internet community.

draft-ietf-rohc-tcp-requirements-08 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4163
RFC4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles G. Pelletier August 2005 ASCII 47088 21 context initialization short-lived

This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows. [STANDARDS-TRACK]

draft-ietf-rohc-context-replication-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4164
RFC4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA) T. George B. Bidulock R. Dantu H. Schwarzbauer K. Morneault September 2005 ASCII 114669 53 ss7 over ip ss7/ip sigtran m2ua

This document defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints. [STANDARDS-TRACK]

draft-ietf-sigtran-m2pa-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=4165 10.17487/RFC4165
RFC4166 Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement L. Coene J. Pastor-Balbas February 2006 ASCII 46659 23

This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given. This memo provides information for the Internet community.

draft-ietf-sigtran-signalling-over-sctp-applic-09 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC4166
RFC4167 Graceful OSPF Restart Implementation Report A. Lindem October 2005 ASCII 11780 6 open shortest path first

Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol. This memo provides information for the Internet community.

draft-ietf-ospf-graceful-impl-report-05 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC4167
RFC4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne G. Camarillo October 2005 ASCII 21079 10 transport mechanism

This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. [STANDARDS-TRACK]

draft-ietf-sip-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4168
RFC4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2 V. Torvinen J. Arkko M. Naslund November 2005 ASCII 26429 13 tls transport layer security tunneled authentication man-in-the-middle attacks

HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. This memo provides information for the Internet community.

draft-torvinen-http-digest-aka-v2-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4169
RFC4170 Tunneling Multiplexed Compressed RTP (TCRTP) B. Thompson T. Koren D. Wing November 2005 ASCII 48990 24 real-time transport protocol

This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-avt-tcrtp-08 BCP0110 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai avt 10.17487/RFC4170
RFC4171 Internet Storage Name Service (iSNS) J. Tseng K. Gibbons F. Travostino C. Du Laney J. Souza September 2005 ASCII 310636 123 isns servers isns clients fibre channel devices ifcp intelligent storage discovery

This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. [STANDARDS-TRACK]

draft-ietf-ips-isns-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4171 10.17487/RFC4171
RFC4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking C. Monia R. Mullendore F. Travostino W. Jeong M. Edwards September 2005 ASCII 241908 111 gateway-to-gateway fibre channel fabric tcp transport control protocol

This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network. [STANDARDS-TRACK]

draft-ietf-ips-ifcp-14 RFC6172 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4172
RFC4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol P. Sarkar D. Missimer C. Sapuntzakis September 2005 ASCII 27105 12 scsi tcp transport control protocol boot server

Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-boot-12 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4173 10.17487/RFC4173
RFC4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service C. Monia J. Tseng K. Gibbons September 2005 ASCII 29485 13 isns internet storage name service iscsi internet scsi ifcp internet fibre channel storage devices

This document describes the Dynamic Host Configuration Protocol (DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network. [STANDARDS-TRACK]

draft-ietf-dhc-isnsoption-13 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4174
RFC4175 RTP Payload Format for Uncompressed Video L. Gharai C. Perkins September 2005 ASCII 39431 18 packetization scheme real-time transport protocol real time transport protocol smpte society of motion picture television engineers video formats

This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. [STANDARDS-TRACK]

draft-ietf-avt-uncomp-video-06 RFC4421 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4175
RFC4176 Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management Y. El Mghazli Editor T. Nadeau M. Boucadair K. Chan A. Gonguet October 2005 ASCII 46348 21

This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community.

draft-ietf-l3vpn-mgt-fwk-08 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4176
RFC4177 Architectural Approaches to Multi-homing for IPv6 G. Huston September 2005 ASCII 95374 36 internet protocol

This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. This memo provides information for the Internet community.

draft-ietf-multi6-architecture-04 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4177
RFC4178 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism L. Zhu P. Leach K. Jaganathan W. Ingersoll October 2005 ASCII 46485 22 generic service application security program interface

This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers.

This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet. [STANDARDS-TRACK]

draft-ietf-kitten-2478bis-05 RFC2478 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC4178
RFC4179 Using Universal Content Identifier (UCI) as Uniform Resource Names (URN) S. Kang October 2005 ASCII 12935 7 nca national computerization agency digital resources

This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA. This memo provides information for the Internet community.

draft-sangug-uci-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4179
RFC4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files Y. Shafranovich October 2005 ASCII 12931 8 text/csv

This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community.

draft-shafranovich-mime-csv-05 RFC7111 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4180
RFC4181 Guidelines for Authors and Reviewers of MIB Documents C. Heard Editor September 2005 ASCII 102521 42 standards-track specifications management information base review

This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ops-mib-review-guidelines-04 RFC4841 BCP0111 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4181 10.17487/RFC4181
RFC4182 Removing a Restriction on the use of MPLS Explicit NULL E. Rosen September 2005 ASCII 14087 7 multiprotocol label switching ipv4 explicit null

The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.

This document updates RFC 3032. [STANDARDS-TRACK]

draft-ietf-mpls-explicit-null-02 RFC3032 RFC5462 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4182 10.17487/RFC4182
RFC4183 A Suggested Scheme for DNS Resolution of Networks and Gateways E. Warnicke September 2005 ASCII 18357 9 domain name space ip address internet protocol address netmask first-hop router subnet

This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet. This memo provides information for the Internet community.

draft-warnicke-network-dns-resolution-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4183
RFC4184 RTP Payload Format for AC-3 Audio B. Link T. Hager J. Flaks October 2005 ASCII 25202 13 real time transport protocol audio compression

This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation. [STANDARDS-TRACK]

draft-ietf-avt-rtp-ac3-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4184
RFC4185 National and Local Characters for DNS Top Level Domain (TLD) Names J. Klensin October 2005 ASCII 50926 19 domain name system multilingual internationalized local translation

In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about "multilingual" or "internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country. This memo provides information for the Internet community.

draft-klensin-idn-tld-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4185
RFC4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) H. Haverinen Editor J. Salowey Editor January 2006 ASCII 220807 92 3gpp

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. This memo provides information for the Internet community.

draft-haverinen-pppext-eap-sim-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4186 10.17487/RFC4186
RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) J. Arkko H. Haverinen January 2006 ASCII 194958 79 3gpp universal mobile telecommunications system umts

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.

EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.

draft-arkko-pppext-eap-aka-15 RFC5448 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4187 10.17487/RFC4187
RFC4188 Definitions of Managed Objects for Bridges K. Norseth Editor E. Bell Editor September 2005 ASCII 86877 44 BRIDGE-MIB SNMP MIB standard standards management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.

The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.

This memo obsoletes RFC 1493. [STANDARDS-TRACK]

draft-ietf-bridge-bridgemib-smiv2-10 RFC1493 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge http://www.rfc-editor.org/errata_search.php?rfc=4188 10.17487/RFC4188
RFC4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP) K. Ono S. Tachimoto October 2005 ASCII 25842 12 user agent ua intermediaries

A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. This memo provides information for the Internet community.

draft-ietf-sipping-e2m-sec-reqs-06 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4189
RFC4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony K. Carlberg I. Brown C. Beard November 2005 ASCII 69447 28 disaster communications prioritized voip

This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. This memo provides information for the Internet community.

draft-ietf-ieprep-framework-10 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC4190
RFC4191 Default Router Preferences and More-Specific Routes R. Draves D. Thaler November 2005 ASCII 34672 15 router advertisement

This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]

draft-ietf-ipv6-router-selection-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4191 10.17487/RFC4191
RFC4192 Procedures for Renumbering an IPv6 Network without a Flag Day F. Baker E. Lear R. Droms September 2005 ASCII 52110 22 prefix internet protocol network interface make-before-break enterprise connecting routers

This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. This memo provides information for the Internet community.

draft-ietf-v6ops-renumbering-procedure-05 RFC2072 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4192
RFC4193 Unique Local IPv6 Unicast Addresses R. Hinden B. Haberman October 2005 ASCII 35908 16 internet protocol local communication

This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]

draft-ietf-ipv6-unique-local-addr-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4193
RFC4194 The S Hexdump Format J. Strombergson L. Walleij P. Faltstrom October 2005 ASCII 25727 13 shf standard hex format secure hash standard shs sha-1 nist fips 180-2 binary data dump format hexadecimal intel hex format s-rec extensible markup language xml

This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format. [STANDARDS-TRACK]

draft-strombergson-shf-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4194
RFC4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum W. Kameyama October 2005 ASCII 10066 6 digital broadcasting tv radio storage systems metadata schemas

This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents. This memo provides information for the Internet community.

draft-kameyama-tv-anytime-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4195
RFC4196 The SEED Cipher Algorithm and Its Use with IPsec H.J. Lee J.H. Yoon S.L. Lee J.I. Lee October 2005 ASCII 22587 12 ipsec esp encryption algorithm

This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

draft-lee-ipsec-cipher-seed-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4196
RFC4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks M. Riegel Editor October 2005 ASCII 47937 24 digital signatures plesiochronous digital hierarchy sonet synchronous optical network sdh synchronous digital hierarchy pwe3 pseudo wire emulation

This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits. This memo provides information for the Internet community.

draft-ietf-pwe3-tdm-requirements-08 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4197 10.17487/RFC4197
RFC4198 A Uniform Resource Name (URN) Namespace for Federated Content D. Tessman November 2005 ASCII 12134 7 content resource content collections

This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections. A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members. This memo provides information for the Internet community.

draft-dtessman-urn-namespace-federated-content-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4198
RFC4201 Link Bundling in MPLS Traffic Engineering (TE) K. Kompella Y. Rekhter L. Berger October 2005 ASCII 27033 12 multiprotocol label switching generalized multiprotocol label switching gmpls lsp label switched path interface identification tlvs

For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description. [STANDARDS-TRACK]

draft-ietf-mpls-bundle-06 RFC3471 RFC3472 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4201
RFC4202 Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII 57333 27 open shortest path first

This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-routing-09 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4202
RFC4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII 23130 11 open shortest path first

This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]

draft-ietf-ccamp-ospf-gmpls-extensions-12 RFC3630 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4203
RFC4204 Link Management Protocol (LMP) J. Lang Editor October 2005 ASCII 186515 86 gmpls sonet sdh discovery link verification fault managment control channel management link property correlation traffic engineering links trace monitoring

For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK]

draft-ietf-ccamp-lmp-10 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4204 10.17487/RFC4204
RFC4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII 22323 11

This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). This memo provides information for the Internet community.

draft-ietf-isis-gmpls-extensions-19 RFC5307 RFC3784 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC4205
RFC4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) K. Kompella Y. Rekhter October 2005 ASCII 31965 14 lsr label switching router te lsp fa forwarding adjacency

To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).

This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]

draft-ietf-mpls-lsp-hierarchy-08 RFC6001 RFC6107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4206
RFC4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages J. Lang D. Papadimitriou October 2005 ASCII 29390 15 gmpls discovery link verification fault management control channel management link property correlation traffic engineering links trace monitoring

This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. [STANDARDS-TRACK]

draft-ietf-ccamp-lmp-test-sonet-sdh-04 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4207 10.17487/RFC4207
RFC4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model G. Swallow J. Drake H. Ishimatsu Y. Rekhter October 2005 ASCII 28693 13 lsp label switched paths routing protocol signaling protocol

Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-overlay-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4208
RFC4209 Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems A. Fredette Editor J. Lang Editor October 2005 ASCII 33906 16 te traffic engineering peer nodes ols optical link interface requirements

The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document. [STANDARDS-TRACK]

draft-ietf-ccamp-lmp-wdm-03 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4209
RFC4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) C. Adams S. Farrell T. Kause T. Mononen September 2005 ASCII 212013 95 PKICMP cryptographic authentication pkix pki X.509v3 certificate creation certificate management ca certification authority

This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]

draft-ietf-pkix-rfc2510bis-09 RFC2510 RFC6712 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4210 10.17487/RFC4210
RFC4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) J. Schaad September 2005 ASCII 86136 40 X.509-CRMF certification authority ca registration authority ra pkix pki certificate production crmf security encryption authenticaion

This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]

draft-ietf-pkix-rfc2511bis-08 RFC2511 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4211 10.17487/RFC4211
RFC4212 Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols M. Blinov C. Adams October 2005 ASCII 41757 19 X.509v3 public-key certificates crmf certificate request message format pkix certificate management protocol pkix-cmp certificate management messages over cms cmc

The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC). This memo provides information for the Internet community.

draft-adams-cmpaltcert-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4212
RFC4213 Basic Transition Mechanisms for IPv6 Hosts and Routers E. Nordmark R. Gilligan October 2005 ASCII 58575 27 TRANS-IPV6 ipv4 dual sack configured tunneling

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.

This document obsoletes RFC 2893. [STANDARDS-TRACK]

draft-ietf-v6ops-mech-v2-07 RFC2893 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4213 10.17487/RFC4213
RFC4214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin T. Gleeson M. Talwar D. Thaler October 2005 ASCII 27811 14 ISATAP] ipv4 link layer nbma non-broadcast multiple access

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ngtrans-isatap-22 RFC5214 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4214
RFC4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks J. Wiljakka Editor October 2005 ASCII 52903 24 internet protocol gprs general packet radio service global system for mobile communications gsm universal mobile telecommunications system umts wideband code division multiple access wcdma

This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.

The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. This memo provides information for the Internet community.

draft-ietf-v6ops-3gpp-analysis-11 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4215
RFC4216 MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements R. Zhang Editor J.-P. Vasseur Editor November 2005 ASCII 64640 29 inter-as mpls-te

This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios. This memo provides information for the Internet community.

draft-ietf-tewg-interas-mpls-te-req-09 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC4216
RFC4217 Securing FTP with TLS P. Ford-Hutchinson October 2005 ASCII 61180 29 security authentication file transfer protocol transport layer security

This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".

This specification is in accordance with RFC 959, "File Transfer Protocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions". [STANDARDS-TRACK]

draft-murray-auth-ftp-ssl-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4217 10.17487/RFC4217
RFC4218 Threats Relating to IPv6 Multihoming Solutions E. Nordmark T. Li October 2005 ASCII 75969 31 security threats internet protocol version 6

This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.

The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. This memo provides information for the Internet community.

draft-ietf-multi6-multihoming-threats-03 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4218
RFC4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About E. Lear October 2005 ASCII 25141 12 security threats internet protocol version 6

This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution. This memo provides information for the Internet community.

draft-ietf-multi6-things-to-think-about-01 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4219
RFC4220 Traffic Engineering Link Management Information Base M. Dubuc T. Nadeau J. Lang November 2005 ASCII 104566 54 mib network management protocols te te-link-std-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. [STANDARDS-TRACK]

draft-ietf-mpls-telink-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4220
RFC4221 Multiprotocol Label Switching (MPLS) Management Overview T. Nadeau C. Srinivasan A. Farrel November 2005 ASCII 70291 32 mib management information base management architecture network management

A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.

This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management. This memo provides information for the Internet community.

draft-ietf-mpls-mgmt-overview-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4221
RFC4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance G. Choudhury Editor October 2005 ASCII 34132 15 open shortest path first lsa link state advertisement

This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol. The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ospf-scalability-09 BCP0112 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg ospf 10.17487/RFC4222
RFC4223 Reclassification of RFC 1863 to Historic P. Savola October 2005 ASCII 5123 3 BGP-IDRP border gateway protocol inter-domain routing

This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also obsoletes RFC 1863. This memo provides information for the Internet community.

draft-ietf-idr-rfc1863-historic-00 RFC1863 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4223
RFC4224 RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets G. Pelletier L-E. Jonsson K. Sandlund January 2006 ASCII 49416 21

RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. This memo provides information for the Internet community.

draft-ietf-rohc-over-reordering-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4224
RFC4225 Mobile IP Version 6 Route Optimization Security Design Background P. Nikander J. Arkko T. Aura G. Montenegro E. Nordmark December 2005 ASCII 98584 37 mipv6 mip

This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.

The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs. This memo provides information for the Internet community.

draft-ietf-mip6-ro-sec-03 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4225
RFC4226 HOTP: An HMAC-Based One-Time Password Algorithm D. M'Raihi M. Bellare F. Hoornaert D. Naccache O. Ranen December 2005 ASCII 77117 37 hashed message authentication code security analysis oath open authentication authentication OATH

This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.

This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This memo provides information for the Internet community.

draft-mraihi-oath-hmac-otp-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4226 10.17487/RFC4226
RFC4227 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) E. O'Tuathail M. Rose January 2006 ASCII 39112 21 xml extensible markup language remote procedure calling rpc asynchronous event notification unacknowledged messages binding

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.

The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. [STANDARDS-TRACK]

draft-mrose-rfc3288bis-02 RFC3288 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4227 10.17487/RFC4227
RFC4228 Requirements for an IETF Draft Submission Toolset A. Rousskov December 2005 ASCII 76952 31 automation tool

This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. This memo provides information for the Internet community.

draft-ietf-tools-draft-submission-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4228
RFC4229 HTTP Header Field Registrations M. Nottingham J. Mogul December 2005 ASCII 70879 53 hyper text transfer protocol

This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864. This memo provides information for the Internet community.

draft-nottingham-hdrreg-http-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4229 10.17487/RFC4229
RFC4230 RSVP Security Properties H. Tschofenig R. Graveman December 2005 ASCII 121030 48 resource reservation protocol

This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. This memo provides information for the Internet community.

draft-ietf-nsis-rsvp-sec-properties-06 INFORMATIONAL INFORMATIONAL IETF tsv nsis http://www.rfc-editor.org/errata_search.php?rfc=4230 10.17487/RFC4230
RFC4231 Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 M. Nystrom December 2005 ASCII 17725 9 message authentication codes message authentication schemes

This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]

draft-nystrom-smime-hmac-sha-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4231 10.17487/RFC4231
RFC4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer K. Morneault S. Rengasami M. Kalla G. Sidebottom January 2006 ASCII 157857 73 stream control transmission protocol sctp signaling gateway sg media gateway controller mgc signaling media gateway interface

This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.

This document obsoletes RFC 3057. [STANDARDS-TRACK]

draft-ietf-sigtran-rfc3057bis-02 RFC3057 RFC5133 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC4233
RFC4234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell October 2005 ASCII 26351 16 ABNF] backus-naur form augmented backus-naur form rule definitions encoding core lexical analyzer electronic mail

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

draft-crocker-abnf-rfc2234bis-00 RFC2234 RFC5234 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4234 10.17487/RFC4234
RFC4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne R. Mahy Editor November 2005 ASCII 83268 39 sip events dialog package

This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved. [STANDARDS-TRACK]

draft-ietf-sipping-dialog-package-06 RFC7463 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4235 10.17487/RFC4235
RFC4236 HTTP Adaptation with Open Pluggable Edge Services (OPES) A. Rousskov M. Stecher November 2005 ASCII 53512 27 callout protocol ocp opes tracing opes bypass

Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES. [STANDARDS-TRACK]

draft-ietf-opes-http-03 PROPOSED STANDARD PROPOSED STANDARD IETF app opes 10.17487/RFC4236
RFC4237 Voice Messaging Directory Service G. Vaudreuil October 2005 ASCII 26093 13 vpim voice profile for internet mail

This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.

The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one from Anne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission. [STANDARDS-TRACK]

draft-ietf-vpim-vpimdir-11 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim http://www.rfc-editor.org/errata_search.php?rfc=4237 10.17487/RFC4237
RFC4238 Voice Message Routing Service G. Vaudreuil October 2005 ASCII 18902 10 vpim telephone number addressing voice profile and intenret mail vpim directory

Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. [STANDARDS-TRACK]

draft-ietf-vpim-routing-10 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim http://www.rfc-editor.org/errata_search.php?rfc=4238 10.17487/RFC4238
RFC4239 Internet Voice Messaging (IVM) S. McRae G. Parsons November 2005 ASCII 24867 11 voicemail vpim voice profile for internet mail

This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.

The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application. [STANDARDS-TRACK]

draft-ietf-vpim-ivm-06 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC4239
RFC4240 Basic Network Media Services with SIP E. Burger Editor J. Van Dyke A. Spitzer December 2005 ASCII 54976 24 session initiation protocol network media services media servers application servers

In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.

This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. This memo provides information for the Internet community.

draft-burger-sipping-netann-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4240 10.17487/RFC4240
RFC4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service Y. Shirasaki S. Miyakawa T. Yamasaki A. Takenouchi December 2005 ASCII 20580 10 user network specification ntt communications adsl cpe customer preises equipment

This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. This memo provides information for the Internet community.

draft-shirasaki-dualstack-service-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4241 10.17487/RFC4241
RFC4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) S. Venaas T. Chown B. Volz November 2005 ASCII 14759 8 internet protocol

This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK]

draft-ietf-dhc-lifetime-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4242
RFC4243 Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option M. Stapp R. Johnson T. Palaniappan December 2005 ASCII 14342 7

This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator. [STANDARDS-TRACK]

draft-ietf-dhc-vendor-suboption-00 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4243
RFC4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information M. Barnes Editor November 2005 ASCII 98992 44 history-info retarget enhanced services voicemail automatic call distribution

This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. [STANDARDS-TRACK]

draft-ietf-sip-history-info-06 RFC7044 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4244 10.17487/RFC4244
RFC4245 High-Level Requirements for Tightly Coupled SIP Conferencing O. Levin R. Even November 2005 ASCII 24415 12 session initiation protocol

This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. This memo provides information for the Internet community.

draft-ietf-sipping-conferencing-requirements-01 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4245
RFC4246 International Standard Audiovisual Number (ISAN) URN Definition M. Dolan February 2006 ASCII 10312 6 numbering system international identification audiovisual uniform resource identifier

The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works. This document is the definition of the formal Uniform Resource Name (URN) Namespace Identifier (NID) for ISAN. This memo provides information for the Internet community.

draft-dolan-urn-isan-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4246
RFC4247 Requirements for Header Compression over MPLS J. Ash B. Goode J. Hand R. Zhang November 2005 ASCII 25127 11 multiprotocol label switching voip voice over ip

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario. This memo provides information for the Internet community.

draft-ietf-avt-hc-mpls-reqs-03 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC4247
RFC4248 The telnet URI Scheme P. Hoffman October 2005 ASCII 7292 4 uniform resource identifier url uniform resource locators

This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]

draft-hoffman-telnet-uri-05 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4248
RFC4249 Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components B. Lilly January 2006 ASCII 28731 14 header field generator header field parser

Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer. This memo identifies information useful to implementers of header field generators and parsers. This memo provides information for the Internet community.

draft-lilly-field-specification-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4249
RFC4250 The Secure Shell (SSH) Protocol Assigned Numbers S. Lehtinen C. Lonvick Editor January 2006 ASCII 44010 20 remote login

This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK]

draft-ietf-secsh-assignednumbers-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4250
RFC4251 The Secure Shell (SSH) Protocol Architecture T. Ylonen C. Lonvick Editor January 2006 ASCII 71750 30 remote login ssh algorithm

The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK]

draft-ietf-secsh-architecture-22 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4251
RFC4252 The Secure Shell (SSH) Authentication Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII 34268 17 remote login public key password host-based client authentication

The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]

draft-ietf-secsh-userauth-27 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4252 10.17487/RFC4252
RFC4253 The Secure Shell (SSH) Transport Layer Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII 68263 32 remote login encryption server authentication integrity protection diffie-hellman key exchange diffie hellman

The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.

Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.

This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]

draft-ietf-secsh-transport-24 RFC6668 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4253 10.17487/RFC4253
RFC4254 The Secure Shell (SSH) Connection Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII 50338 24 remote login interactive login remote execution encrypted tunnel

Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.

The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. [STANDARDS-TRACK]

draft-ietf-secsh-connect-25 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4254 10.17487/RFC4254
RFC4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints J. Schlyter W. Griffin January 2006 ASCII 18399 9 domain name system dnssec domain name system security

This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. [STANDARDS-TRACK]

draft-ietf-secsh-dns-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4255 10.17487/RFC4255
RFC4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) F. Cusack M. Forssen January 2006 ASCII 24728 12 remote login alphanumeric input

The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). [STANDARDS-TRACK]

draft-ietf-secsh-auth-kbdinteract-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4256 10.17487/RFC4256
RFC4257 Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks G. Bernstein E. Mannie V. Sharma E. Gray December 2005 ASCII 86974 35 mpls optical switching sdh sonet

Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. This memo provides information for the Internet community.

draft-ietf-ccamp-sdhsonet-control-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4257
RFC4258 Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) D. Brungard Editor November 2005 ASCII 48558 22 control domain hierarchy multi-level multi-layer inter-domain intra-domain e-nni i-nni uni

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).

This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-ason-routing-reqts-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4258
RFC4259 A Framework for Transmission of IP Datagrams over MPEG-2 Networks M.-J. Montpetit G. Fairhurst H. Clausen B. Collini-Nocker H. Linder November 2005 ASCII 100423 42 digital television dvb digital video broadcast atsc advanced television systems committee

This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television.

The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. This memo provides information for the Internet community.

draft-ietf-ipdvb-arch-04 INFORMATIONAL INFORMATIONAL IETF int ipdvb 10.17487/RFC4259
RFC4260 Mobile IPv6 Fast Handovers for 802.11 Networks P. McCann November 2005 ASCII 35276 15 link layer

This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications. This memo provides information for the Internet community.

draft-ietf-mipshop-80211fh-04 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC4260
RFC4261 Common Open Policy Service (COPS) Over Transport Layer Security (TLS) J. Walker A. Kulkarni Editor December 2005 ASCII 28662 14 client-accept message

This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.

This document also updates RFC 2748 by modifying the contents of the Client-Accept message. [STANDARDS-TRACK]

draft-ietf-rap-cops-tls-11 RFC2748 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC4261
RFC4262 X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities S. Santesson December 2005 ASCII 9801 5 cryptographic capabilities

This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDS-TRACK]

draft-ietf-smime-certcapa-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC4262
RFC4263 Media Subtype Registration for Media Type text/troff B. Lilly January 2006 ASCII 33371 16

A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described. This memo provides information for the Internet community.

draft-lilly-text-troff-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4263
RFC4264 BGP Wedgies T. Griffin G. Huston November 2005 ASCII 24139 10 border gateway protocol

It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". This memo provides information for the Internet community.

draft-ietf-grow-bgp-wedgies-03 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC4264
RFC4265 Definition of Textual Conventions for Virtual Private Network (VPN) Management B. Schliesser T. Nadeau November 2005 ASCII 10976 6 tc

This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). [STANDARDS-TRACK]

draft-ietf-l3vpn-tc-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn 10.17487/RFC4265
RFC4266 The gopher URI Scheme P. Hoffman November 2005 ASCII 12083 6 uniform resource identifier url

This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]

draft-hoffman-gopher-uri-03 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4266
RFC4267 The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml M. Froumentin November 2005 ASCII 17753 9 voice browser voice extensible markup language voicexml speech synthesis markup language ssml speech recognition grammar specification srgs call control xml ccxml pronunciation lexicon specification pls

This document defines the media types for the languages of the W3C Speech Interface Framework, as designed by the Voice Browser Working Group in the following specifications: the Voice Extensible Markup Language (VoiceXML), the Speech Synthesis Markup Language (SSML), the Speech Recognition Grammar Specification (SRGS), the Call Control XML (CCXML), and the Pronunciation Lexicon Specification (PLS). This memo provides information for the Internet community.

draft-froumentin-voice-mediatypes-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4267
RFC4268 Entity State MIB S. Chisholm D. Perkins November 2005 ASCII 40348 19 management information base snmp entity-state-tc-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the Entity MIB to provide information about the state of physical entities.

In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that these Textual Conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-entmib-state-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=4268 10.17487/RFC4268
RFC4269 The SEED Encryption Algorithm H.J. Lee S.J. Lee J.H. Yoon D.H. Cheon J.I. Lee December 2005 ASCII 34390 16 encryption algorithm seed cbc seed oid

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).

This document obsoletes RFC 4009. This memo provides information for the Internet community.

draft-lee-rfc4009bis-02 RFC4009 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4269
RFC4270 Attacks on Cryptographic Hashes in Internet Protocols P. Hoffman B. Schneier November 2005 ASCII 26641 12 collision attacks hash algorithms ip digital certificates

Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. This memo provides information for the Internet community.

draft-hoffman-hash-attacks-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4270 10.17487/RFC4270
RFC4271 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter Editor T. Li Editor S. Hares Editor January 2006 ASCII 222702 104 BGP-4 routing

This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.

The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.

This document obsoletes RFC 1771. [STANDARDS-TRACK]

draft-ietf-idr-bgp4-26 RFC1771 RFC6286 RFC6608 RFC6793 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4271 10.17487/RFC4271
RFC4272 BGP Security Vulnerabilities Analysis S. Murphy January 2006 ASCII 53119 22 border gateway protocol attacks risks insider threat

Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.

This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.

draft-ietf-idr-bgp-vuln-01 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4272
RFC4273 Definitions of Managed Objects for BGP-4 J. Haas Editor S. Hares Editor January 2006 ASCII 65629 32 BGP-4-MIB management information base mib border gateway protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower.

The origin of this memo is from RFC 1269 "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents.

This memo is intended to document deployed implementations of this MIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions.

This document obsoletes RFC 1269 and RFC 1657. [STANDARDS-TRACK]

draft-ietf-idr-bgp4-mib-15 RFC1269 RFC1657 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4273 10.17487/RFC4273
RFC4274 BGP-4 Protocol Analysis D. Meyer K. Patel January 2006 ASCII 38200 16 border gateway protocol

The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).

This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community.

draft-ietf-idr-bgp-analysis-07 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4274 10.17487/RFC4274
RFC4275 BGP-4 MIB Implementation Survey S. Hares D. Hares January 2006 ASCII 77598 37 border gateway protocol management information base

This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification. This memo provides information for the Internet community.

draft-ietf-idr-bgp-mibagent-survey-02 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4275 10.17487/RFC4275
RFC4276 BGP-4 Implementation Report S. Hares A. Retana January 2006 ASCII 132864 97 border gateway protocol

This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia).

The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. This memo provides information for the Internet community.

draft-ietf-idr-bgp-implementation-02 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4276
RFC4277 Experience with the BGP-4 Protocol D. McPherson K. Patel January 2006 ASCII 45117 19 border gateway protocol

The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).

This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. This memo provides information for the Internet community.

draft-ietf-idr-bgp4-experience-protocol-05 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4277 10.17487/RFC4277
RFC4278 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification S. Bellovin A. Zinin January 2006 ASCII 14483 7 border gateway protocol

The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level. This memo provides information for the Internet community.

draft-iesg-tcpmd5app-01 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC4278
RFC4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) P. Eronen Editor H. Tschofenig Editor December 2005 ASCII 32160 15 psk psks symmetric keys diffie-hellman

This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]

draft-ietf-tls-psk-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4279
RFC4280 Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers K. Chowdhury P. Yegani L. Madour November 2005 ASCII 23001 11 bcmcs 3g third generation cellular telephone mobile node mn

This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes. [STANDARDS-TRACK]

draft-ietf-dhc-bcmc-options-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4280 10.17487/RFC4280
RFC4281 The Codecs Parameter for "Bucket" Media Types R. Gellens D. Singer P. Frojdh November 2005 ASCII 25529 29 codec container audio video 3gpp 3gpp2

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered.

This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) [STANDARDS-TRACK]

draft-gellens-mime-bucket-04 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4281 10.17487/RFC4281
RFC4282 The Network Access Identifier B. Aboba M. Beadles J. Arkko P. Eronen December 2005 ASCII 34421 16 NAI nai roaming tunneling

In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \%customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and \%ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS-TRACK]

draft-ietf-radext-rfc2486bis-06 RFC2486 RFC7542 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4282 10.17487/RFC4282
RFC4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6) A. Patel K. Leung M. Khalil H. Akhtar K. Chowdhury November 2005 ASCII 14653 8 mobility header mobile nodes correspondent nodes home agents

Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header. [STANDARDS-TRACK]

draft-ietf-mip6-mn-ident-option-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4283 10.17487/RFC4283
RFC4284 Identity Selection Hints for the Extensible Authentication Protocol (EAP) F. Adrangi V. Lortz F. Bari P. Eronen January 2006 ASCII 30322 14 nai network access identifier

The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.

The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. This memo provides information for the Internet community.

draft-adrangi-eap-network-discovery-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4284
RFC4285 Authentication Protocol for Mobile IPv6 A. Patel K. Leung M. Khalil H. Akhtar K. Chowdhury January 2006 ASCII 40874 19 ip security ipsec mip6 mobile node home agent

IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. This memo provides information for the Internet community.

draft-ietf-mip6-auth-protocol-07 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4285 10.17487/RFC4285
RFC4286 Multicast Router Discovery B. Haberman J. Martin December 2005 ASCII 35540 18 igmp internet group management protocol mld multicast listener discovery mrd

The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.

This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. [STANDARDS-TRACK]

draft-ietf-magma-mrdisc-07 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4286 10.17487/RFC4286
RFC4287 The Atom Syndication Format M. Nottingham Editor R. Sayre Editor December 2005 ASCII 81922 43 xml-basd web content metadata

This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK]

draft-ietf-atompub-format-11 RFC5988 PROPOSED STANDARD PROPOSED STANDARD IETF app atompub 10.17487/RFC4287
RFC4288 Media Type Specifications and Registration Procedures N. Freed J. Klensin December 2005 ASCII 52667 24 mime multipurpose internet mail extensions media types

This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-freed-media-type-reg-05 RFC2048 RFC6838 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4288 10.17487/RFC4288
RFC4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed J. Klensin December 2005 ASCII 21502 11 media types external body access content-transfer-encodings

This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-freed-mime-p4-07 RFC2048 BCP0013 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4289
RFC4290 Suggested Practices for Registration of Internationalized Domain Names (IDN) J. Klensin December 2005 ASCII 71115 28 chinese domain names japanese domain names korean domain names

This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names. This memo provides information for the Internet community.

draft-klensin-reg-guidelines-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4290
RFC4291 IP Version 6 Addressing Architecture R. Hinden S. Deering February 2006 ASCII 52897 25 internet protocol version 6 unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.

This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]

draft-ietf-ipv6-addr-arch-v4-04 RFC3513 RFC5952 RFC6052 RFC7136 RFC7346 RFC7371 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4291 10.17487/RFC4291
RFC4292 IP Forwarding Table MIB B. Haberman April 2006 ASCII 69321 34 TABLE-MIB Management Information Base Internet Protocol

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner. This document obsoletes RFC 2096. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2096-update-07 RFC2096 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4292
RFC4293 Management Information Base for the Internet Protocol (IP) S. Routhier Editor April 2006 ASCII 242243 122 MIB-IP IP Simple Network Management Protocol MIB ipv6 ICMPv6-MIB| mib internet protocol ip mib ipv4 mib ipv6 mib icmp mib icmpv6 mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2011-update-10 RFC2011 RFC2465 RFC2466 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4293 10.17487/RFC4293
RFC4294 IPv6 Node Requirements J. Loughney Editor April 2006 ASCII 39125 20 internet protocol version 6

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This memo provides information for the Internet community.

draft-ietf-ipv6-node-requirements-11 RFC6434 RFC5095 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4294 10.17487/RFC4294
RFC4295 Mobile IPv6 Management Information Base G. Keeni K. Koide K. Nagami S. Gundavelli April 2006 ASCII 209038 109 mib mipv6

This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. [STANDARDS-TRACK]

draft-ietf-mip6-mipv6-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4295 10.17487/RFC4295
RFC4296 The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols S. Bailey T. Talpey December 2005 ASCII 43907 22 rddp warp

This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. This memo provides information for the Internet community.

draft-ietf-rddp-arch-07 INFORMATIONAL INFORMATIONAL IETF tsv rddp http://www.rfc-editor.org/errata_search.php?rfc=4296 10.17487/RFC4296
RFC4297 Remote Direct Memory Access (RDMA) over IP Problem Statement A. Romanow J. Mogul T. Talpey S. Bailey December 2005 ASCII 48514 20 overhead copy avoidance

Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and the Internet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.

This document examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA). This memo provides information for the Internet community.

draft-ietf-rddp-problem-statement-05 INFORMATIONAL INFORMATIONAL IETF tsv rddp 10.17487/RFC4297
RFC4298 RTP Payload Format for BroadVoice Speech Codecs J.-H. Chen W. Lee J. Thyssen December 2005 ASCII 30099 14 real time transport narroband wideband bv16 broadvoice16 sdp session description protocol

This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avt-rtp-bv-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4298
RFC4301 Security Architecture for the Internet Protocol S. Kent K. Seo December 2005 ASCII 262123 101 IPSEC ipsec authentication encapsulation IP IPv4 IPv6 IP-layer ip authentication header ip security IPsec confidentiality authentication integrity anti-replay ah esp encapsulating security payload ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]

draft-ietf-ipsec-rfc2401bis-06 RFC2401 RFC3168 RFC6040 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4301 10.17487/RFC4301
RFC4302 IP Authentication Header S. Kent December 2005 ASCII 82328 34 IP-AUTH ipsec Internet Protocol AH security IPv4 IPv6 ip security confidentiality authentication integrity anti-replay ah esp encapsulating security payload ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]

draft-ietf-ipsec-rfc2402bis-10 RFC2402 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4302 10.17487/RFC4302
RFC4303 IP Encapsulating Security Payload (ESP) S. Kent December 2005 ASCII 114315 44 ESP ipsec internet protocol encapsulating security ipv4 ipv6 ip security confidentiality authentication integrity anti-replay ah ip authentication header ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]

draft-ietf-ipsec-esp-v3-10 RFC2406 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4303 10.17487/RFC4303
RFC4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) S. Kent December 2005 ASCII 9243 5 ipsecurity anti-replay ah ip authentication header esp encapsulating security payload ike internet key exchange ikev2

The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64-bit) sequence numbers (ESNs) for a particular AH or ESP security association. [STANDARDS-TRACK]

draft-ietf-ipsec-esn-addendum-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC4304
RFC4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) D. Eastlake 3rd December 2005 ASCII 17991 9 ESP ipsec authentication mechanism header security architecture payload internet protocol encapsulating ipv4 ipv6

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

draft-ietf-ipsec-esp-ah-algorithms-02 RFC2402 RFC2406 RFC4835 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4305 10.17487/RFC4305
RFC4306 Internet Key Exchange (IKEv2) Protocol C. Kaufman Editor December 2005 ASCII 250941 99 ISAKMPSEC ipsec internet protocol security association key management ipsec cryptography authentication IKE oakley isakmp

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).

This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.

Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. [STANDARDS-TRACK]

draft-ietf-ipsec-ikev2-17 RFC2407 RFC2408 RFC2409 RFC5996 RFC5282 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4306 10.17487/RFC4306
RFC4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) J. Schiller December 2005 ASCII 12985 6 ipsec ike internet key exchange

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

draft-ietf-ipsec-ikev2-algorithms-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4307 10.17487/RFC4307
RFC4308 Cryptographic Suites for IPsec P. Hoffman December 2005 ASCII 13127 7 ike internet key exchange ikev2 security algorithms ikev1

The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2. [STANDARDS-TRACK]

draft-ietf-ipsec-ui-suites-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4308 10.17487/RFC4308
RFC4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) R. Housley December 2005 ASCII 28998 13 cbc-mac mode initialization vector iv confidentiality data origin authentication connectionless integrity

This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]

draft-ietf-ipsec-ciph-aes-ccm-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4309 10.17487/RFC4309
RFC4310 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck December 2005 ASCII 46326 22 dnssec domain name system security extensions

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. [STANDARDS-TRACK]

draft-hollenbeck-epp-secdns-08 RFC5910 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4310
RFC4311 IPv6 Host-to-Router Load Sharing R. Hinden D. Thaler November 2005 ASCII 10156 5 internet protocol version 6 conceptual sending algorithm

The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. [STANDARDS-TRACK]

draft-ietf-ipv6-host-load-sharing-04 RFC2461 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4311
RFC4312 The Camellia Cipher Algorithm and Its Use With IPsec A. Kato S. Moriai M. Kanda December 2005 ASCII 15980 8 cipher block chaining mode initialization vector iv esp encapsulating security payload ip security

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicit Initialization Vector, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

draft-kato-ipsec-ciph-camellia-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4312 10.17487/RFC4312
RFC4313 Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources D. Oran December 2005 ASCII 46875 20 speech processing audio streams si speaker identification sv speaker verification tts text to speech

This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and Real Time Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. This memo provides information for the Internet community.

draft-ietf-speechsc-reqts-07 INFORMATIONAL INFORMATIONAL IETF rai speechsc 10.17487/RFC4313
RFC4314 IMAP4 Access Control List (ACL) Extension A. Melnikov December 2005 ASCII 56599 27 IMAP4-ACL Control List interet message access protocol

The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.

This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. [STANDARDS-TRACK]

draft-ietf-imapext-2086upd-08 RFC2086 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=4314 10.17487/RFC4314
RFC4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension M. Crispin December 2005 ASCII 16629 8 IMAP4UIDPL internet message access protocol disconnected operation

The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. [STANDARDS-TRACK]

draft-crispin-imap-rfc2359bis-04 RFC2359 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4315
RFC4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties J. Reschke December 2005 ASCII 20352 11 datatying propfind

This specification extends the Web Distributed Authoring and Versioning Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information. This memo defines an Experimental Protocol for the Internet community.

draft-reschke-webdav-property-datatypes-09 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4316
RFC4317 Session Description Protocol (SDP) Offer/Answer Examples A. Johnston R. Sparks December 2005 ASCII 32262 24

This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. This memo provides information for the Internet community.

draft-ietf-mmusic-offer-answer-examples-06 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4317
RFC4318 Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol D. Levi D. Harrington December 2005 ASCII 28124 14 management information base simple network management protocol transparent bridging rstp-mib

This memo defines an SMIv2 MIB module for managing the Rapid Spanning Tree capability defined by the IEEE P802.1t and P802.1w amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. [STANDARDS-TRACK]

draft-ietf-bridge-rstpmib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC4318
RFC4319 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines C. Sikes B. Ray R. Abbi December 2005 ASCII 146995 75 mib management information base hdsl2-shdsl-line-mib interfaces

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276). This document obsoletes RFC 3276. [STANDARDS-TRACK]

draft-ietf-adslmib-gshdslbis-11 RFC3276 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=4319 10.17487/RFC4319
RFC4320 Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction R. Sparks January 2006 ASCII 13853 7

This document describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding. These changes update behavior defined in RFC 3261. [STANDARDS-TRACK]

draft-sparks-sip-nit-actions-03 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4320
RFC4321 Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction R. Sparks January 2006 ASCII 22708 10

This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction. This memo provides information for the Internet community.

draft-sparks-sip-nit-problems-02 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC4321
RFC4322 Opportunistic Encryption using the Internet Key Exchange (IKE) M. Richardson D.H. Redelmeier December 2005 ASCII 95453 44 oe linux frees/wan ipsec dns domain name space dns security

This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.

As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. This memo provides information for the Internet community.

draft-richardson-ipsec-opportunistic-17 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4322 10.17487/RFC4322
RFC4323 Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB) M. Patrick W. Murwin January 2006 ASCII 197285 89 snmp simple network management protocol cm cable modem cmts cable modem termination system docs-ietf-qos-mib

This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0. [STANDARDS-TRACK]

draft-ietf-ipcdn-qos-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4323
RFC4324 Calendar Access Protocol (CAP) D. Royer G. Babics S. Mansour December 2005 ASCII 254638 131 calendar user cu calendar user agent cua ical calender store cs

The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols. This memo defines an Experimental Protocol for the Internet community.

draft-royer-calsch-cap-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4324
RFC4325 Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension S. Santesson R. Housley December 2005 ASCII 14449 7 issuer certificate

This document updates RFC 3280 by defining the Authority Information Access Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates. [STANDARDS-TRACK]

draft-ietf-pkix-crlaia-03 RFC5280 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4325
RFC4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS) G. Fairhurst B. Collini-Nocker December 2005 ASCII 95422 42

The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.

This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. [STANDARDS-TRACK]

draft-ietf-ipdvb-ule-06 RFC7280 PROPOSED STANDARD PROPOSED STANDARD IETF int ipdvb http://www.rfc-editor.org/errata_search.php?rfc=4326 10.17487/RFC4326
RFC4327 Link Management Protocol (LMP) Management Information Base (MIB) M. Dubuc T. Nadeau J. Lang E. McGinnis January 2006 ASCII 150509 82 lmp-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]

draft-ietf-ccamp-lmp-mib-10 RFC4631 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4327 10.17487/RFC4327
RFC4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control D. Papadimitriou Editor January 2006 ASCII 52145 23 otn optical transport networks pre-otn

This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-g709-09 RFC3471 RFC7139 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4328
RFC4329 Scripting Media Types B. Hoehrmann April 2006 ASCII 30230 15 JavaScript EMACScript mime script subtype

This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This memo provides information for the Internet community.

draft-hoehrmann-script-types-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4329
RFC4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI D. Mills January 2006 ASCII 67930 27 NTP time computer clock synchronization

This memorandum describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based on RFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.

This memorandum obsoletes RFC 1769, which describes SNTP Version 3 (SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) and SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation of SNTP. This memo provides information for the Internet community.

draft-mills-sntp-v4-01 RFC2030 RFC1769 RFC5905 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4330 10.17487/RFC4330
RFC4331 Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections B. Korver L. Dusseault February 2006 ASCII 19706 10 webdav

Web Distributed Authoring and Versioning (WebDAV) servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories. [STANDARDS-TRACK]

draft-ietf-webdav-quota-07 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav 10.17487/RFC4331
RFC4332 Cisco's Mobile IPv4 Host Configuration Extensions K. Leung A. Patel G. Tsirtsis E. Klovning December 2005 ASCII 19788 11 dynamic host configuration protocol dhcp point-to-point ip control protocol ppp ipcp

An IP device requires basic host configuration to be able to communicate. For example, it will typically require an IP address and the address of a DNS server. This information is configured statically or obtained dynamically using Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol/IP Control Protocol (PPP/IPCP). However, both DHCP and PPP/IPCP provide host configuration based on the access network. In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network. The information to configure the host needs to be based on the home network. This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages. This memo provides information for the Internet community.

draft-leung-cisco-mip4-host-config-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4332
RFC4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process G. Huston Editor B. Wijnen Editor December 2005 ASCII 15396 9 iad iasa ietf administrative support activity ietf administrative director

This memo outlines the guidelines for selection of members of the IETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-iesg-iaoc-selection-03 BCP0113 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC4333
RFC4334 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) R. Housley T. Moore February 2006 ASCII 20739 11 eap extensible authentication protocol wireless lan wlan system service identifier ssid

This document defines two Extensible Authentication Protocol (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770. [STANDARDS-TRACK]

draft-ietf-pkix-rfc3770bis-03 RFC3770 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4334 10.17487/RFC4334
RFC4335 The Secure Shell (SSH) Session Channel Break Extension J. Galbraith P. Remaker January 2006 ASCII 11370 6

The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. [STANDARDS-TRACK]

draft-ietf-secsh-break-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4335 10.17487/RFC4335
RFC4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP) S. Floyd M. Handley E. Kohler March 2006 ASCII 53585 22

This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games. This memo provides information for the Internet community.

draft-ietf-dccp-problem-03 INFORMATIONAL INFORMATIONAL IETF tsv dccp 10.17487/RFC4336
RFC4337 MIME Type Registration for MPEG-4 Y Lim D. Singer March 2006 ASCII 17290 11

This document defines the standard MIME types associated with MP4 files. It also recommends use of registered MIME types according to the type of contents. [STANDARDS-TRACK]

draft-lim-mpeg4-mime-03 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4337 10.17487/RFC4337
RFC4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel C. DeSanti C. Carlson R. Nixon January 2006 ASCII 75541 33 link local address link-local address

This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks.

This document obsoletes RFC 2625 and RFC 3831. [STANDARDS-TRACK]

draft-ietf-imss-ip-over-fibre-channel-03 RFC3831 RFC2625 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4338
RFC4339 IPv6 Host Configuration of DNS Server Information Approaches J. Jeong Editor February 2006 ASCII 60803 26 domain name server internet protocol address configuration dhcpv6 dynamic host configuration protocol

This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution. This memo provides information for the Internet community.

draft-ietf-dnsop-ipv6-dns-configuration-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=4339 10.17487/RFC4339
RFC4340 Datagram Congestion Control Protocol (DCCP) E. Kohler M. Handley S. Floyd March 2006 ASCII 318830 129 transport protocol

The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK]

draft-ietf-dccp-spec-11 RFC5595 RFC5596 RFC6335 RFC6773 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4340 10.17487/RFC4340
RFC4341 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control S. Floyd E. Kohler March 2006 ASCII 47868 20 transport protocol amid additive increase multiplicative decrease

This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. [STANDARDS-TRACK]

draft-ietf-dccp-ccid2-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC4341
RFC4342 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) S. Floyd E. Kohler J. Padhye March 2006 ASCII 83054 33 transport protocol ecn explicit congestion notification ccid3

This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. [STANDARDS-TRACK]

draft-ietf-dccp-ccid3-11 RFC5348 RFC6323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4342 10.17487/RFC4342
RFC4343 Domain Name System (DNS) Case Insensitivity Clarification D. Eastlake 3rd January 2006 ASCII 22899 10

Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]

draft-ietf-dnsext-insensitive-06 RFC1034 RFC1035 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4343 10.17487/RFC4343
RFC4344 The Secure Shell (SSH) Transport Layer Encryption Modes M. Bellare T. Kohno C. Namprempre January 2006 ASCII 27521 12 rekey

Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks.

This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. [STANDARDS-TRACK]

draft-ietf-secsh-newmodes-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4344
RFC4345 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol B. Harris January 2006 ASCII 8967 5 arcfour cipher key scheduling algorithm

This document specifies methods of using the Arcfour cipher in the Secure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm. [STANDARDS-TRACK]

draft-harris-ssh-arcfour-fixes-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4345 10.17487/RFC4345
RFC4346 The Transport Layer Security (TLS) Protocol Version 1.1 T. Dierks E. Rescorla April 2006 ASCII 187041 87

This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

draft-ietf-tls-rfc2246-bis-13 RFC2246 RFC5246 RFC4366 RFC4680 RFC4681 RFC5746 RFC6176 RFC7465 RFC7507 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4346 10.17487/RFC4346
RFC4347 Datagram Transport Layer Security E. Rescorla N. Modadugu April 2006 ASCII 56014 25 dtls

This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. [STANDARDS-TRACK]

draft-rescorla-dtls-05 RFC6347 RFC5746 RFC7507 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4347 10.17487/RFC4347
RFC4348 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec S. Ahmadi January 2006 ASCII 73528 32 speech codec variable-rate multicode wideband speech codec

This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.

VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. [STANDARDS-TRACK]

draft-ietf-avt-rtp-vmr-wb-11 RFC4424 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4348
RFC4349 High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) C. Pignataro M. Townsley February 2006 ASCII 22888 11 pseudowire

The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel High-Level Data Link Control (HDLC) frames over L2TPv3. [STANDARDS-TRACK]

draft-ietf-l2tpext-pwe3-hdlc-07 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4349
RFC4350 A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government F. Hendrikx C. Wallis February 2006 ASCII 21111 11 nid namespace identification

This document describes a Uniform Resource Name (URN) Namespace Identification (NID)convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New Zealand Government. This memo provides information for the Internet community.

draft-hendrikx-wallis-urn-nzl-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4350
RFC4351 Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream G. Hellstrom P. Jones January 2006 ASCII 44405 20 itu-t recommendation t.140

This memo describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting audio and text data within a single RTP session.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This memo defines a Historic Document for the Internet community.

draft-ietf-avt-audio-t140c-00 HISTORIC HISTORIC IETF rai avt 10.17487/RFC4351
RFC4352 RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec J. Sjoberg M. Westerlund A. Lakaniemi S. Wenger January 2006 ASCII 91297 38 real-time transport protocol audio signals

This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech. A media type registration for AMR-WB+ is included in this specification. [STANDARDS-TRACK]

draft-ietf-avt-rtp-amrwbplus-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4352 10.17487/RFC4352
RFC4353 A Framework for Conferencing with the Session Initiation Protocol (SIP) J. Rosenberg February 2006 ASCII 67405 29

The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. This memo provides information for the Internet community.

draft-ietf-sipping-conferencing-framework-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4353
RFC4354 A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service M. Garcia-Martin January 2006 ASCII 46847 21 oma open mobile alliance

The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet. This memo provides information for the Internet community.

draft-garcia-sipping-poc-isb-am-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4354
RFC4355 IANA Registration for Enumservices email, fax, mms, ems, and sms R. Brandner L. Conroy R. Stastny January 2006 ASCII 30218 16 domain name system

This document registers the Enumservices "email", "fax", "sms", "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761. [STANDARDS-TRACK]

draft-ietf-enum-msg-05 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4355
RFC4356 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail R. Gellens January 2006 ASCII 69427 31 cellular telephone x-mms

The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.

One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.

This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers. [STANDARDS-TRACK]

draft-ietf-lemonade-mms-mapping-06 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC4356
RFC4357 Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms V. Popov I. Kurepkin S. Leontiev January 2006 ASCII 114564 51 cpalgs public-key one-way hash block cipher encyption decryption mac hmac prf wrap unwrap ukm kek key parameter derivation digest cbc counter mode digital signature

This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in Internet applications. This memo provides information for the Internet community.

draft-popov-cryptopro-cpalgs-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4357 10.17487/RFC4357
RFC4358 A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA) D. Smith January 2006 ASCII 11562 6 nid namespace identifier omna open mobile naming authority

This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the Open Mobile Alliance (OMA). OMA defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA). This memo provides information for the Internet community.

draft-smith-oma-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4358
RFC4359 The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) B. Weis January 2006 ASCII 26989 12 ip encapsulating security payload digital signature

This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. [STANDARDS-TRACK]

draft-ietf-msec-ipsec-signatures-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4359
RFC4360 BGP Extended Communities Attribute S. Sangli D. Tappan Y. Rekhter February 2006 ASCII 24145 12

This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]

draft-ietf-idr-bgp-ext-communities-09 RFC7153 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4360 10.17487/RFC4360
RFC4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) T. Lemon B. Sommerfeld February 2006 ASCII 28009 12 dhcpv6

This document specifies the format that is to be used for encoding Dynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers. [STANDARDS-TRACK]

draft-ietf-dhc-3315id-for-v4-05 RFC2131 RFC2132 RFC3315 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4361 10.17487/RFC4361
RFC4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP L-E. Jonsson G. Pelletier K. Sandlund January 2006 ASCII 53926 23 internet protocol user datagram protocol real-time transport protocol

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format. This document is a replacement for RFC 3242, which it obsoletes. [STANDARDS-TRACK]

draft-ietf-rohc-rfc3242bis-01 RFC3242 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4362
RFC4363 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions D. Levi D. Harrington January 2006 ASCII 188981 99 mib management information base mac bridges traffic classes enhanced multicast filtering p-bridge-mib q-bridge-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001 (TM). The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v (TM).

Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.

This memo supplements RFC 4188 and obsoletes RFC 2674. [STANDARDS-TRACK]

draft-ietf-bridge-ext-v2-07 RFC2674 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge http://www.rfc-editor.org/errata_search.php?rfc=4363 10.17487/RFC4363
RFC4364 BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen Y. Rekhter February 2006 ASCII 116446 47 service provider ip backbone ce router pe router border gateway protocol multiprotocol label switching architecture virtual private networks

This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]

draft-ietf-l3vpn-rfc2547bis-03 RFC2547 RFC4577 RFC4684 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4364 10.17487/RFC4364
RFC4365 Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen February 2006 ASCII 77924 32

This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section. This memo provides information for the Internet community.

draft-ietf-l3vpn-as2547-07 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4365 10.17487/RFC4365
RFC4366 Transport Layer Security (TLS) Extensions S. Blake-Wilson M. Nystrom D. Hopwood J. Mikkelsen T. Wright April 2006 ASCII 66344 30 transport protocol layer authentication privacy

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.

The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]

draft-ietf-tls-rfc3546bis-02 RFC3546 RFC5246 RFC6066 RFC4346 RFC5746 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4366 10.17487/RFC4366
RFC4367 What's in a Name: False Assumptions about DNS Names J. Rosenberg Editor IAB February 2006 ASCII 41724 17 domain name system

The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform Resource Identifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided. This memo provides information for the Internet community.

draft-iab-dns-assumptions-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4367 10.17487/RFC4367
RFC4368 Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition T. Nadeau S. Hegde January 2006 ASCII 43315 22 management information base mpls-lc-atm-std-mib mpls-lc-fr-std-mib

This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. [STANDARDS-TRACK]

draft-ietf-mpls-lc-if-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4368 10.17487/RFC4368
RFC4369 Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP) K. Gibbons C. Monia J. Tseng F. Travostino January 2006 ASCII 59354 29 mib management information base snmp simple network management protocol ifcp gateway ifcp-mgmt-mib

The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. [STANDARDS-TRACK]

draft-ietf-ips-ifcp-mib-07 RFC6173 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4369
RFC4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control R. Weltman February 2006 ASCII 10624 5 proxy authorization control

This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection. [STANDARDS-TRACK]

draft-weltman-ldapv3-proxy-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4370
RFC4371 BCP 101 Update for IPR Trust B. Carpenter Editor L. Lynch Editor January 2006 ASCII 6901 4

This document updates BCP 101 to take account of the new IETF Intellectual Property Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-carpenter-bcp101-update-03 RFC4071 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4371
RFC4372 Chargeable User Identity F. Adrangi A. Lior J. Korhonen J. Loughney January 2006 ASCII 21555 10 radius remote authentication dial-in user service roaming transaction home network

This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS-TRACK]

draft-ietf-radext-chargeable-user-id-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4372
RFC4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) R. Harrison J. Sermersheim Y. Dong January 2006 ASCII 31091 16

The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.

The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. This memo provides information for the Internet community.

draft-rharrison-lburp-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4373
RFC4374 The application/xv+xml Media Type G. McCobb January 2006 ASCII 10308 6 mime sub-type media descriptor xhtml+voice

This document describes the registration of the MIME sub-type application/xv+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. This memo provides information for the Internet community.

draft-mccobb-xv-media-type-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4374
RFC4375 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain K. Carlberg January 2006 ASCII 17037 8 resource transit domain stub domain

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.

draft-ietf-ieprep-domain-req-05 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC4375
RFC4376 Requirements for Floor Control Protocols P. Koskelainen J. Ott H. Schulzrinne X. Wu February 2006 ASCII 30021 14 shared resources multiparty conferences

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework. This memo provides information for the Internet community.

draft-ietf-xcon-floor-control-req-03 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC4376
RFC4377 Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks T. Nadeau M. Morrow G. Swallow D. Allan S. Matsushima February 2006 ASCII 31889 15

This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks. This memo provides information for the Internet community.

draft-ietf-mpls-oam-requirements-07 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4377 10.17487/RFC4377
RFC4378 A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) D. Allan Editor T. Nadeau Editor February 2006 ASCII 23640 11 data plane fcaps

This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching (MPLS). The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. This memo provides information for the Internet community.

draft-ietf-mpls-oam-frmwk-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4378
RFC4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures K. Kompella G. Swallow February 2006 ASCII 116872 50 data plane

This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. [STANDARDS-TRACK]

draft-ietf-mpls-lsp-ping-13 RFC1122 RFC5462 RFC6424 RFC6425 RFC6426 RFC6829 RFC7506 RFC7537 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4379 10.17487/RFC4379
RFC4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) C. Huitema February 2006 ASCII 132607 53

We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". [STANDARDS-TRACK]

draft-huitema-v6ops-teredo-05 RFC5991 RFC6081 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4380 10.17487/RFC4380
RFC4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) M. Behringer February 2006 ASCII 55200 22 service provider atm asynchronous transfer mode frame relay

This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.

The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for the Internet community.

draft-behringer-mpls-security-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4381
RFC4382 MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base T. Nadeau Editor H. van der Linde Editor February 2006 ASCII 85594 44 mib management information base multiprotocol label switching label switching router lsr mpls-l3vpn-std-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual Private Networks on a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. [STANDARDS-TRACK]

draft-ietf-l3vpn-mpls-vpn-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4382 10.17487/RFC4382
RFC4383 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP) M. Baugher E. Carrara February 2006 ASCII 41766 19 multicast data stream broadcast data stream

This memo describes the use of the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. [STANDARDS-TRACK]

draft-ietf-msec-srtp-tesla-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4383
RFC4384 BGP Communities for Data Collection D. Meyer February 2006 ASCII 26078 12 border gateway protocol

BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grow-collection-communities-06 BCP0114 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=4384 10.17487/RFC4384
RFC4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN S. Bryant G. Swallow L. Martini D. McPherson February 2006 ASCII 22440 12 multiprotocol label switching packet switched network pseudowire associated channel header

This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header. The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. [STANDARDS-TRACK]

draft-ietf-pwe3-cw-06 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4385 10.17487/RFC4385
RFC4386 Internet X.509 Public Key Infrastructure Repository Locator Service S. Boeyen P. Hallam-Baker February 2006 ASCII 11330 6 pki public key infrastructure dns srv

This document defines a Public Key Infrastructure (PKI) repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate-using systems to locate PKI repositories.This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pkix-pkixrep-04 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC4386
RFC4387 Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP P. Gutmann Editor February 2006 ASCII 63182 25 pki hypertext transfer protocol

The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. [STANDARDS-TRACK]

draft-ietf-pkix-certstore-http-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4387
RFC4388 Dynamic Host Configuration Protocol (DHCP) Leasequery R. Woundy K. Kinnear February 2006 ASCII 63914 27 dhcpv4 ip address

A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients. Other processes and devices that already make use of DHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information. [STANDARDS-TRACK]

draft-ietf-dhc-leasequery-09 RFC6148 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4388 10.17487/RFC4388
RFC4389 Neighbor Discovery Proxies (ND Proxy) D. Thaler M. Talwar C. Patel April 2006 ASCII 38124 18 ndproxy

Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipv6-ndproxy-04 EXPERIMENTAL EXPERIMENTAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4389 10.17487/RFC4389
RFC4390 Dynamic Host Configuration Protocol (DHCP) over InfiniBand V. Kashyap April 2006 ASCII 10754 6 bootstrap boot ipoib

IP over Infiniband (IPoIB) link-layer address is 20 octets long. This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol (DHCP/BOOTP) message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. [STANDARDS-TRACK]

draft-ietf-ipoib-dhcp-over-infiniband-10 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4390
RFC4391 Transmission of IP over InfiniBand (IPoIB) J. Chu V. Kashyap April 2006 ASCII 45858 21 address resolution protocol arp ib

This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets. The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links. [STANDARDS-TRACK]

draft-ietf-ipoib-ip-over-infiniband-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4391
RFC4392 IP over InfiniBand (IPoIB) Architecture V. Kashyap April 2006 ASCII 53506 23 ib ipv4 ipv6

InfiniBand is a high-speed, channel-based interconnect between systems and devices.

This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. This memo provides information for the Internet community.

draft-ietf-ipoib-architecture-04 INFORMATIONAL INFORMATIONAL IETF int ipoib 10.17487/RFC4392
RFC4393 MIME Type Registrations for 3GPP2 Multimedia Files H. Garudadri March 2006 ASCII 14369 7 third-generation partnership project 2

This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

draft-garudadri-avt-3gpp2-mime-02 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4393
RFC4394 A Transport Network View of the Link Management Protocol (LMP) D. Fedyk O. Aboul-Magd D. Brungard J. Lang D. Papadimitriou February 2006 ASCII 40812 18 gmpls ason discovery sdh otn sonet pdh

The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. This memo provides information for the Internet community.

draft-ietf-ccamp-transport-lmp-02 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4394
RFC4395 Guidelines and Registration Procedures for New URI Schemes T. Hansen T. Hardie L. Masinter February 2006 ASCII 31933 15 uniform resource identifier syntax semantics

This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hansen-2717bis-2718bis-uri-guidelines-06 RFC2717 RFC2718 RFC7595 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4395 10.17487/RFC4395
RFC4396 RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text J. Rey Y. Matsui February 2006 ASCII 155421 66 3GPP 3GPP timed text streaming real-time streaming titling decorated text scrolling text karaoke hyperlinked text highlighted text blinking text highlight color text delay text style text box text wrap text sample sample descriptions modifier boxes UTF-8 UTF-16

This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file. Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations. In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified. [STANDARDS-TRACK]

draft-ietf-avt-rtp-3gpp-timed-text-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4396 10.17487/RFC4396
RFC4397 A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture I. Bryskin A. Farrel February 2006 ASCII 40331 19

Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON).

This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture.

It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-ason-lexicography-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4397 10.17487/RFC4397
RFC4398 Storing Certificates in the Domain Name System (DNS) S. Josefsson March 2006 ASCII 35652 17 SC-DNS cryptology authenticity

Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]

draft-ietf-dnsext-rfc2538bis-09 RFC2538 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4398 10.17487/RFC4398
RFC4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) N. Williams February 2006 ASCII 15272 8 secure session layer message integrity check mic

This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Program Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that do not or cannot use GSS-API per-message message integrity check (MIC) and wrap tokens for session protection. [STANDARDS-TRACK]

draft-ietf-kitten-gssapi-prf-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC4401
RFC4402 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism N. Williams February 2006 ASCII 9549 5

This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. [STANDARDS-TRACK]

draft-ietf-kitten-krb5-gssapi-prf-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten http://www.rfc-editor.org/errata_search.php?rfc=4402 10.17487/RFC4402
RFC4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3) B. Bergeson K. Boogert V. Nanjundaswamy February 2006 ASCII 78747 42 LDAPv3

This document defines the Lightweight Directory Access Protocol (LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory. This memo provides information for the Internet community.

draft-bergeson-uddi-ldap-schema-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4403
RFC4404 Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP) R. Natarajan A. Rijhsinghani February 2006 ASCII 60475 33 mib management information base fcip-mgmt-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Fibre Channel Over TCP/IP (FCIP) entities, which are used to interconnect Fibre Channel (FC) fabrics with IP networks. [STANDARDS-TRACK]

draft-ietf-ips-fcip-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4404 10.17487/RFC4404
RFC4405 SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message E. Allman H. Katz April 2006 ASCII 29429 14 spam spoofing phishing

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. This memo defines an Experimental Protocol for the Internet community.

draft-katz-submitter-01 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4405
RFC4406 Sender ID: Authenticating E-Mail J. Lyon M. Wong April 2006 ASCII 40428 19 simple mail transfer protocol spam spoofing

Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address. This memo defines an Experimental Protocol for the Internet community.

draft-lyon-senderid-core-01 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4406
RFC4407 Purported Responsible Address in E-Mail Messages J. Lyon April 2006 ASCII 14387 7 pra purported responsible address

This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).This memo defines an Experimental Protocol for the Internet community.

draft-lyon-senderid-pra-01 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4407 10.17487/RFC4407
RFC4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 M. Wong W. Schlitt April 2006 ASCII 105009 48 spoofing spf

E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. This memo defines an Experimental Protocol for the Internet community.

draft-schlitt-spf-classic-02 RFC7208 RFC6652 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4408 10.17487/RFC4408
RFC4409 Message Submission for Mail R. Gellens J. Klensin April 2006 ASCII 34911 17 smtp simle mail transfer protocol ua user agent

This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.

Message relay and final delivery are unaffected, and continue to use SMTP over port 25.

When conforming to this document, message submission uses the protocol specified here, normally over port 587.

This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]

draft-gellens-submit-bis-02 RFC2476 RFC6409 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4409 10.17487/RFC4409
RFC4410 Selectively Reliable Multicast Protocol (SRMP) M. Pullen F. Zhao D. Cohen February 2006 ASCII 65877 30 transport best-effort srt selectively reliable transport

The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best-effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and a Selectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application. This memo defines an Experimental Protocol for the Internet community.

draft-pullen-srmp-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4410 10.17487/RFC4410
RFC4411 Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events J. Polk February 2006 ASCII 49260 22 Resource-Priority preempt preempted Q.850 preconditions

This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. [STANDARDS-TRACK]

draft-ietf-sipping-reason-header-for-preemption-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC4411
RFC4412 Communications Resource Priority for the Session Initiation Protocol (SIP) H. Schulzrinne J. Polk February 2006 ASCII 79193 36 RP RPH preferential preempt preempted preemption queue DSN DRSN WPS ETS Q.735 Q735 disaster I.255 flash flash-override

This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. [STANDARDS-TRACK]

draft-ietf-sip-resource-priority-10 RFC7134 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4412
RFC4413 TCP/IP Field Behavior M. West S. McCann March 2006 ASCII 28435 44 transmission control protocol header compression

This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers. This memo provides information for the Internet community.

draft-ietf-rohc-tcp-field-behavior-04 INFORMATIONAL INFORMATIONAL IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4413 10.17487/RFC4413
RFC4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS) A. Newton February 2006 ASCII 89985 51

This document describes an Internet Registry Information Service (IRIS) registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. [STANDARDS-TRACK]

draft-ietf-enum-iris-ereg-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4414
RFC4415 IANA Registration for Enumservice Voice R. Brandner L. Conroy R. Stastny February 2006 ASCII 15956 8 uniform resource identifier uri voice call audio call

This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call. [STANDARDS-TRACK]

draft-ietf-enum-voice-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4415
RFC4416 Goals for Internet Messaging to Support Diverse Service Environments J. Wong Editor February 2006 ASCII 93676 43 IMAP protocol extensions messaging wireless handheld telephone user interface multi-modal LEMONADE extension principles history background motivation cellular interworking constraints TUI WUI client MMS

This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.

The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.

The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.

The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. This memo provides information for the Internet community.

draft-ietf-lemonade-goals-05 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC4416
RFC4417 Report of the 2004 IAB Messaging Workshop P. Resnick Editor P. Saint-Andre Editor February 2006 ASCII 47201 20 internet architecture board internet messaging

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA. The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB. This memo provides information for the Internet community.

draft-iab-messaging-report-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4417
RFC4418 UMAC: Message Authentication Code using Universal Hashing T. Krovetz Editor March 2006 ASCII 51304 27

This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines.

To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material. This memo provides information for the Internet community.

draft-krovetz-umac-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4418 10.17487/RFC4418
RFC4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol M. Friedl N. Provos W. Simpson March 2006 ASCII 18356 10

This memo describes a new key exchange method for the Secure Shell (SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time. [STANDARDS-TRACK]

draft-ietf-secsh-dh-group-exchange-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4419
RFC4420 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) A. Farrel Editor D. Papadimitriou J.-P. Vasseur A. Ayyangar February 2006 ASCII 47235 21 SESSION_ATTRIBUTE

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. [STANDARDS-TRACK]

draft-ietf-mpls-rsvpte-attributes-05 RFC5420 RFC3209 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4420
RFC4421 RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes C. Perkins February 2006 ASCII 8000 4 realtime transport protocol video stream

The RFC Payload Format for Uncompressed Video, RFC 4175, defines a scheme to packetise uncompressed, studio-quality, video streams for transport using RTP. This memo extends the format to support additional colour sampling modes. [STANDARDS-TRACK]

draft-ietf-avt-uncomp-video-ext-01 RFC4175 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4421
RFC4422 Simple Authentication and Security Layer (SASL) A. Melnikov Editor K. Zeilenga Editor June 2006 ASCII 73206 33 SASL encryption protocol specific

The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.

This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.

This document obsoletes RFC 2222. [STANDARDS-TRACK]

draft-ietf-sasl-rfc2222bis-15 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl 10.17487/RFC4422
RFC4423 Host Identity Protocol (HIP) Architecture R. Moskowitz P. Nikander May 2006 ASCII 61049 24

This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding. This memo provides information for the Internet community.

draft-ietf-hip-arch-03 INFORMATIONAL INFORMATIONAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=4423 10.17487/RFC4423
RFC4424 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec S. Ahmadi February 2006 ASCII 16331 8 speech codec variable-rate multicode wideband speech codec

This document is an addendum to RFC 4348, which specifies the RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document specifies some updates in RFC 4348 to enable support for the new operating mode of VMR-WB standard (i.e., VMR-WB mode 4). These updates do not affect the existing modes of VMR-WB already specified in RFC 4348.

The payload formats and their associated parameters, as well as all provisions, restrictions, use cases, features, etc., that are specified in RFC 4348 are applicable to the new operating mode with no exception. [STANDARDS-TRACK]

draft-ietf-avt-rtp-vmr-wb-extension-02 RFC4348 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4424
RFC4425 RTP Payload Format for Video Codec 1 (VC-1) A. Klemets February 2006 ASCII 84335 36 smpte 421m wmv wmv9 vc-9

This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television. [STANDARDS-TRACK]

draft-ietf-avt-rtp-vc1-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4425 10.17487/RFC4425
RFC4426 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification J. Lang Editor B. Rajagopalan Editor D. Papadimitriou Editor March 2006 ASCII 55820 23

This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-recovery-functional-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4426
RFC4427 Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) E. Mannie Editor D. Papadimitriou Editor March 2006 ASCII 43842 22

This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-recovery-terminology-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4427 10.17487/RFC4427
RFC4428 Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) D. Papadimitriou Editor E. Mannie Editor March 2006 ASCII 118749 47

This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-recovery-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4428 10.17487/RFC4428
RFC4429 Optimistic Duplicate Address Detection (DAD) for IPv6 N. Moore April 2006 ASCII 33123 17 internet protocol version 6 stateless address autoconfiguration neighbor discovery

Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK]

draft-ietf-ipv6-optimistic-dad-07 RFC7527 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4429 10.17487/RFC4429
RFC4430 Kerberized Internet Negotiation of Keys (KINK) S. Sakane K. Kamada M. Thomas J. Vilhuber March 2006 ASCII 91261 40 ike internet key exchange

This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. [STANDARDS-TRACK]

draft-ietf-kink-kink-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec kink http://www.rfc-editor.org/errata_search.php?rfc=4430 10.17487/RFC4430
RFC4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record M. Andrews S. Weiler February 2006 ASCII 7861 4 dns domain name space

This document defines a new DNS resource record, called the DNSSEC Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain. This memo provides information for the Internet community.

draft-andrews-dlv-dns-rr-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4431
RFC4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol B. Harris March 2006 ASCII 16077 8 rivest-sharmir-adleman public key encryption

This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. [STANDARDS-TRACK]

draft-harris-ssh-rsa-kex-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4432
RFC4433 Mobile IPv4 Dynamic Home Agent (HA) Assignment M. Kulkarni A. Patel K. Leung March 2006 ASCII 55636 25 internet protocol messaging

Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. [STANDARDS-TRACK]

draft-ietf-mip4-dynamic-assignment-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4433 10.17487/RFC4433
RFC4434 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) P. Hoffman February 2006 ASCII 9384 6 security ipsec advanced encryption standard mac message authentication code

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128. [STANDARDS-TRACK]

draft-hoffman-rfc3664bis-05 RFC3664 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4434
RFC4435 A Framework for the Usage of Internet Media Guides (IMGs) Y. Nomura R. Walsh J-P. Luoma H. Asaeda H. Schulzrinne April 2006 ASCII 51687 22 session description protocol sdp sdpng

This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure. This memo provides information for the Internet community.

draft-ietf-mmusic-img-framework-09 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4435
RFC4436 Detecting Network Attachment in IPv4 (DNAv4) B. Aboba J. Carlson S. Cheshire March 2006 ASCII 35991 15 internet protocol

The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment. [STANDARDS-TRACK]

draft-ietf-dhc-dna-ipv4-18 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4436 10.17487/RFC4436
RFC4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources J. Whitehead G. Clemm J. Reschke Editor March 2006 ASCII 49932 25 http hyper text transfer protocol

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-webdav-redirectref-protocol-13 EXPERIMENTAL EXPERIMENTAL IETF app webdav 10.17487/RFC4437
RFC4438 Fibre-Channel Name Server MIB C. DeSanti V. Gaonkar H.K. Vivek K. McCloghrie S. Gai April 2006 ASCII 70156 36 management information base T11-fc-name-server-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Name Server function of a Fibre Channel network. The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. [STANDARDS-TRACK]

draft-ietf-imss-fc-nsm-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4438 10.17487/RFC4438
RFC4439 Fibre Channel Fabric Address Manager MIB C. DeSanti V. Gaonkar K. McCloghrie S. Gai March 2006 ASCII 77153 40 management information base t11-tc-mib t11-fc-fabric-addr-mgr-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. [STANDARDS-TRACK]

draft-ietf-imss-fc-fam-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4439 10.17487/RFC4439
RFC4440 IAB Thoughts on the Role of the Internet Research Task Force (IRTF) S. Floyd Editor V. Paxson Editor A. Falk Editor IAB March 2006 ASCII 29063 13 internet architecture board

This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF. This memo provides information for the Internet community.

draft-iab-irtf-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4440
RFC4441 The IEEE 802/IETF Relationship B. Aboba Editor March 2006 ASCII 49624 22 snmp aaa simple network management protocol authentication authorization accounting

Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications. This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history. This memo provides information for the Internet community.

draft-iab-ieee-802-rel-05 RFC7241 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4441
RFC4442 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) S. Fries H. Tschofenig March 2006 ASCII 37345 18 authentication mikey multimedia internet keying protocol

TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.

This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast. [STANDARDS-TRACK]

draft-ietf-msec-bootstrapping-tesla-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4442
RFC4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification A. Conta S. Deering M. Gupta Editor March 2006 ASCII 48969 24

This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]

draft-ietf-ipngwg-icmp-v3-07 RFC2463 RFC2780 RFC4884 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4443 10.17487/RFC4443
RFC4444 Management Information Base for Intermediate System to Intermediate System (IS-IS) J. Parker Editor April 2006 ASCII 181968 103 mib routing protocol isis-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this document describes a MIB for the Intermediate System to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks. [STANDARDS-TRACK]

draft-ietf-isis-wg-mib-26 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=4444 10.17487/RFC4444
RFC4445 A Proposed Media Delivery Index (MDI) J. Welch J. Clark April 2006 ASCII 24171 10

This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media, MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media. This memo provides information for the Internet community.

draft-welch-mdi-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4445
RFC4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) L. Martini April 2006 ASCII 19782 9

This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in the Pseudo Wire Edge to Edge (PWE3) working group. Detailed IANA allocation instructions are also included in this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pwe3-iana-allocation-15 BCP0116 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4446 10.17487/RFC4446
RFC4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) L. Martini Editor E. Rosen N. El-Aawar T. Smith G. Heron April 2006 ASCII 76204 33 mpls multiprotocol label switching protocol pdu protocol data units

Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. [STANDARDS-TRACK]

draft-ietf-pwe3-control-protocol-17 RFC6723 RFC6870 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4447 10.17487/RFC4447
RFC4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks L. Martini Editor E. Rosen N. El-Aawar G. Heron April 2006 ASCII 49012 24 pw pseudowire pdu protocol data units

An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK]

draft-ietf-pwe3-ethernet-encap-11 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4448 10.17487/RFC4448
RFC4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key C. Perkins June 2006 ASCII 15080 7 mobile node correspondent node binding management key binding updates

A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. [STANDARDS-TRACK]

draft-ietf-mip6-precfgkbm-04 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4449 10.17487/RFC4449
RFC4450 Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents E. Lear H. Alvestrand March 2006 ASCII 23822 11

This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today. The results identify a set of documents that were marked as Proposed Standards that are now reclassified as Historic. This memo provides information for the Internet community.

draft-ietf-newtrk-decruft-experiment-03 INFORMATIONAL INFORMATIONAL IETF gen newtrk http://www.rfc-editor.org/errata_search.php?rfc=4450 10.17487/RFC4450
RFC4451 BGP MULTI_EXIT_DISC (MED) Considerations D. McPherson V. Gill March 2006 ASCII 28435 13 border gateway protocol

The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.

This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar. This memo provides information for the Internet community.

draft-ietf-grow-bgp-med-considerations-05 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC4451
RFC4452 The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces H. Van de Sompel T. Hammond E. Neylon S. Weibel April 2006 ASCII 36408 17 uniform resource identifier

This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces. Namespaces participating in the "info" URI scheme are regulated by an "info" Registry mechanism. This memo provides information for the Internet community.

draft-vandesompel-info-uri-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4452 10.17487/RFC4452
RFC4453 Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP) J. Rosenberg G. Camarillo Editor D. Willis April 2006 ASCII 16833 8 sip extensions

The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a set of requirements for extensions to SIP that add consent-based communications. This memo provides information for the Internet community.

draft-ietf-sipping-consent-reqs-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4453
RFC4454 Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) S. Singh M. Townsley C. Pignataro May 2006 ASCII 58281 26 extensible tunneling protocol

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks. This document describes the specifics of how to use the L2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over an IP network. [STANDARDS-TRACK]

draft-ietf-l2tpext-pwe3-atm-04 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4454
RFC4455 Definition of Managed Objects for Small Computer System Interface (SCSI) Entities M. Hallak-Stamler M. Bakke Y. Lederman M. Krueger K. McCloghrie April 2006 ASCII 178947 88 mib management information base scsi-mib

This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular, it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. [STANDARDS-TRACK]

draft-ietf-ips-scsi-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4455 10.17487/RFC4455
RFC4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) T. Bates E. Chen R. Chandra April 2006 ASCII 23209 12 BGP-RR Border Gateway Protocol autonomous system

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.

This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP).

This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK]

draft-ietf-idr-rfc2796bis-02 RFC2796 RFC1966 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4456 10.17487/RFC4456
RFC4457 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header) G. Camarillo G. Blanco April 2006 ASCII 15884 8 3gpp third generation partnership project 3rd generation partnership project ims ip multimedia subsystem

This document specifies the Session Initiation Protocol (SIP) P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. This memo provides information for the Internet community.

draft-camarillo-sipping-user-database-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4457
RFC4458 Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) C. Jennings F. Audet J. Elwell April 2006 ASCII 41378 21 universal resource identifiers

The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications. This memo provides information for the Internet community.

draft-jennings-sip-voicemail-uri-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4458 10.17487/RFC4458
RFC4459 MTU and Fragmentation Issues with In-the-Network Tunneling P. Savola April 2006 ASCII 32051 14

Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. This memo provides information for the Internet community.

draft-savola-mtufrag-network-tunneling-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4459
RFC4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues R. Stewart I. Arias-Rodriguez K. Poon A. Caro M. Tuexen April 2006 ASCII 215405 109 SCTP IP internet transport packet network

This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the delta, a description of the problem and the details of the solution are also provided. This memo provides information for the Internet community.

draft-ietf-tsvwg-sctpimpguide-16 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4460
RFC4461 Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) S. Yasukawa Editor April 2006 ASCII 64542 30 p2mp multiprotocol label switching

This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).

There is no intent to specify solution-specific details or application-specific requirements in this document.

The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. This memo provides information for the Internet community.

draft-ietf-mpls-p2mp-sig-requirement-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4461
RFC4462 Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol J. Hutzelman J. Salowey J. Galbraith V. Welch May 2006 ASCII 65280 29

The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.

This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.

This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. [STANDARDS-TRACK]

draft-ietf-secsh-gsskeyex-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4462 10.17487/RFC4462
RFC4463 A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks S. Shanmugham P. Monaco B. Eberman April 2006 ASCII 176385 86

This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area.

MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol). This memo provides information for the Internet community.

draft-shanmugham-mrcp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4463
RFC4464 Signaling Compression (SigComp) Users' Guide A. Surtees M. West May 2006 ASCII 79643 43

This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets. This memo provides information for the Internet community.

draft-ietf-rohc-sigcomp-user-guide-04 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4464
RFC4465 Signaling Compression (SigComp) Torture Tests A. Surtees M. West June 2006 ASCII 118772 68 SigComp Universal Decompressor Virtual Machine

This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. This memo provides information for the Internet community.

draft-ietf-rohc-sigcomp-torture-tests-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4465
RFC4466 Collected Extensions to IMAP4 ABNF A. Melnikov C. Daboo April 2006 ASCII 33752 17

Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.

This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions.

This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. [STANDARDS-TRACK]

draft-melnikov-imap-ext-abnf-08 RFC2088 RFC2342 RFC3501 RFC3502 RFC3516 RFC6237 RFC7377 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4466
RFC4467 Internet Message Access Protocol (IMAP) - URLAUTH Extension M. Crispin May 2006 ASCII 36714 18 imap url imapurl

This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.

An IMAP server that supports this extension indicates this with a capability name of "URLAUTH". [STANDARDS-TRACK]

draft-ietf-lemonade-urlauth-08 RFC5092 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC4467
RFC4468 Message Submission BURL Extension C. Newman May 2006 ASCII 28614 14 URLAUTH IMAP IMAPURL Forward-without-download mobile-client lemonade

The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. [STANDARDS-TRACK]

draft-ietf-lemonade-burl-04 RFC3463 RFC5248 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4468 10.17487/RFC4468
RFC4469 Internet Message Access Protocol (IMAP) CATENATE Extension P. Resnick April 2006 ASCII 21822 13 append

The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server. [STANDARDS-TRACK]

draft-ietf-lemonade-catenate-05 RFC3501 RFC3502 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4469 10.17487/RFC4469
RFC4470 Minimally Covering NSEC Records and DNSSEC On-line Signing S. Weiler J. Ihren April 2006 ASCII 17471 8 dns security domain name system

This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-online-signing-02 RFC4035 RFC4034 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4470 10.17487/RFC4470
RFC4471 Derivation of DNS Name Predecessor and Successor G. Sisson B. Laurie September 2006 ASCII 42430 23 domain namespace dynamic nsec dnssec

This document describes two methods for deriving the canonically-ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dnsext-dns-name-p-s-01 EXPERIMENTAL EXPERIMENTAL IETF int dnsext 10.17487/RFC4471
RFC4472 Operational Considerations and Issues with IPv6 DNS A. Durand J. Ihren P. Savola April 2006 ASCII 68882 29 domain name system internet protocol version 6

This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. This memo provides information for the Internet community.

draft-ietf-dnsop-ipv6-dns-issues-12 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4472
RFC4473 Requirements for Internet Media Guides (IMGs) Y. Nomura R. Walsh J-P. Luoma J. Ott H. Schulzrinne May 2006 ASCII 53864 23 media-on-deman multicast

This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery. This memo provides information for the Internet community.

draft-ietf-mmusic-img-req-08 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4473
RFC4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) J. Peterson C. Jennings August 2006 ASCII 104952 41 security identity identity-info

The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS-TRACK]

draft-ietf-sip-identity-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4474 10.17487/RFC4474
RFC4475 Session Initiation Protocol (SIP) Torture Test Messages R. Sparks Editor A. Hawrylyshen A. Johnston J. Rosenberg H. Schulzrinne May 2006 ASCII 93276 53

This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. This memo provides information for the Internet community.

draft-ietf-sipping-torture-tests-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4475
RFC4476 Attribute Certificate (AC) Policies Extension C. Francis D. Pinkas May 2006 ASCII 20229 11 acp attribute certificate policies

This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific ACPs. [STANDARDS-TRACK]

draft-ietf-pkix-acpolicies-extn-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4476
RFC4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues T. Chown S. Venaas C. Strauf May 2006 ASCII 30440 14 internet protocol

A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken. This memo provides information for the Internet community.

draft-ietf-dhc-dual-stack-04 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC4477
RFC4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol Y. Nir April 2006 ASCII 10714 5 lifetime

This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer. This document describes a mechanism to perform this function. This memo defines an Experimental Protocol for the Internet community.

draft-nir-ikev2-auth-lt-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4478
RFC4479 A Data Model for Presence J. Rosenberg July 2006 ASCII 88399 35 simple sip session initiation protocol

This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. [STANDARDS-TRACK]

draft-ietf-simple-presence-data-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4479 10.17487/RFC4479
RFC4480 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) H. Schulzrinne V. Gurbani P. Kyzivat J. Rosenberg July 2006 ASCII 74026 37

The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.

This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.

These extensions include presence information for persons, services (tuples), and devices. [STANDARDS-TRACK]

draft-ietf-simple-rpid-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4480 10.17487/RFC4480
RFC4481 Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals H. Schulzrinne July 2006 ASCII 15549 9

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past. [STANDARDS-TRACK]

draft-ietf-simple-future-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4481
RFC4482 CIPID: Contact Information for the Presence Information Data Format H. Schulzrinne July 2006 ASCII 22157 11 pidf

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. [STANDARDS-TRACK]

draft-ietf-simple-cipid-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4482
RFC4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages E. Burger Editor May 2006 ASCII 36794 17 universal resource locator mime external-body access-type

This document defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. [STANDARDS-TRACK]

draft-ietf-sip-content-indirect-mech-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4483 10.17487/RFC4483
RFC4484 Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP) J. Peterson J. Polk D. Sicker H. Tschofenig August 2006 ASCII 37169 15 policy decision

This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system. This memo provides information for the Internet community.

draft-ietf-sipping-trait-authz-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4484
RFC4485 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne May 2006 ASCII 57278 23 interactive communication

The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. This memo provides information for the Internet community.

draft-ietf-sip-guidelines-09 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC4485
RFC4486 Subcodes for BGP Cease Notification Message E. Chen V. Gillet April 2006 ASCII 10254 6 border gateway protocol bgp peers

This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. [STANDARDS-TRACK]

draft-ietf-idr-cease-subcode-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4486
RFC4487 Mobile IPv6 and Firewalls: Problem Statement F. Le S. Faccin B. Patil H. Tschofenig May 2006 ASCII 32022 16 3g mobile networks

This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks.

The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions. This memo provides information for the Internet community.

draft-ietf-mip6-firewalls-04 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4487
RFC4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription O. Levin May 2006 ASCII 17264 8

The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. [STANDARDS-TRACK]

draft-ietf-sip-refer-with-norefersub-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4488
RFC4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses J-S. Park M-K. Shin H-J. Kim April 2006 ASCII 12224 6 iid interface identifiers

This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate its unique multicast addresses automatically without conflicts. The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast-prefix-based IPv6 multicast addresses. This memo updates RFC 3306. [STANDARDS-TRACK]

draft-ietf-ipv6-link-scoped-mcast-09 RFC3306 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4489
RFC4490 Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS) S. Leontiev Editor G. Chudov Editor May 2006 ASCII 54912 29 CPCMS S/MIME PKIX X.509 certificate CRL revocation public-key one-way hash block cipher encryption decryption MAC HMAC PRF wrap unwrap UKM KEK key Diffie-Hellman agreement transport parameter derivation digest CBC counter mode digital signature

This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents. [STANDARDS-TRACK]

draft-ietf-smime-gost-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4490 10.17487/RFC4490
RFC4491 Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile S. Leontiev Editor D. Shefanovski Editor May 2006 ASCII 39095 20 PKIX X.509 CPPK public-key one-way hash function block cipher encryption decryption key derivation parameter message digest digital signature 34.310 34.311 34.310-95 34.310-2004 34.311-95

This document supplements RFC 3279. It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509 Public Key Infrastructure (PKI). [STANDARDS-TRACK]

draft-ietf-pkix-gost-cppk-05 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4491 10.17487/RFC4491
RFC4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) S. Blake-Wilson N. Bolyard V. Gupta C. Hawk B. Moeller May 2006 ASCII 72231 35 ecdh elliptic curve diffie-hellman elliptic curve digital signature algorithm ecdsa

This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. This memo provides information for the Internet community.

draft-ietf-tls-ecc-12 RFC5246 RFC7027 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4492 10.17487/RFC4492
RFC4493 The AES-CMAC Algorithm JH. Song R. Poovendran J. Lee T. Iwata June 2006 ASCII 38751 20 cipher-based message authentication code omac1 one-key cbc mac1 advanced encryption algorithm

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard (AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.

draft-songlee-aes-cmac-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4493
RFC4494 The AES-CMAC-96 Algorithm and Its Use with IPsec JH. Song R. Poovendran J. Lee June 2006 ASCII 14992 8 cipher-basd message authentication code one-key cbc-mac1 omac1 xcbc extended cipher block chaining advanced encryption standard

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC). This memo specifies the use of CMAC mode as an authentication mechanism of the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols. This new algorithm is named AES-CMAC-96. [STANDARDS-TRACK]

draft-songlee-aes-cmac-96-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4494
RFC4495 A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow J. Polk S. Dhesikan May 2006 ASCII 44983 21 rsvpv1

This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms of RSVP tunnels. This specification is an extension of RFC 2205. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-bw-reduction-02 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4495
RFC4496 Open Pluggable Edge Services (OPES) SMTP Use Cases M. Stecher A. Barbir May 2006 ASCII 27403 12

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES. This memo provides information for the Internet community.

draft-ietf-opes-smtp-use-cases-06 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC4496
RFC4497 Interworking between the Session Initiation Protocol (SIP) and QSIG J. Elwell F. Derks P. Mourot O. Rousseau May 2006 ASCII 149992 65 telecommunication networks enterprise networks signalling

This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-qsig2sip-04 BCP0117 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC4497
RFC4498 The Managed Object Aggregation MIB G. Keeni May 2006 ASCII 59214 29 management information base aggregate mib time aggregate mib

This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the Aggregation MIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated Managed Object instances. This memo defines an Experimental Protocol for the Internet community.

draft-glenn-mo-aggr-mib-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4498
RFC4501 Domain Name System Uniform Resource Identifiers S. Josefsson May 2006 ASCII 20990 10 dns uri

This document defines Uniform Resource Identifiers for Domain Name System resources. [STANDARDS-TRACK]

draft-josefsson-dns-url-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4501 10.17487/RFC4501
RFC4502 Remote Network Monitoring Management Information Base Version 2 S. Waldbusser May 2006 ASCII 290816 142 RMON-MIB RMON MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices.

This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module. [STANDARDS-TRACK]

draft-ietf-rmonmib-rmon2-v2-05 RFC2021 RFC3273 DRAFT STANDARD DRAFT STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=4502 10.17487/RFC4502
RFC4503 A Description of the Rabbit Stream Cipher Algorithm M. Boesgaard M. Vesterager E. Zenner May 2006 ASCII 22308 12 iv initialization vector encryption algorithm

This document describes the encryption algorithm Rabbit. It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV). The method was published in 2003 and has been subject to public security and performance revision. Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed. This memo provides information for the Internet community.

draft-zenner-rabbit-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4503 10.17487/RFC4503
RFC4504 SIP Telephony Device Requirements and Configuration H. Sinnreich Editor S. Lass C. Stredicke May 2006 ASCII 84849 37 session initiation protocol pc pda analog

This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.

We present a glossary of the most common settings and some of the more widely used values for some settings. This memo provides information for the Internet community.

draft-sinnreich-sipdev-req-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4504
RFC4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism K. Zeilenga June 2006 ASCII 16599 9 SASL-ANON Simple Authentication Security Layer

On the Internet, it is common practice to permit anonymous access to various services. Traditionally, this has been done with a plain-text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. [STANDARDS-TRACK]

draft-ietf-sasl-anon-05 RFC2245 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl 10.17487/RFC4505
RFC4506 XDR: External Data Representation Standard M. Eisler Editor May 2006 ASCII 55477 27 XDR rpc onc open network computing

This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832. [STANDARDS-TRACK]

draft-ietf-nfsv4-rfc1832bis-06 RFC1832 STD0067 INTERNET STANDARD INTERNET STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=4506 10.17487/RFC4506
RFC4507 Transport Layer Security (TLS) Session Resumption without Server-Side State J. Salowey H. Zhou P. Eronen H. Tschofenig May 2006 ASCII 35329 17

This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping \%per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. [STANDARDS-TRACK]

draft-salowey-tls-ticket-07 RFC5077 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4507
RFC4508 Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method O. Levin A. Johnston May 2006 ASCII 11338 6 caller preferences

The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. [STANDARDS-TRACK]

draft-ietf-sip-refer-feature-param-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4508
RFC4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) W. Hardaker May 2006 ASCII 14155 7 domain name system dns dnskey

This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]

draft-ietf-dnsext-ds-sha256-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4509 10.17487/RFC4509
RFC4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map K. Zeilenga Editor June 2006 ASCII 12354 7 LDAPV3 LDAv3 x.500 LDAP3-ATD syntax LDAP3-UTF8 x.500 ASN.1 string format STR-LDAP LDAP-URL Lightweight Directory Access Protocol Universal Resource Locator

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document provides a road map of the LDAP Technical Specification. [STANDARDS-TRACK]

draft-ietf-ldapbis-roadmap-08 RFC2251 RFC2252 RFC2253 RFC2254 RFC2255 RFC2256 RFC2829 RFC2830 RFC3377 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis 10.17487/RFC4510
RFC4511 Lightweight Directory Access Protocol (LDAP): The Protocol J. Sermersheim Editor June 2006 ASCII 150116 68 LDAP TLS LDAPv3 LDAv3 x.500

This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]

draft-ietf-ldapbis-protocol-32 RFC2251 RFC2830 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4511 10.17487/RFC4511
RFC4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models K. Zeilenga Editor June 2006 ASCII 108377 52 LDAv3 x.500 LDAPv3 LDAP3-ATD syntax elective extensions mechanisms

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP. [STANDARDS-TRACK]

draft-ietf-ldapbis-models-14 RFC2251 RFC2252 RFC2256 RFC3674 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4512 10.17487/RFC4512
RFC4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms R. Harrison Editor June 2006 ASCII 80546 34 LDAP TLS

This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.

This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.

This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.

This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. [STANDARDS-TRACK]

draft-ietf-ldapbis-authmeth-19 RFC2251 RFC2829 RFC2830 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis 10.17487/RFC4513
RFC4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names K. Zeilenga Editor June 2006 ASCII 31859 15 LDAP3-UTF8 LDAPv3 x.500 ASN.1 string format

The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]

draft-ietf-ldapbis-dn-16 RFC2253 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4514 10.17487/RFC4514
RFC4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters M. Smith Editor T. Howes June 2006 ASCII 23885 12 STR-LDAP STRLDAP LDAPv3 X.500 BER ASN.1

Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. [STANDARDS-TRACK]

draft-ietf-ldapbis-filter-09 RFC2254 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4515 10.17487/RFC4515
RFC4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator M. Smith Editor T. Howes June 2006 ASCII 30562 15 LDAP-URL LDAPURL LDAP search URL URI LDAPv3

This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. [STANDARDS-TRACK]

draft-ietf-ldapbis-url-09 RFC2255 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4516 10.17487/RFC4516
RFC4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules S. Legg Editor June 2006 ASCII 114285 53 LDAP3-ATD LDAv3 x.500 syntax,

Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. [STANDARDS-TRACK]

draft-ietf-ldapbis-syntaxes-11 RFC2252 RFC2256 RFC3698 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis 10.17487/RFC4517
RFC4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation K. Zeilenga June 2006 ASCII 28166 14

The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This led to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use in LDAP. [STANDARDS-TRACK]

draft-ietf-ldapbis-strprep-07 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4518 10.17487/RFC4518
RFC4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications A. Sciberras Editor June 2006 ASCII 64996 35 Lightweight Directory Access Protocol syntax

This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. [STANDARDS-TRACK]

draft-ietf-ldapbis-user-schema-11 RFC2256 RFC2247 RFC2798 RFC2377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4519 10.17487/RFC4519
RFC4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) K. Zeilenga June 2006 ASCII 34298 19

This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to the Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ldapbis-bcp64-07 RFC3383 BCP0064 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ldapbis 10.17487/RFC4520
RFC4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions K. Zeilenga June 2006 ASCII 34585 16

The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas. This document discusses considerations for designers of LDAP extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-zeilenga-ldap-ext-10 BCP0118 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4521 10.17487/RFC4521
RFC4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option S. Legg June 2006 ASCII 16276 8 ber ldap-specific encoding

Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP\-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. [STANDARDS-TRACK]

draft-legg-ldap-binary-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4522
RFC4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates K. Zeilenga June 2006 ASCII 43753 24 LDAP3-ATD LDAv3 x.500 syntax pkix

This document describes schema for representing X.509 certificates, X.521 security information, and related elements in directories accessible using the Lightweight Directory Access Protocol (LDAP). The LDAP definitions for these X.509 and X.521 schema elements replace those provided in RFCs 2252 and 2256. [STANDARDS-TRACK]

draft-zeilenga-ldap-x509-02 RFC2252 RFC2256 RFC2587 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4523 10.17487/RFC4523
RFC4524 COSINE LDAP/X.500 Schema K. Zeilenga Editor June 2006 ASCII 11245 25 Naming

This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE and Internet X.500 pilot projects.

This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. [STANDARDS-TRACK]

draft-zeilenga-ldap-cosine-02 RFC1274 RFC2247 RFC2798 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4524 10.17487/RFC4524
RFC4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension K. Zeilenga June 2006 ASCII 11251 6 pre-read post-read control extension

This document describes an extension to the Lightweight Directory Access Protocol (LDAP) Modify operation to support an increment capability. This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre-read or post-read control extension. This memo provides information for the Internet community.

draft-zeilenga-ldap-incr-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4525
RFC4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters K. Zeilenga June 2006 ASCII 10097 5 x.500 string representation

This document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. [STANDARDS-TRACK]

draft-zeilenga-ldap-t-f-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4526 10.17487/RFC4526
RFC4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls K. Zeilenga June 2006 ASCII 15987 8

This document specifies an extension to the Lightweight Directory Access Protocol (LDAP) to allow the client to read the target entry of an update operation. The client may request to read the entry before and/or after the modifications are applied. These reads are done as an atomic part of the update operation. [STANDARDS-TRACK]

draft-zeilenga-ldap-readentry-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4527
RFC4528 Lightweight Directory Access Protocol (LDAP) Assertion Control K. Zeilenga June 2006 ASCII 12539 6 test and set test and clear

This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true. It can be used to construct "test and set", "test and clear", and other conditional operations. [STANDARDS-TRACK]

draft-zeilenga-ldap-assert-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4528
RFC4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol K. Zeilenga June 2006 ASCII 11927 6

The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class. This memo provides information for the Internet community.

draft-zeilenga-ldap-adlist-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4529 10.17487/RFC4529
RFC4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute K. Zeilenga June 2006 ASCII 15191 8 x.500 universally unique identifier

This document describes the LDAP/X.500 \'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. [STANDARDS-TRACK]

draft-zeilenga-ldap-uuid-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4530
RFC4531 Lightweight Directory Access Protocol (LDAP) Turn Operation K. Zeilenga June 2006 ASCII 18986 9 turn request turn response

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other. This memo defines an Experimental Protocol for the Internet community.

draft-zeilenga-ldap-turn-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4531
RFC4532 Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation K. Zeilenga June 2006 ASCII 14247 7 authorization identity

This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP "Who am I?" operation. [STANDARDS-TRACK]

draft-zeilenga-ldap-authzid-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4532 10.17487/RFC4532
RFC4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation K. Zeilenga J.H. Choi June 2006 ASCII 73895 32 dit directory information tree

This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation. This memo defines an Experimental Protocol for the Internet community.

draft-zeilenga-ldup-sync-06 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4533
RFC4534 Group Security Policy Token v1 A Colegrove H Harney June 2006 ASCII 54157 33 cryptographic group

The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a token. [STANDARDS-TRACK]

draft-ietf-msec-policy-token-sec-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=4534 10.17487/RFC4534
RFC4535 GSAKMP: Group Secure Association Key Management Protocol H. Harney U. Meth A. Colegrove G. Gross June 2006 ASCII 240863 106 security framework cryptographic network

This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. [STANDARDS-TRACK]

draft-ietf-msec-gsakmp-sec-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4535
RFC4536 The application/smil and application/smil+xml Media Types P. Hoschka July 2006 ASCII 13747 8 synchronized multimedia integration language

This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL 2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation. This memo provides information for the Internet community.

draft-hoschka-smil-media-type-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4536
RFC4537 Kerberos Cryptosystem Negotiation Extension L. Zhu P. Leach K. Jaganathan June 2006 ASCII 11166 6

This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. [STANDARDS-TRACK]

draft-zhu-kerb-enctype-nego-04 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC4537
RFC4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) J. Rosenberg June 2006 ASCII 36089 17 tdialog

This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. [STANDARDS-TRACK]

draft-ietf-sip-target-dialog-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4538
RFC4539 Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF) T. Edwards May 2006 ASCII 11950 6

This document serves to register a media type for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata. This memo provides information for the Internet community.

draft-edwards-mime-mxf-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4539
RFC4540 NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 M. Stiemerling J. Quittek C. Cadar May 2006 ASCII 152685 67 midcom

This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements. This memo defines an Experimental Protocol for the Internet community.

draft-stiemerling-midcom-simco-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4540
RFC4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches M. Christensen K. Kimball F. Solensky May 2006 ASCII 38555 16 igmpv3 mldv2

This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community.

draft-ietf-magma-snoop-12 INFORMATIONAL INFORMATIONAL IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4541 10.17487/RFC4541
RFC4542 Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite F. Baker J. Polk May 2006 ASCII 99770 42 ieps internet emergency preparedness service call admission control cac phb per hop behavior multi-level precedence and preemption mlpp government emergency telecommunication service gets

RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.

This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. This memo provides information for the Internet community.

draft-ietf-tsvwg-mlpp-that-works-04 RFC5865 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4542
RFC4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH D. McGrew J. Viega May 2006 ASCII 29818 14 encapsulating security payload gcm galois/counter mode authentication header

This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH). GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]

draft-mcgrew-aes-gmac-esp-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4543 10.17487/RFC4543
RFC4544 Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) M. Bakke M. Krueger T. McSweeney J. Muchow May 2006 ASCII 156541 83 tcp/ip scsi

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). [STANDARDS-TRACK]

draft-ietf-ips-iscsi-mib-11 RFC7147 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4544 10.17487/RFC4544
RFC4545 Definitions of Managed Objects for IP Storage User Identity Authorization M. Bakke J. Muchow May 2006 ASCII 87345 43 mib management information base snmp tcp/ip ips-auth-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. [STANDARDS-TRACK]

draft-ietf-ips-auth-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4545 10.17487/RFC4545
RFC4546 Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces D. Raftus E. Cardona June 2006 ASCII 300844 139 cmts cm upstream downstream tdma atdma scdma quality of service channel utilizazation

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). [STANDARDS-TRACK]

draft-ietf-ipcdn-docs-rfmibv2-14 RFC2670 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4546
RFC4547 Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems A. Ahmad G. Nakanishi June 2006 ASCII 83917 40 snmp simple network management protocol mib smiv2 DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification (DOCSIS) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB.

This memo specifies a MIB module in a manner that is compliant to the Structure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. [STANDARDS-TRACK]

draft-ietf-ipcdn-docsisevent-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4547
RFC4548 Internet Code Point (ICP) Assignments for NSAP Addresses E. Gray J. Rutemiller G. Swallow May 2006 ASCII 17950 9 network service access point

This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. [STANDARDS-TRACK]

draft-gray-rfc1888bis-03 RFC1888 RFC4048 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4548
RFC4549 Synchronization Operations for Disconnected IMAP4 Clients A. Melnikov Editor June 2006 ASCII 75417 35 internet message access protocol

This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.

This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.

This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients. This memo provides information for the Internet community.

draft-melnikov-imap-disc-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4549
RFC4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile S. Maes A. Melnikov June 2006 ASCII 48790 23 internet message access protocol,

This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.

The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). [STANDARDS-TRACK]

draft-ietf-lemonade-profile-07 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4550 10.17487/RFC4550
RFC4551 IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization A. Melnikov S. Hole June 2006 ASCII 50265 25 internet mail access protocol

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.

The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.

This document defines an extension to IMAP (RFC 3501). [STANDARDS-TRACK]

draft-ietf-imapext-condstore-09 RFC7162 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=4551 10.17487/RFC4551
RFC4552 Authentication/Confidentiality for OSPFv3 M. Gupta N. Melam June 2006 ASCII 31540 15 open shortest path first authentication header encapsulating security payload ah/esp

This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-auth-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4552 10.17487/RFC4552
RFC4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) A. Vainshtein Editor YJ. Stein Editor June 2006 ASCII 58141 27 SAToP pseudowires circuit emulation structure-agnostic emulation

This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK]

draft-ietf-pwe3-satop-05 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4553 10.17487/RFC4553
RFC4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks T. Chown June 2006 ASCII 23355 11 Virtual Local Area Network

Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. This memo provides information for the Internet community.

draft-ietf-v6ops-vlan-usage-01 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4554
RFC4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE) P. Eronen June 2006 ASCII 78698 33 internet key exchange ipsec internet protocol security vpn virtual private networks

This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. [STANDARDS-TRACK]

draft-ietf-mobike-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec mobike 10.17487/RFC4555
RFC4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu B. Tung June 2006 ASCII 100339 42

This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. [STANDARDS-TRACK]

draft-ietf-cat-kerberos-pk-init-34 RFC6112 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4556 10.17487/RFC4556
RFC4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu K. Jaganathan N. Williams June 2006 ASCII 11593 6

This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension that provides for the use of public key cryptography. [STANDARDS-TRACK]

draft-ietf-krb-wg-ocsp-for-pkinit-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4557 10.17487/RFC4557
RFC4558 Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement Z. Ali R. Rahman D. Prairie D. Papadimitriou June 2006 ASCII 14185 7 Multi-Protocol Label Switching mpls Generalized Multi-Protocol Label Switching gmpls Traffic Engineering te rsvp-te gr graceful restart

Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. [STANDARDS-TRACK]

draft-ietf-ccamp-rsvp-node-id-based-hello-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4558
RFC4559 SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows K. Jaganathan L. Zhu J. Brezak June 2006 ASCII 16088 8 msie microsoft internet explorer iis internet information services simple and protected negotiate nt lan manager

This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed. This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document. This memo provides information for the Internet community.

draft-jaganathan-kerberos-http-01 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4559 10.17487/RFC4559
RFC4560 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations J. Quittek Editor K. White Editor June 2006 ASCII 207956 100 mib management information base DISMAN-PING-MIB DEFINITIONS DISMAN-TRACEROUTE-MIB DEFINITIONS DISMAN-NSLOOKUP-MIB DEFINITIONS

This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host.

Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. [STANDARDS-TRACK]

draft-ietf-disman-remops-mib-v2-09 RFC2925 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC4560
RFC4561 Definition of a Record Route Object (RRO) Node-Id Sub-Object J.-P. Vasseur Editor Z. Ali S. Sivabalan June 2006 ASCII 19362 10 multiprotocol label switching traffic engineering plr point of local repair igp interior gateway protocol as autonomous system abr area border router asbr autonomous system border router

In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS-TRACK]

draft-ietf-mpls-nodeid-subobject-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4561
RFC4562 MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network T. Melsen S. Blake June 2006 ASCII 30332 13 Ethernet Access Network ARP DHCP

This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.

The mechanism - called "MAC-Forced Forwarding" - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts. This memo provides information for the Internet community.

draft-melsen-mac-forced-fwd-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4562
RFC4563 The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) E. Carrara V. Lehtovirta K. Norrman June 2006 ASCII 20464 10 security key management multicast broadcast MBMS

This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol. This is used in, for example, the Multimedia Broadcast/Multicast Service specified in the Third Generation Partnership Project. [STANDARDS-TRACK]

draft-ietf-msec-newtype-keyid-05 RFC6309 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4563
RFC4564 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) S. Govindan Editor H. Cheng ZH. Yao WH. Zhou L. Yang July 2006 ASCII 64576 32 wlan wireless local area network

This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs. This memo provides information for the Internet community.

draft-ietf-capwap-objectives-04 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4564
RFC4565 Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols D. Loher D. Nelson O. Volinsky B. Sarikaya July 2006 ASCII 62929 31

This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005. his memo provides information for the Internet community.

draft-ietf-capwap-eval-00 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4565
RFC4566 SDP: Session Description Protocol M. Handley V. Jacobson C. Perkins July 2006 ASCII 108820 49 SDP mbone internet multicast backbone multimedia internet addresses syntax

This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-new-26 RFC2327 RFC3266 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4566 10.17487/RFC4566
RFC4567 Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) J. Arkko F. Lindholm M. Naslund K. Norrman E. Carrara July 2006 ASCII 67693 30 key management protocol multimedia internet keying mikey

This document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.

General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined. [STANDARDS-TRACK]

draft-ietf-mmusic-kmgmt-ext-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4567 10.17487/RFC4567
RFC4568 Session Description Protocol (SDP) Security Descriptions for Media Streams F. Andreasen M. Baugher D. Wing July 2006 ASCII 107881 44 srtp secure real-time transport protocol

This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS-TRACK]

draft-ietf-mmusic-sdescriptions-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4568
RFC4569 Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag G. Camarillo July 2006 ASCII 6920 4

This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features. This memo provides information for the Internet community.

draft-ietf-sipping-message-tag-00 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4569
RFC4570 Session Description Protocol (SDP) Source Filters B. Quinn R. Finlayson July 2006 ASCII 28601 14 internet protocol ip source-filter ssm source-specific multicast

This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-srcfilter-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4570 10.17487/RFC4570
RFC4571 Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport J. Lazzaro July 2006 ASCII 18751 9 TCP-based media transport TCP tunnel transmission control protocol

This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method. [STANDARDS-TRACK]

draft-ietf-avt-rtp-framing-contrans-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4571 10.17487/RFC4571
RFC4572 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) J. Lennox July 2006 ASCII 38658 17 setup connection reestablishment

This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.

This document extends and updates RFC 4145. [STANDARDS-TRACK]

draft-ietf-mmusic-comedia-tls-06 RFC4145 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4572
RFC4573 MIME Type Registration for RTP Payload Format for H.224 R. Even A. Lochbaum July 2006 ASCII 13587 7 real time transport protocol itu h.281 h.224 far-end camera control

In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. [STANDARDS-TRACK]

draft-ietf-avt-mime-h224-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4573
RFC4574 The Session Description Protocol (SDP) Label Attribute O. Levin G. Camarillo August 2006 ASCII 13484 8 media level attribute media stream

This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-media-label-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4574
RFC4575 A Session Initiation Protocol (SIP) Event Package for Conference State J. Rosenberg H. Schulzrinne O. Levin Editor August 2006 ASCII 97484 48 conference event package uri uniform resource identifier

This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS-TRACK]

draft-ietf-sipping-conference-package-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC4575
RFC4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen P. Psenak P. Pillay-Esnault June 2006 ASCII 15149 7 service provider sp provider edge pe

This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. [STANDARDS-TRACK]

draft-ietf-ospf-2547-dnbit-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4576
RFC4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen P. Psenak P. Pillay-Esnault June 2006 ASCII 61515 25 ce open shortest path first mpls Multiprotocol Label Switching

Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.

This document updates RFC 4364. [STANDARDS-TRACK]

draft-ietf-l3vpn-ospf-2547-06 RFC4364 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4577 10.17487/RFC4577
RFC4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) M. Johnston S. Venaas Editor November 2006 ASCII 13238 7 efi extensible firmware interface

We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible Firmware Interface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. This memo provides information for the Internet community.

draft-ietf-dhc-pxe-options-03 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC4578
RFC4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents A. Johnston O. Levin August 2006 ASCII 96506 43 ua conference-unaware conference-aware focus

This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs. The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-cc-conferencing-07 BCP0119 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC4579
RFC4580 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option B. Volz June 2006 ASCII 10937 6

This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-subid-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4580
RFC4581 Cryptographically Generated Addresses (CGA) Extension Field Format M. Bagnulo J. Arkko October 2006 ASCII 7636 4 tlv

This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. [STANDARDS-TRACK]

draft-bagnulo-cga-ext-02 RFC3972 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4581
RFC4582 The Binary Floor Control Protocol (BFCP) G. Camarillo J. Ott K. Drage November 2006 ASCII 154497 65 conference

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.

This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. [STANDARDS-TRACK]

draft-ietf-xcon-bfcp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC4582
RFC4583 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams G. Camarillo November 2006 ASCII 24150 12 bfcp stream

This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-bfcp-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4583 10.17487/RFC4583
RFC4584 Extension to Sockets API for Mobile IPv6 S. Chakrabarti E. Nordmark July 2006 ASCII 53995 25 advanced socket api mobility header messages hom address destination routing header type 2 socket applications

This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6.

Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options, and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications. This memo provides information for the Internet community.

draft-ietf-mip6-mipext-advapi-07 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4584 10.17487/RFC4584
RFC4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) J. Ott S. Wenger N. Sato C. Burmeister J. Rey July 2006 ASCII 117762 51 media stream feedback based error audio visual profile

Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]

draft-ietf-avt-rtcp-feedback-11 RFC5506 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4585 10.17487/RFC4585
RFC4586 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations C. Burmeister R. Hakenberg A. Miyazaki J. Ott N. Sato S. Fukunaga July 2006 ASCII 66759 28 Real-time Transport Protocol

This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic. This memo provides information for the Internet community.

draft-burmeister-avt-rtcp-feedback-sim-06 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4586 10.17487/RFC4586
RFC4587 RTP Payload Format for H.261 Video Streams R. Even August 2006 ASCII 37477 17 RTP-H.261 real-time transport protocol sdp session description protocol

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP.

The memo also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.

This specification obsoletes RFC 2032. [STANDARDS-TRACK]

draft-ietf-avt-rfc2032-bis-13 RFC2032 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4587 10.17487/RFC4587
RFC4588 RTP Retransmission Payload Format J. Rey D. Leon A. Miyazaki V. Varsa R. Hakenberg July 2006 ASCII 76630 35 real time transport protocol rtcp real-time transport control protocol RTP/AVPF

RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK]

draft-ietf-avt-rtp-retransmission-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4588 10.17487/RFC4588
RFC4589 Location Types Registry H. Schulzrinne H. Tschofenig July 2006 ASCII 24037 12

This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. [STANDARDS-TRACK]

draft-ietf-geopriv-location-types-registry-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC4589
RFC4590 RADIUS Extension for Digest Authentication B. Sterman D. Sadolevsky D. Schwartz D. Williams W. Beck July 2006 ASCII 67181 32 remote authentication dial-in user service sip http

This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]

draft-ietf-radext-digest-auth-09 RFC5090 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4590 10.17487/RFC4590
RFC4591 Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) M. Townsley G. Wilkie S. Booth S. Bryant J. Lau August 2006 ASCII 28232 14 data link protocols frame encapsulation virtual-circuit creation and deletion status change notification

The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel Frame Relay over L2TPv3, including frame encapsulation, virtual-circuit creation and deletion, and status change notification. [STANDARDS-TRACK]

draft-ietf-l2tpext-pwe3-fr-07 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=4591 10.17487/RFC4591
RFC4592 The Role of Wildcards in the Domain Name System E. Lewis July 2006 ASCII 43991 20 cname

This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK]

draft-ietf-dnsext-wcard-clarify-11 RFC1034 RFC2672 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4592 10.17487/RFC4592
RFC4593 Generic Threats to Routing Protocols A. Barbir S. Murphy Y. Yang October 2006 ASCII 48292 22 threat sources threat capability threat action threat consequences

Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately. This memo provides information for the Internet community.

draft-ietf-rpsec-routing-threats-07 INFORMATIONAL INFORMATIONAL IETF rtg rpsec 10.17487/RFC4593
RFC4594 Configuration Guidelines for DiffServ Service Classes J. Babiarz K. Chan F. Baker August 2006 ASCII 144044 57 differentiated services code points traffic conditioners per-hop behaviors phb dscp active queue management aqm

This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. This memo provides information for the Internet community.

draft-ietf-tsvwg-diffserv-service-classes-02 RFC5865 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4594
RFC4595 Use of IKEv2 in the Fibre Channel Security Association Management Protocol F. Maino D. Black July 2006 ASCII 32268 16 internet key exchange

This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies these IKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel. This memo provides information for the Internet community.

draft-maino-fcsp-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4595 10.17487/RFC4595
RFC4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension J. Rosenberg P. Kyzivat July 2006 ASCII 82954 40

This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841. This memo provides information for the Internet community.

draft-ietf-sipping-callerprefs-usecases-05 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4596 10.17487/RFC4596
RFC4597 Conferencing Scenarios R. Even N. Ismail August 2006 ASCII 38428 17 multimedia voice video text interactive text xcon

This document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. This memo provides information for the Internet community.

draft-ietf-xcon-conference-scenarios-05 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC4597
RFC4598 Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio B. Link July 2006 ASCII 39811 17 encoded audio data multichannel audio coding format

This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data. E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media. E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation. [STANDARDS-TRACK]

draft-ietf-avt-rtp-eac3-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4598
RFC4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner M. Handley H. Holbrook I. Kouvelas August 2006 ASCII 340632 150 PDF 304538 PIM-SM routing message type timers flags

This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.

This document obsoletes RFC 2362, an Experimental version of PIM-SM. [STANDARDS-TRACK]

draft-ietf-pim-sm-v2-new-12 RFC2362 RFC5059 RFC5796 RFC6226 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=4601 10.17487/RFC4601
RFC4602 Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis T. Pusateri August 2006 ASCII 15310 8

This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard. This memo provides information for the Internet community.

draft-ietf-pim-proposed-req-02 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC4602
RFC4603 Additional Values for the NAS-Port-Type Attribute G. Zorn G. Weber R. Foltak July 2006 ASCII 7354 5 radius Remote Authentication Dial-In User Service

This document defines a set of values for the NAS-Port-Type RADIUS Attribute. This memo provides information for the Internet community.

draft-zorn-radius-port-type-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4603
RFC4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast H. Holbrook B. Cain B. Haberman August 2006 ASCII 23370 11 ssm

The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK]

draft-holbrook-idmr-igmpv3-ssm-08 RFC3376 RFC3810 PROPOSED STANDARD PROPOSED STANDARD IETF int magma 10.17487/RFC4604
RFC4605 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") B. Fenner H. He B. Haberman H. Sandick August 2006 ASCII 25558 12

In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information. [STANDARDS-TRACK]

draft-ietf-magma-igmp-proxy-06 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4605 10.17487/RFC4605
RFC4606 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control E. Mannie D. Papadimitriou August 2006 ASCII 53492 25

This document provides minor clarification to RFC 3946.

This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when GMPLS signaling is used. [STANDARDS-TRACK]

draft-ietf-ccamp-rfc3946bis-01 RFC3946 RFC6344 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4606 10.17487/RFC4606
RFC4607 Source-Specific Multicast for IP H. Holbrook B. Cain August 2006 ASCII 42990 19 ipv4 ssm ipv6

IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]

draft-ietf-ssm-arch-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ssm http://www.rfc-editor.org/errata_search.php?rfc=4607 10.17487/RFC4607
RFC4608 Source-Specific Protocol Independent Multicast in 232/8 D. Meyer R. Rockell G. Shepherd August 2006 ASCII 15030 7 ip ssm

IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mboned-ssm232-08 BCP0120 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC4608
RFC4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements P. Savola R. Lehtonen D. Meyer October 2006 ASCII 49812 23 security threats intra-domain inter-domain any-source multicast asm source-specific multicast ssm embedded rendezvous point embedded-rp

This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats. This memo provides information for the Internet community.

draft-ietf-mboned-mroutesec-04 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC4609
RFC4610 Anycast-RP Using Protocol Independent Multicast (PIM) D. Farinacci Y. Cai August 2006 ASCII 22490 12 rendezvous point rp msdp register multicast source discovery register-stop

This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS-TRACK]

draft-ietf-pim-anycast-rp-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC4610
RFC4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios M. McBride J. Meylor D. Meyer August 2006 ASCII 33230 14 pim-sm protocol independent multicast sparse mode

This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mboned-msdp-deploy-06 BCP0121 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC4611
RFC4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration P. Jones H. Tamura August 2006 ASCII 15675 8 itu-t recommendation t.38 sdp session description protocol

This document defines the MIME sub-type audio/t38. The usage of this MIME type, which is intended for use within Session Description Protocol (SDP), is specified within ITU-T Recommendation T.38. This memo defines a Historic Document for the Internet community.

draft-jones-avt-audio-t38-05 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4612 10.17487/RFC4612
RFC4613 Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI) P. Frojdh U. Lindgren M. Westerlund September 2006 ASCII 12263 6 dls

This document serves to register a media type for Downloadable Sounds. This memo provides information for the Internet community.

draft-westerlund-mime-dls-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4613
RFC4614 A Roadmap for Transmission Control Protocol (TCP) Specification Documents M. Duke R. Braden W. Eddy E. Blanton September 2006 ASCII 75645 33

This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This memo provides information for the Internet community.

draft-ietf-tcpm-tcp-roadmap-06 RFC7414 RFC6247 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4614
RFC4615 The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) J. Song R. Poovendran J. Lee T. Iwata August 2006 ASCII 13312 7 ipsec ip security pseudo-random function

Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced Encryption Standard (AES). This memo describes such an algorithm, called AES-CMAC-PRF-128. It supports fixed and variable key sizes. [STANDARDS-TRACK]

draft-songlee-aes-cmac-prf-128-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4615
RFC4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism K. Zeilenga Editor August 2006 ASCII 20270 11 data confidentiality

This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. [STANDARDS-TRACK]

draft-ietf-sasl-plain-09 RFC2595 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4616 10.17487/RFC4616
RFC4617 A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project J. Kornijenko August 2006 ASCII 12934 8 general contractor Olimps LTD subcontractors ABC software LTD Microsoft Latvia LTD Riga Internet eXchange Technologies LTD RIX Microlink LTD

This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian National Government Integration Project (Latvian abbreviation IVIS). This memo provides information for the Internet community.

draft-kornijenko-ivis-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4617
RFC4618 Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks L. Martini E. Rosen G. Heron A. Malis September 2006 ASCII 33141 16 pw pseudowire point to point protocol pdu packet data unit

A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol. This enables service providers to offer "emulated" HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire. [STANDARDS-TRACK]

draft-ietf-pwe3-hdlc-ppp-encap-mpls-09 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4618
RFC4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks L. Martini Editor C. Kawa Editor A. Malis Editor September 2006 ASCII 38193 19 pseudowire psn packet switched network pw

A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network. [STANDARDS-TRACK]

draft-ietf-pwe3-frame-relay-07 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4619 10.17487/RFC4619
RFC4620 IPv6 Node Information Queries M. Crawford B. Haberman Editor August 2006 ASCII 31134 14 internet protocol version 6

This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipngwg-icmp-name-lookups-15 EXPERIMENTAL EXPERIMENTAL IETF int ipv6 10.17487/RFC4620
RFC4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol T. Kivinen H. Tschofenig August 2006 ASCII 73070 30 internet key exchange

The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).

This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded. This memo provides information for the Internet community.

draft-ietf-mobike-design-08 INFORMATIONAL INFORMATIONAL IETF sec mobike 10.17487/RFC4621
RFC4622 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre July 2006 ASCII 49968 23 Extensible Messaging and Presence Protocol Internationalized Resource Identifier Uniform Resource Identifier Jabber xmpp iri uri

This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

draft-saintandre-xmpp-iri-04 RFC5122 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4622
RFC4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly A. Malis M. Townsley August 2006 ASCII 36369 17

This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. [STANDARDS-TRACK]

draft-ietf-pwe3-fragmentation-10 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4623 10.17487/RFC4623
RFC4624 Multicast Source Discovery Protocol (MSDP) MIB B. Fenner D. Thaler October 2006 ASCII 58759 32 management information base MSDP-MIB

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mboned-msdp-mib-01 EXPERIMENTAL EXPERIMENTAL IETF ops mboned 10.17487/RFC4624
RFC4625 Fibre Channel Routing Information MIB C. DeSanti K. McCloghrie S. Kode S. Gai September 2006 ASCII 41278 22 management information base T11-FC-ROUTE-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. [STANDARDS-TRACK]

draft-ietf-imss-fc-rtm-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4625
RFC4626 MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol C. DeSanti V. Gaonkar K. McCloghrie S. Gai September 2006 ASCII 67953 36 management information base T11-FC-FSPF-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. [STANDARDS-TRACK]

draft-ietf-imss-fc-fspf-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4626
RFC4627 The application/json Media Type for JavaScript Object Notation (JSON) D. Crockford July 2006 ASCII 16319 10 data interchange format ECMAScript Programming Language Standard

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community.

draft-crockford-jsonorg-json-04 RFC7159 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4627 10.17487/RFC4627
RFC4628 RTP Payload Format for H.263 Moving RFC 2190 to Historic Status R. Even January 2007 ASCII 8084 5 real-time transport protocol itu-t itu telecommunication standardization sector transfer

The first RFC that describes RTP payload format for ITU Telecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190. This specification discusses why to move RFC 2190 to historic status. This memo provides information for the Internet community.

draft-ietf-avt-rfc2190-to-historic-06 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC4628
RFC4629 RTP Payload Format for ITU-T Rec. H.263 Video J. Ott C. Bormann G. Sullivan S. Wenger R. Even Editor January 2007 ASCII 67231 29 real-time transport protocol multicast unicast sdp session description protocol

This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.

The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.

The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 MIME media type in RFC 3555. [STANDARDS-TRACK]

draft-ietf-avt-rfc2429-bis-09 RFC2429 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4629
RFC4630 Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile R. Housley S. Santesson August 2006 ASCII 12539 6 utf8string printablestring

This document updates the handling of DirectoryString in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding. The requirement for exclusive use of UTF8String after December 31, 2003 is removed. [STANDARDS-TRACK]

draft-ietf-pkix-cert-utf8-03 RFC5280 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4630
RFC4631 Link Management Protocol (LMP) Management Information Base (MIB) M. Dubuc T. Nadeau J. Lang E. McGinnis A. Farrel September 2006 ASCII 152560 83 lmp-mib

This document provides minor corrections to and obsoletes RFC 4327.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]

draft-ietf-ccamp-rfc4327bis-01 RFC4327 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4631 10.17487/RFC4631
RFC4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan V. Fuller T. Li August 2006 ASCII 66944 27 CIDR-STRA global routing state

This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grow-rfc1519bis-04 RFC1519 BCP0122 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=4632 10.17487/RFC4632
RFC4633 Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists S. Hartman August 2006 ASCII 14979 7

Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. This memo defines an Experimental Protocol for the Internet community.

draft-hartman-mailinglist-experiment-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4633
RFC4634 US Secure Hash Algorithms (SHA and HMAC-SHA) D. Eastlake 3rd T. Hansen July 2006 ASCII 197147 108 fips federal information processing standard sha-224 sha-256 sha-384 sha-512

The United States of America has adopted a suite of Secure Hash Algorithms (SHAs), including four beyond SHA-1, as part of a Federal Information Processing Standard (FIPS), specifically SHA-224 (RFC 3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS 180-2.

Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. This memo provides information for the Internet community.

draft-eastlake-sha2-02 RFC6234 RFC3174 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4634 10.17487/RFC4634
RFC4635 HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers D. Eastlake 3rd August 2006 ASCII 16533 8 dns resource record rr cryptographic message authentication code cmac

Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. [STANDARDS-TRACK]

draft-ietf-dnsext-tsig-sha-06 RFC2845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4635 10.17487/RFC4635
RFC4636 Foreign Agent Error Extension for Mobile IPv4 C. Perkins October 2006 ASCII 11663 6 internet protocol

This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node. [STANDARDS-TRACK]

draft-ietf-mip4-faerr-02 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4636 10.17487/RFC4636
RFC4637 RFC4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) P. Arberg D. Kourkouzelis M. Duckett T. Anschutz J. Moisand September 2006 ASCII 18984 9

The Point-to-Point Protocol over Ethernet (PPPoE), as described in RFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492. This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks. This memo provides information for the Internet community.

draft-arberg-pppoe-mtu-gt1492-03 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC4638
RFC4639 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems R. Woundy K. Marez December 2006 ASCII 188220 88 snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems.

This memo obsoletes RFC 2669. [STANDARDS-TRACK]

draft-ietf-ipcdn-device-mibv2-11 RFC2669 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4639
RFC4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6) A. Patel Editor G. Giaretta Editor September 2006 ASCII 49926 22 internet protocol version 6 mobile node

A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping. This memo provides information for the Internet community.

draft-ietf-mip6-bootstrap-ps-05 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4640 10.17487/RFC4640
RFC4641 DNSSEC Operational Practices O. Kolkman R. Gieben September 2006 ASCII 79894 35 dns domain name space security extensions zone administrator DNS-SOC cryptology resource records rrs

This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.

The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.

This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community.

draft-ietf-dnsop-dnssec-operational-practices-08 RFC2541 RFC6781 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=4641 10.17487/RFC4641
RFC4642 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) K. Murchison J. Vinocur C. Newman October 2006 ASCII 29366 14 encryption single link confidentiality

This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. [STANDARDS-TRACK]

draft-ietf-nntpext-tls-nntp-09 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4642 10.17487/RFC4642
RFC4643 Network News Transfer Protocol (NNTP) Extension for Authentication J. Vinocur K. Murchison October 2006 ASCII 51411 24 authinfo user/pass authinfo simple authinfo generic sasl simple authentication and security layer

This document defines an extension to the Network News Transfer Protocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.

This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP. [STANDARDS-TRACK]

draft-ietf-nntpext-authinfo-10 RFC2980 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4643 10.17487/RFC4643
RFC4644 Network News Transfer Protocol (NNTP) Extension for Streaming Feeds J. Vinocur K. Murchison October 2006 ASCII 26439 14 check takethis mode stream

This memo defines an extension to the Network News Transfer Protocol (NNTP) to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency.

This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. [STANDARDS-TRACK]

draft-ietf-nntpext-streaming-06 RFC2980 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4644 10.17487/RFC4644
RFC4645 Initial Language Subtag Registry D. Ewell September 2006 ASCII 15517 7 iana

This memo defined the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only served as a starting point for the registry, its actual contents have been removed before publication to avoid confusion. This memo provides information for the Internet community.

draft-ietf-ltru-initial-06 INFORMATIONAL INFORMATIONAL IETF app ltru 10.17487/RFC4645
RFC4646 Tags for Identifying Languages A. Phillips M. Davis September 2006 ASCII 135810 59 Lang-Tag

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ltru-registry-14 RFC3066 RFC5646 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru http://www.rfc-editor.org/errata_search.php?rfc=4646 10.17487/RFC4646
RFC4647 Matching of Language Tags A. Phillips M. Davis September 2006 ASCII 45595 20 Lang-Tag

This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ltru-matching-15 RFC3066 BCP0047 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru 10.17487/RFC4647
RFC4648 The Base16, Base32, and Base64 Data Encodings S. Josefsson October 2006 ASCII 35491 18 schemes data line-feeds alphabets base encoding hex

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]

draft-josefsson-rfc3548bis-04 RFC3548 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4648 10.17487/RFC4648
RFC4649 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option B. Volz August 2006 ASCII 10940 6

This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-remoteid-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4649
RFC4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) M. Euchner September 2006 ASCII 63016 27 Multicast security MIKEY key management Diffie-Hellman key agreement HMAC

This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY. [STANDARDS-TRACK]

draft-ietf-msec-mikey-dhhmac-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=4650 10.17487/RFC4650
RFC4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization C. Vogt J. Arkko February 2007 ASCII 79226 31 Mobile IPv6 Route Optimization Enhancement Mobility Handoff IP Address Tests Protected Tunnels Optimistic Behavior Proactive IP Address Tests Concurrent Care-of Address Tests Diverted Routing Credit-Based Authorization Heuristic Monitoring Crypto-Based Identifiers Pre-Configuration Semi-Permanent Security Associations Delegation Mobile Networks Location Privacy

This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This memo provides information for the Internet community.

draft-irtf-mobopts-ro-enhancements-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC4651
RFC4652 Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements D. Papadimitriou Editor L.Ong J. Sadler S. Shew D. Ward October 2006 ASCII 47179 22 gmpls generalized multiprotocol label switching otn optical transport networks sonet sdh synchronous optical network synchronous digital hierarchy itu-t

The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs).

This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-ason-routing-eval-03 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4652
RFC4653 Improving the Robustness of TCP to Non-Congestion Events S. Bhandarkar A. L. N. Reddy M. Allman E. Blanton August 2006 ASCII 42268 18 ncr non-congestion robustness transmission control protocol

This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tcpm-tcp-dcr-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=4653 10.17487/RFC4653
RFC4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification J. Widmer M. Handley August 2006 ASCII 72190 32 streaming media multicase ip internet protocol

This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-tfmcc-07 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=4654 10.17487/RFC4654
RFC4655 A Path Computation Element (PCE)-Based Architecture A. Farrel J.-P. Vasseur J. Ash August 2006 ASCII 97561 40 traffic engineering

Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.

This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.

draft-ietf-pce-architecture-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4655
RFC4656 A One-way Active Measurement Protocol (OWAMP) S. Shalunov B. Teitelbaum A. Karp J. Boote M. Zekauskas September 2006 ASCII 132303 56 unidirectional characteristics one-way gps cdma

The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]

draft-ietf-ippm-owdp-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC4656
RFC4657 Path Computation Element (PCE) Communication Protocol Generic Requirements J. Ash Editor J.L. Le Roux Editor September 2006 ASCII 45284 21 pce architecture pcc path computation client

The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community.

draft-ietf-pce-comm-protocol-gen-reqs-07 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4657
RFC4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN J. De Clercq D. Ooms M. Carugi F. Le Faucheur September 2006 ASCII 42090 18 service provider border gateway protocol multiprotocol label switching

This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".

This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. [STANDARDS-TRACK]

draft-ietf-l3vpn-bgp-ipv6-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4659 10.17487/RFC4659
RFC4660 Functional Description of Event Notification Filtering H. Khartabil E. Leppanen M. Lonnfors J. Costa-Requena September 2006 ASCII 63886 31 event state subscription presence filter criteria

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.

This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. [STANDARDS-TRACK]

draft-ietf-simple-event-filter-funct-05 RFC6665 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4660 10.17487/RFC4660
RFC4661 An Extensible Markup Language (XML)-Based Format for Event Notification Filtering H. Khartabil E. Leppanen M. Lonnfors J. Costa-Requena September 2006 ASCII 48890 24 event state subscription presence filter criteria

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document. [STANDARDS-TRACK]

draft-ietf-simple-filter-format-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4661 10.17487/RFC4661
RFC4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists A. B. Roach B. Campbell J. Rosenberg August 2006 ASCII 82778 39

This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes. [STANDARDS-TRACK]

draft-ietf-simple-event-list-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4662 10.17487/RFC4662
RFC4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG D. Harrington September 2006 ASCII 47973 22 management information base

This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage. This memo provides information for the Internet community.

draft-harrington-8021-mib-transition-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4663
RFC4664 Framework for Layer 2 Virtual Private Networks (L2VPNs) L. Andersson Editor E. Rosen Editor September 2006 ASCII 97768 44

This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community.

draft-ietf-l2vpn-l2-framework-05 INFORMATIONAL INFORMATIONAL IETF int l2vpn http://www.rfc-editor.org/errata_search.php?rfc=4664 10.17487/RFC4664
RFC4665 Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks W. Augustyn Editor Y. Serbest Editor September 2006 ASCII 68972 32 l2vpn ppvpn virtual private wire service vpws virtual private lan service vpls

This document provides requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives. This memo provides information for the Internet community.

draft-ietf-l2vpn-requirements-07 INFORMATIONAL INFORMATIONAL IETF int l2vpn 10.17487/RFC4665
RFC4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) K. Morneault Editor J. Pastor-Balbas Editor September 2006 ASCII 292991 124 mtp isup sccp sctp stream control tranmission protocol mgc media gateway protocol st signalling gateway

This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. This document obsoletes RFC 3332. [STANDARDS-TRACK]

draft-ietf-sigtran-rfc3332bis-06 RFC3332 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=4666 10.17487/RFC4666
RFC4667 Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) W. Luo September 2006 ASCII 33166 15 L2VPN L2TP L2TPv3 pseudowire forwarder

The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types of L2VPNs in a unified fashion. [STANDARDS-TRACK]

draft-ietf-l2tpext-l2vpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4667
RFC4668 RADIUS Authentication Client MIB for IPv6 D. Nelson August 2006 ASCII 48252 24 management information base security remote access dialin user service RADIUS-AUTH-CLIENT-MIB

This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients.

This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]

draft-ietf-radext-rfc2618bis-04 RFC2618 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4668 10.17487/RFC4668
RFC4669 RADIUS Authentication Server MIB for IPv6 D. Nelson August 2006 ASCII 50525 25 management information base security remote access dialin user service RADIUS-AUTH-SERVER-MIB

This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers.

This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]

draft-ietf-radext-rfc2619bis-04 RFC2619 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4669 10.17487/RFC4669
RFC4670 RADIUS Accounting Client MIB for IPv6 D. Nelson August 2006 ASCII 44667 23 management information base security remote access dialin user service RADIUS-ACC-CLIENT-MIB

This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients.

This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.

draft-ietf-radext-rfc2620bis-04 RFC2620 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4670 10.17487/RFC4670
RFC4671 RADIUS Accounting Server MIB for IPv6 D. Nelson August 2006 ASCII 47694 24 management information base security remote access dialin user service RADIUS-ACC-SERVER-MIB

This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting servers.

This memo obsoletes RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.

draft-ietf-radext-rfc2621bis-04 RFC2621 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4671 10.17487/RFC4671
RFC4672 RADIUS Dynamic Authorization Client MIB S. De Cnodder N. Jonnala M. Chiba September 2006 ASCII 50817 24 remote authentication dial-in user service dac dynamic authorization client RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. This memo provides information for the Internet community.

draft-ietf-radext-dynauth-client-mib-06 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4672 10.17487/RFC4672
RFC4673 RADIUS Dynamic Authorization Server MIB S. De Cnodder N. Jonnala M. Chiba September 2006 ASCII 47635 24 management information base remote authentication dial-in user service RADIUS-DYNAUTH-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. This memo provides information for the Internet community.

draft-ietf-radext-dynauth-server-mib-06 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4673 10.17487/RFC4673
RFC4674 Requirements for Path Computation Element (PCE) Discovery J.L. Le Roux Editor October 2006 ASCII 40321 19 path computation client pcc

This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. This memo provides information for the Internet community.

draft-ietf-pce-discovery-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4674
RFC4675 RADIUS Attributes for Virtual LAN and Priority Support P. Congdon M. Sanchez B. Aboba September 2006 ASCII 29751 15 remote authentication dial-in user service local area network

This document proposes additional Remote Authentication Dial-In User Service (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks. These attributes are usable within either RADIUS or Diameter. [STANDARDS-TRACK]

draft-ietf-radext-vlan-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4675 10.17487/RFC4675
RFC4676 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information H. Schulzrinne October 2006 ASCII 45208 19 lci local configuration information

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]

draft-ietf-geopriv-dhcp-civil-09 RFC4776 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4676 10.17487/RFC4676
RFC4677 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force P. Hoffman S. Harris September 2006 ASCII 127383 50 meeting

This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. This memo provides information for the Internet community.

draft-hoffman-taobis-08 RFC3160 RFC6722 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4677 10.17487/RFC4677
RFC4678 Server/Application State Protocol v1 A. Bivens September 2006 ASCII 102713 48 sasp server/application state protocol

Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. The Server/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members. This memo provides information for the Internet community.

draft-bivens-sasp-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4678 10.17487/RFC4678
RFC4679 DSL Forum Vendor-Specific RADIUS Attributes V. Mammoliti G. Zorn P. Arberg R. Rennison September 2006 ASCII 42743 25 remote authentication dial-in user service vsa dsl digital subscriber line

This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum.

These attributes are designed to transport Digital Subscriber Line (DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. This memo provides information for the Internet community.

draft-mammoliti-radius-dsl-vsa-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4679 10.17487/RFC4679
RFC4680 TLS Handshake Message for Supplemental Data S. Santesson October 2006 ASCII 15602 9 transport layer security

This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. [STANDARDS-TRACK]

draft-santesson-tls-supp-02 RFC4346 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4680
RFC4681 TLS User Mapping Extension S. Santesson A. Medvinsky J. Ball October 2006 ASCII 20682 11 transport layer security handshake message upndomainhint

This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future. [STANDARDS-TRACK]

draft-santesson-tls-ume-07 RFC4346 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4681
RFC4682 Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices E. Nechamkin J-F. Mule December 2006 ASCII 137373 60 mib snmp simple network management protocol PKTC-IETF-MTA-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

draft-ietf-ipcdn-pktc-mtamib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4682
RFC4683 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) J. Park J. Lee H.. Lee S. Park T. Polk October 2006 ASCII 41285 20 subjectaltname privacy-sensitive identifiers pepsi

This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.

The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. [STANDARDS-TRACK]

draft-ietf-pkix-sim-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4683 10.17487/RFC4683
RFC4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) P. Marques R. Bonica L. Fang L. Martini R. Raszuk K. Patel J. Guichard November 2006 ASCII 28474 14 mp-bgp bgp speakers route target

This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364. [STANDARDS-TRACK]

draft-ietf-l3vpn-rt-constrain-02 RFC4364 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4684 10.17487/RFC4684
RFC4685 Atom Threading Extensions J. Snell September 2006 ASCII 24403 12 atom syndication format extension threading syndication

This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. [STANDARDS-TRACK]

draft-snell-atompub-feed-thread-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4685
RFC4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) J. Fenton September 2006 ASCII 70382 29 email attack authentication signature ssp

This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. This memo provides information for the Internet community.

draft-ietf-dkim-threats-03 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC4686
RFC4687 Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks S. Yasukawa A. Farrel D. King T. Nadeau September 2006 ASCII 30486 14 multiprotocol label switching pwmp lsp p2mp mpls lsp

Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.

For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.

This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. This memo provides information for the Internet community.

draft-ietf-mpls-p2mp-oam-reqs-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4687
RFC4688 A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D S. Rushing October 2006 ASCII 13255 8

This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D. This memo provides information for the Internet community.

draft-rushing-s1000d-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4688
RFC4689 Terminology for Benchmarking Network-layer Traffic Control Mechanisms S. Poretsky J. Perser S. Erramilli S. Khurana October 2006 ASCII 62369 34 packet classification

This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms. Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number. This memo provides information for the Internet community.

draft-ietf-bmwg-dsmterm-13 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4689
RFC4690 Review and Recommendations for Internationalized Domain Names (IDNs) J. Klensin P. Faltstrom C. Karp IAB September 2006 ASCII 100929 37 dns domain namespace idna internationalizing domain names in applications

This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed. This memo provides information for the Internet community.

draft-iab-idn-nextsteps-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4690
RFC4691 Guidelines for Acting as an IETF Liaison to Another Organization L. Andersson Editor October 2006 ASCII 33888 14 internet engineering task force sdo standards development organization consortium industrial forum

Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052. This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them. This memo provides information for the Internet community.

draft-iab-liaison-guidelines-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4691
RFC4692 Considerations on the IPv6 Host Density Metric G. Huston October 2006 ASCII 41357 17 internet protocol version 6 ipv6 unicast address blocks

This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches. This memo provides information for the Internet community.

draft-huston-hd-metric-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4692
RFC4693 IETF Operational Notes H. Alvestrand October 2006 ASCII 19268 10 ION

This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.

It proposes to establish this series as an RFC 3933 process experiment. This memo defines an Experimental Protocol for the Internet community.

draft-alvestrand-ipod-03 RFC6393 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4693
RFC4694 Number Portability Parameters for the "tel" URI J. Yu October 2006 ASCII 36910 15 uniform resource identifier np

This document defines five parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed. [STANDARDS-TRACK]

draft-ietf-iptel-tel-np-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4694
RFC4695 RTP Payload Format for MIDI J. Lazzaro J. Wawrzynek November 2006 ASCII 403808 169 asc content streaming DLS 2 General MIDI MIDI MIDI file MIDI file streaming MIDI light control MIDI rendering MIDI ringtone MIDI streaming MIDI sequencer MIDI time code MIDI timecode MIDI Manufacturers Association MMA mpeg4-generic MPEG 4 MPEG 4 Structured Audio MPEG 4 Synthetic Coding MTC musical notes network musical performance recovery journal Show Control sonification ringtone rtp-midi RTP RTP MIDI SMPTE time code SMPTE timecode Standard MIDI Files XMF

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. [STANDARDS-TRACK]

draft-ietf-avt-rtp-midi-format-15 RFC6295 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4695 10.17487/RFC4695
RFC4696 An Implementation Guide for RTP MIDI J. Lazzaro J. Wawrzynek November 2006 ASCII 83827 38 checkpoint packet checkpoint history guard packets jitter keep-alive packets MIDI musical telepresence network musical performance NMP receiving algorithm recovery journal recovery journal receiving structure recovery journal sending structure RTP RTP MIDI queuing MIDI sending algorithm sending MIDI telepresence

This memo offers non-normative implementation guidance for the Real-time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. [STANDARDS-TRACK]

draft-ietf-avt-rtp-midi-guidelines-15 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4696 10.17487/RFC4696
RFC4697 Observed DNS Resolution Misbehavior M. Larson P. Barber October 2006 ASCII 45187 18 domain name system tld top level domain

This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsop-bad-dns-res-06 BCP0123 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC4697
RFC4698 IRIS: An Address Registry (areg) Type for the Internet Registry Information Service E. Gunduz A. Newton S. Kerr October 2006 ASCII 89932 48 ip address autonomous system number internet protocol address

This document describes an IRIS registry schema for IP address and Autonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. [STANDARDS-TRACK]

draft-ietf-crisp-iris-areg-15 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4698 10.17487/RFC4698
RFC4701 A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) M. Stapp T. Lemon A. Gustafsson October 2006 ASCII 24570 12 dns fqdn fully qualified domain name

It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct Resource Record (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR. [STANDARDS-TRACK]

draft-ietf-dnsext-dhcid-rr-13 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4701 10.17487/RFC4701
RFC4702 The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option M. Stapp B. Volz Y. Rekhter October 2006 ASCII 37534 17 dhcpv4 dns rr

This document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. [STANDARDS-TRACK]

draft-ietf-dhc-fqdn-option-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4702
RFC4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients M. Stapp B. Volz October 2006 ASCII 29690 13 dynamic assignment dns dhcid dns rr

The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names (FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts. [STANDARDS-TRACK]

draft-ietf-dhc-ddns-resolution-12 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4703
RFC4704 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option B. Volz October 2006 ASCII 32359 15 dns rr

This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-fqdn-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4704
RFC4705 GigaBeam High-Speed Radio Link Encryption R. Housley A. Corry October 2006 ASCII 30926 15 key management wifiber radio link

This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products. The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities. This memo provides information for the Internet community.

draft-housley-gigabeam-radio-link-encrypt-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4705 10.17487/RFC4705
RFC4706 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) M. Morgenstern M. Dodge S. Baillie U. Bonollo November 2006 ASCII 347648 167 mib management information base adsl2+ ADSL2-LINE-TC-MIB ADSL2-LINE-MIB

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Asymmetric Digital Subscriber Line" family of interface types: ADSL, ADSL2, ADSL2+, and their variants. [STANDARDS-TRACK]

draft-ietf-adslmib-adsl2-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4706
RFC4707 Netnews Administration System (NAS) P. Grau V. Heinau H. Schlichting R. Schuettler October 2006 ASCII 86510 49 news servers news administrator news reader

The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.

The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.

NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible. Furthermore, NAS is able to reflect the somewhat chaotic structure of Usenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS-compliant software. This memo defines an Experimental Protocol for the Internet community.

draft-dfncis-netnews-admin-sys-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4707
RFC4708 CellML Media Type A. Miller October 2006 ASCII 13217 7 media format mathematical model mathematical modelling mathematical modeling content MathML markup languages bioengineering biology

This document standardises a new media type -- application/cellml+xml -- for use in exchanging mathematical models represented in a CellML Umbrella 1.0 compliant markup language. This memo provides information for the Internet community.

draft-miller-media-type-cellml-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4708
RFC4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers J. Reschke October 2006 ASCII 23672 15 drag-and-drop

In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of a Web Distinguished Authoring and Versioning (WebDAV) server. For example, it is frequently desirable to be able to click on a link and have this link open a window that can handle drag-and-drop interaction with the resources of a WebDAV server.

This document specifies a mechanism and a document format that enables WebDAV servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. This memo provides information for the Internet community.

draft-reschke-webdav-mount-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4709
RFC4710 Real-time Application Quality-of-Service Monitoring (RAQMON) Framework A. Siddiqui D. Romascanu E. Golovinsky October 2006 ASCII 86403 36 internet protocol end-devices qos quality of service snmp simple network management protocol

There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications. [STANDARDS-TRACK]

draft-ietf-rmonmib-raqmon-framework-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4710
RFC4711 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB A. Siddiqui D. Romascanu E. Golovinsky October 2006 ASCII 77341 38 management information base remote monitoring mib qos RAQMON-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB, RFC 2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. [STANDARDS-TRACK]

draft-ietf-rmonmib-raqmon-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4711
RFC4712 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) A. Siddiqui D. Romascanu E. Golovinsky M. Rahman,Y. Kim October 2006 ASCII 109407 48 mib management information base snmp simple network management protocol rds raqmon data source qos RAQMON-RDS-MIB

This memo specifies two transport mappings of the \%Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). [STANDARDS-TRACK]

draft-ietf-rmonmib-raqmon-pdu-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4712
RFC4713 Registration and Administration Recommendations for Chinese Domain Names X. Lee W. Mao E. Chen N. Hsu J. Klensin October 2006 ASCII 18883 9 cdn sc simplified chinese tc traditional chinese

Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDNs) have at least two different forms. The equivalence between Simplified Chinese (SC) and Traditional Chinese (TC) characters is very important for CDN registration. This memo builds on the basic concepts, general guidelines, and framework of RFC 3743 to specify proposed registration and administration procedures for Chinese domain names. The document provides the information needed for understanding and using the tables defined in the IANA table registrations for Simplified and Traditional Chinese. This memo provides information for the Internet community.

draft-xdlee-idn-cdnadmin-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4713
RFC4714 Requirements for IETF Technical Publication Service A. Mankin S. Hayes October 2006 ASCII 53988 24 internet engineering task force

The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process. This memo provides information for the Internet community.

draft-mankin-pub-req-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4714
RFC4715 The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI M. Munakata S. Schubert T. Ohba November 2006 ASCII 28910 14 uniform resource identifier isup isdn user part

Without a tel URI parameter to carry an encoding type of Integrated Services Digital Network (ISDN) subaddress, interworking between ISDN User Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress. This memo provides information for the Internet community.

draft-munakata-iptel-isub-type-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4715
RFC4716 The Secure Shell (SSH) Public Key File Format J. Galbraith R. Thayer November 2006 ASCII 18395 10

This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations.

In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community.

draft-ietf-secsh-publickeyfile-13 INFORMATIONAL INFORMATIONAL IETF sec secsh 10.17487/RFC4716
RFC4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks L. Martini J. Jayakumar M. Bocci N. El-Aawar J. Brayley G. Koleyni December 2006 ASCII 86173 40 pw pseudowire multiprotocol label switching

An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carry ATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide an ATM service. [STANDARDS-TRACK]

draft-ietf-pwe3-atm-encap-11 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4717 10.17487/RFC4717
RFC4718 IKEv2 Clarifications and Implementation Guidelines P. Eronen P. Hoffman October 2006 ASCII 129982 58 internet key exchange

This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. This memo provides information for the Internet community.

draft-eronen-ipsec-ikev2-clarifications-09 RFC5996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4718 10.17487/RFC4718
RFC4719 Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) R. Aggarwal Editor M. Townsley Editor M. Dos Santos Editor November 2006 ASCII 30764 14 port-to-port vlan

This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. [STANDARDS-TRACK]

draft-ietf-l2tpext-pwe3-ethernet-09 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=4719 10.17487/RFC4719
RFC4720 Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention A. Malis D. Allan N. Del Regno November 2006 ASCII 18248 9 fcs

This document defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires. [STANDARDS-TRACK]

draft-ietf-pwe3-fcs-retention-04 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4720
RFC4721 Mobile IPv4 Challenge/Response Extensions (Revised) C. Perkins P. Calhoun J. Bharatia January 2007 ASCII 60386 26 chap

Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as Challenge Handshake Authentication Protocol (CHAP)) for authenticating portable computer devices.

In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.

Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication, Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012. [STANDARDS-TRACK]

draft-ietf-mip4-rfc3012bis-05 RFC3012 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4721 10.17487/RFC4721
RFC4722 Media Server Control Markup Language (MSCML) and Protocol J. Van Dyke E. Burger Editor A. Spitzer November 2006 ASCII 184055 81 sip ivr interactive voice response

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. This memo provides information for the Internet community.

draft-vandyke-mscml-09 RFC5022 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4722
RFC4723 Registration of Media Type audio/mobile-xmf T. Kosonen T. White December 2006 ASCII 12652 8 mma midi manufacturers association association of musical electronices industry amei MIDI Musical Instrument Digital Interface

The MIDI Manufacturers Association (MMA) and the Association of Musical Electronics Industry (AMEI) have produced the Mobile XMF standard, which was developed particularly for mobile MIDI applications. Mobile XMF is a very compact media type providing high-quality synthetic audio content for music downloading and messaging applications that require MIME registration. This document registers the media type audio/mobile-xmf. This memo provides information for the Internet community.

draft-kosonen-mobile-xmf-mediatype-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4723
RFC4724 Graceful Restart Mechanism for BGP S. Sangli E. Chen R. Fernando J. Scudder Y. Rekhter January 2007 ASCII 32343 15 border gateway protocol end-of-rib bgp restart

This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.

The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS-TRACK]

draft-ietf-idr-restart-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4724 10.17487/RFC4724
RFC4725 ENUM Validation Architecture A. Mayrhofer B. Hoeneisen November 2006 ASCII 33216 17 E.164 Registry Registrar Registrant Assignee

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure. This memo provides information for the Internet community.

draft-ietf-enum-validation-arch-04 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC4725
RFC4726 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering A. Farrel J.-P. Vasseur A. Ayyangar November 2006 ASCII 53076 22 mpls mpls-te te lsp label switched path

This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.

For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). This memo provides information for the Internet community.

draft-ietf-ccamp-inter-domain-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4726
RFC4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers B. Fenner November 2006 ASCII 19745 11

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK]

draft-fenner-iana-exp-2780-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4727
RFC4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 D. Johnson Y. Hu D. Maltz February 2007 ASCII 265706 107 route discovery route maintenance

The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and "Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network. All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness. Other advantages of the DSR protocol include easily guaranteed loop-free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-manet-dsr-10 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=4728 10.17487/RFC4728
RFC4729 A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum M. Abel November 2006 ASCII 13423 7 forum technical committee

This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) resources published by the Near Field Communication (NFC) Forum. The NFC Forum defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are provided by the NFC Forum Technical Committee. This memo provides information for the Internet community.

draft-abel-nfc-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4729
RFC4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) E. Burger M. Dolly November 2006 ASCII 120186 56 ua user agent dtmf dual tone multi-frequency

This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). [STANDARDS-TRACK]

draft-ietf-sipping-kpml-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4730 10.17487/RFC4730
RFC4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned A. Melnikov D. Cridland November 2006 ASCII 15431 6 uid search uid

This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. [STANDARDS-TRACK]

draft-melnikov-imap-search-ret-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4731
RFC4732 Internet Denial-of-Service Considerations M. Handley Editor E. Rescorla Editor IAB December 2006 ASCII 91844 38 dos

This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. This memo provides information for the Internet community.

draft-iab-dos-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4732
RFC4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals H. Schulzrinne T. Taylor December 2006 ASCII 115614 49 real-time application protocol DTMF dual-tone multifrequency

This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.

This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.

This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS-TRACK]

draft-ietf-avt-rfc2833bis-15 RFC2833 RFC4734 RFC5244 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4733 10.17487/RFC4733
RFC4734 Definition of Events for Modem, Fax, and Text Telephony Signals H. Schulzrinne T. Taylor December 2006 ASCII 116810 47 real-time application protocol DTMF dual-tone multifrequency

This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. [STANDARDS-TRACK]

draft-ietf-avt-rfc2833bisdata-08 RFC2833 RFC4733 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4734
RFC4735 Example Media Types for Use in Documentation T. Taylor October 2006 ASCII 9951 6 media type example

This document is registration for the 'example' media type and 'example' subtypes within the standards tree. The 'example/*' and '*/example' media types are defined for documentation purposes only. [STANDARDS-TRACK]

draft-taylor-types-example-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4735
RFC4736 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) JP. Vasseur Editor Y. Ikejiri R. Zhang November 2006 ASCII 28850 14 rsvp-te te lsp path

This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. This memo provides information for the Internet community.

draft-ietf-ccamp-loose-path-reopt-02 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4736
RFC4737 Packet Reordering Metrics A. Morton L. Ciavattone G. Ramachandran S. Shalunov J. Perser November 2006 ASCII 94699 45 ippm

This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included. An appendix gives extended definitions for evaluating order with packet fragmentation. [STANDARDS-TRACK]

draft-ietf-ippm-reordering-13 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC4737
RFC4738 MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) D. Ignjatic L. Dondeti F. Audet P. Lin November 2006 ASCII 43015 19 MIKEY SRTP key management group key distribution RSA-R

The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally a Diffie-Hellman key exchange. In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder. In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder's ID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members). This document updates RFC 3830 with the RSA-R mode. [STANDARDS-TRACK]

draft-ietf-msec-mikey-rsa-r-07 RFC3830 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4738
RFC4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol P. Eronen J. Korhonen November 2006 ASCII 22704 11

The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider. This memo defines an Experimental Protocol for the Internet community.

draft-eronen-ipsec-ikev2-multiple-auth-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4739
RFC4740 Diameter Session Initiation Protocol (SIP) Application M. Garcia-Martin Editor M. Belinchon M. Pallares-Lopez C. Canales-Valenzuela K. Tammi November 2006 ASCII 174175 72 authentication authorization diameter client

This document specifies the Diameter Session Initiation Protocol (SIP) application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-sip-app-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4740 10.17487/RFC4740
RFC4741 NETCONF Configuration Protocol R. Enns Editor December 2006 ASCII 173914 95 network configuration protocol network device xml extensible markup language rpc remote procedure call

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. [STANDARDS-TRACK]

draft-ietf-netconf-prot-12 RFC6241 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=4741 10.17487/RFC4741
RFC4742 Using the NETCONF Configuration Protocol over Secure SHell (SSH) M. Wasserman T. Goddard December 2006 ASCII 17807 10 network configuration protocol

This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. [STANDARDS-TRACK]

draft-ietf-netconf-ssh-06 RFC6242 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=4742 10.17487/RFC4742
RFC4743 Using NETCONF over the Simple Object Access Protocol (SOAP) T. Goddard December 2006 ASCII 39734 20 NETCONF XMLCONF SOAP device managment XML Extensible Markup Language

The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF. [STANDARDS-TRACK]

draft-ietf-netconf-soap-08 HISTORIC PROPOSED STANDARD IETF ops netconf 10.17487/RFC4743
RFC4744 Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) E. Lear K. Crozier December 2006 ASCII 19287 10 XML Configuration Network Management Extensible Markup Language

This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP). [STANDARDS-TRACK]

draft-ietf-netconf-beep-10 HISTORIC PROPOSED STANDARD IETF ops netconf 10.17487/RFC4744
RFC4745 Common Policy: A Document Format for Expressing Privacy Preferences H. Schulzrinne H. Tschofenig J. Morris J. Cuellar J. Polk J. Rosenberg February 2007 ASCII 63602 32 rules conditions permissions

This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains. [STANDARDS-TRACK]

draft-ietf-geopriv-common-policy-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4745 10.17487/RFC4745
RFC4746 Extensible Authentication Protocol (EAP) Password Authenticated Exchange T. Clancy W. Arbaugh November 2006 ASCII 63471 30 EAP-PAX password authenticated exchange key exchange

This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange. This memo provides information for the Internet community.

draft-clancy-eap-pax-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4746 10.17487/RFC4746
RFC4747 The Virtual Fabrics MIB S. Kipp G. Ramkumar K. McCloghrie November 2006 ASCII 39034 20 management information base T11-FC-VIRTUAL-FABRIC-MIB fibre channel network virtual fabric

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Virtual Fabrics function. [STANDARDS-TRACK]

draft-ietf-imss-fc-vf-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4747 10.17487/RFC4747
RFC4748 RFC 3978 Update to Recognize the IETF Trust S. Bradner Editor October 2006 ASCII 7284 4 ipr intellectual property rights copyright

This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of all IETF-related intellectual property rights.

This document does not constrain how the IETF Trust exercises those rights. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-ietf-trust-update-03 RFC5378 RFC3978 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC4748
RFC4749 RTP Payload Format for the G.729.1 Audio Codec A. Sollaud October 2006 ASCII 28838 14 real-time transport protocol itu-t international telecommunication union

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec. A media type registration is included for this payload format. [STANDARDS-TRACK]

draft-ietf-avt-rtp-g729-scal-wb-ext-07 RFC5459 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4749
RFC4750 OSPF Version 2 Management Information Base D. Joyal Editor P. Galecki Editor S. Giacalone Editor R. Coltun F. Baker December 2006 ASCII 222459 121 OSPF-MIB Open Shortest Path First SPF MIB routing network management mib OSPF-MIB OSPF-TRAP-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family.

This memo obsoletes RFC 1850; however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in Appendix B. [STANDARDS-TRACK]

draft-ietf-ospf-mib-update-11 RFC1850 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4750 10.17487/RFC4750
RFC4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism A. Melnikov Editor November 2006 ASCII 22133 10 SASL encryption protocol specific

The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface (GSS-API) Kerberos V5 in the SASL.

This document replaces Section 7.2 of RFC 2222, the definition of the "GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222. [STANDARDS-TRACK]

draft-ietf-sasl-gssapi-08 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl 10.17487/RFC4752
RFC4753 ECP Groups For IKE and IKEv2 D. Fu J. Solinas January 2007 ASCII 28760 16 elliptic curve Diffie-Hellman suite b nist curve

This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This memo provides information for the Internet community.

draft-ietf-ipsec-ike-ecp-groups-03 RFC5903 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4753 10.17487/RFC4753
RFC4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) D. Fu J. Solinas January 2007 ASCII 27948 15 suite b

This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods. This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. [STANDARDS-TRACK]

draft-ietf-ipsec-ike-auth-ecdsa-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4754
RFC4755 IP over InfiniBand: Connected Mode V. Kashyap December 2006 ASCII 26314 13

This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. [STANDARDS-TRACK]

draft-ietf-ipoib-connected-mode-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4755
RFC4756 Forward Error Correction Grouping Semantics in Session Description Protocol A. Li November 2006 ASCII 12743 6 fec sdp media lines

This document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) to group together "m" lines in the same session. [STANDARDS-TRACK]

draft-ietf-mmusic-fec-grouping-05 RFC5956 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4756
RFC4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows K. Jaganathan L. Zhu J. Brezak December 2006 ASCII 36562 18 md5 hmac

The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.

The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. This memo provides information for the Internet community.

draft-jaganathan-rc4-hmac-03 RFC6649 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4757 10.17487/RFC4757
RFC4758 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1 M. Nystroem November 2006 ASCII 110657 54 rsa laboratories one-time password specifications otps

This document constitutes Revision 1 of Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories' One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no "bits-on-the-wire" have changed, the protocol specified herein is compatible with CT-KIP Version 1.0.

CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself. This memo provides information for the Internet community.

draft-nystrom-ct-kip-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4758 10.17487/RFC4758
RFC4759 The ENUM Dip Indicator Parameter for the "tel" URI R. Stastny R. Shockey L. Conroy December 2006 ASCII 15062 8 DNS E.164 telephone number

This document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. [STANDARDS-TRACK]

draft-ietf-iptel-tel-enumdi-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4759
RFC4760 Multiprotocol Extensions for BGP-4 T. Bates R. Chandra D. Katz Y. Rekhter January 2007 ASCII 24542 12 MEXT-BGP4 border gateway protocol network layer protocols

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]

draft-ietf-idr-rfc2858bis-10 RFC2858 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4760 10.17487/RFC4760
RFC4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling K. Kompella Editor Y. Rekhter Editor January 2007 ASCII 65219 28 border gateway protocol transparent lan service virtual private switched network service provider

Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.

This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]

draft-ietf-l2vpn-vpls-bgp-08 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF int l2vpn 10.17487/RFC4761
RFC4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling M. Lasserre Editor V. Kompella Editor January 2007 ASCII 82778 31 land area network transparent lan service

This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.

This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK]

draft-ietf-l2vpn-vpls-ldp-09 PROPOSED STANDARD PROPOSED STANDARD IETF int l2vpn http://www.rfc-editor.org/errata_search.php?rfc=4762 10.17487/RFC4762
RFC4763 Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE) M. Vanderveen H. Soliman November 2006 ASCII 96027 46 IEEE 802.11i user anonymity

This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment (SAKE). This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748. The specification has passed Designated Expert review for this IANA assignment. This memo provides information for the Internet community.

draft-vanderveen-eap-sake-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4763 10.17487/RFC4763
RFC4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method F. Bersani H. Tschofenig January 2007 ASCII 133990 64 pre-shared key

This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. This memo defines an Experimental Protocol for the Internet community.

draft-bersani-eap-psk-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4764
RFC4765 The Intrusion Detection Message Exchange Format (IDMEF) H. Debar D. Curry B. Feinstein March 2007 ASCII 307966 157 intrusion detection security secure exchange intrusion IDS XML

The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.

This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-idwg-idmef-xml-16 EXPERIMENTAL EXPERIMENTAL IETF sec idwg 10.17487/RFC4765
RFC4766 Intrusion Detection Message Exchange Requirements M. Wood M. Erlinger March 2007 ASCII 50816 25 idmef idwg intrusion detection exchange format

The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. This memo provides information for the Internet community.

draft-ietf-idwg-requirements-10 INFORMATIONAL INFORMATIONAL IETF sec idwg 10.17487/RFC4766
RFC4767 The Intrusion Detection Exchange Protocol (IDXP) B. Feinstein G. Matthews March 2007 ASCII 56048 28 intrusion intrusion detection beep security ids security protocol secure protocol secure exchange idmef

This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in RFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-idwg-beep-idxp-07 EXPERIMENTAL EXPERIMENTAL IETF sec idwg 10.17487/RFC4767
RFC4768 Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming S. Hartman December 2006 ASCII 27205 12 acl access control list

The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. This memo provides information for the Internet community.

draft-ietf-kitten-gss-naming-05 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC4768
RFC4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information J. Livingood R. Shockey November 2006 ASCII 24945 13 tel uri uri scheme sip

This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. [STANDARDS-TRACK]

draft-ietf-enum-pstn-05 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4769
RFC4770 vCard Extensions for Instant Messaging (IM) C. Jennings J. Reschke Editor January 2007 ASCII 11077 7 impp instant messaging and presence protocol

This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. [STANDARDS-TRACK]

draft-jennings-impp-vcard-08 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4770
RFC4771 Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP) V. Lehtovirta M. Naslund K. Norrman January 2007 ASCII 27945 12 roc

This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. [STANDARDS-TRACK]

draft-lehtovirta-srtp-rcc-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4771 10.17487/RFC4771
RFC4772 Security Implications of Using the Data Encryption Standard (DES) S. Kelly December 2006 ASCII 68524 28

The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by the Advanced Encryption Standard (AES). Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use. This memo provides information for the Internet community.

draft-kelly-saag-des-implications-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4772
RFC4773 Administration of the IANA Special Purpose IPv6 Address Block G. Huston December 2006 ASCII 10580 5

This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry. This memo provides information for the Internet community.

draft-huston-ipv6-iana-specials-01 RFC6890 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4773
RFC4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field S. Floyd November 2006 ASCII 37144 15

There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-tsvwg-ecn-alternates-02 RFC6040 BCP0124 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC4774
RFC4775 Procedures for Protocol Extensions and Variations S. Bradner B. Carpenter Editor T. Narten December 2006 ASCII 32797 14 sdo standards development organization

This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.

This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-carpenter-protocol-extensions-04 BCP0125 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4775
RFC4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information H. Schulzrinne November 2006 ASCII 45495 19 lci local configuration information

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]

RFC4676 RFC5774 RFC6848 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC4776
RFC4777 IBM's iSeries Telnet Enhancements T. Murphy Jr. P. Rieth J. Stevens November 2006 ASCII 104243 47 midrange business computer telnet environment client server printer

This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allows Telnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, language support, auto-sign-on, response codes, session association, etc.

These support functions are implemented primarily using the Telnet Environment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server. This memo provides information for the Internet community.

draft-murphy-iser-telnet-04 RFC2877 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4777
RFC4778 Operational Security Current Practices in Internet Service Provider Environments M. Kaeo January 2007 ASCII 88344 37 isp

This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. This memo provides information for the Internet community.

draft-ietf-opsec-current-practices-07 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=4778 10.17487/RFC4778
RFC4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks S. Asadullah A. Ahmed C. Popoviciu P. Savola J. Palet January 2007 ASCII 188511 81 v6ops isp ipv6 deployment scenarios broadband networks

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today\'s Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6. This memo provides information for the Internet community.

draft-ietf-v6ops-bb-deployment-scenarios-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4779 10.17487/RFC4779
RFC4780 Management Information Base for the Session Initiation Protocol (SIP) K. Lingle J-F. Mule J. Maeng D. Walker April 2007 ASCII 160460 83 mib registrar services SIP-COMMON-MIB SIP-TC-MIB SIP-UA-MIB DEFINITIONS SIP-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. [STANDARDS-TRACK]

draft-ietf-sip-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4780
RFC4781 Graceful Restart Mechanism for BGP with MPLS Y. Rekhter R. Aggarwal January 2007 ASCII 23249 10 border gateway protocol multiprotocol label switching nlri bgp network layer reachability information

A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.

The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS-TRACK]

draft-ietf-mpls-bgp-mpls-restart-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4781
RFC4782 Quick-Start for TCP and IP S. Floyd M. Allman A. Jain P. Sarolahti January 2007 ASCII 214489 82

This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.

This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-quickstart-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4782 10.17487/RFC4782
RFC4783 GMPLS - Communication of Alarm Information L. Berger Editor December 2006 ASCII 42068 19 generalized multiprotocol label switching gmpls-rsvp

This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.

This document updates RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-alarm-spec-06 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4783 10.17487/RFC4783
RFC4784 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks C. Carroll F. Quick June 2007 ASCII 102856 45 mip cryptographic keys dmu

The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS Authentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA).

cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA). This memo provides information for the Internet community.

draft-carroll-dynmobileip-cdma-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4784
RFC4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) U. Blumenthal P. Goel January 2007 ASCII 9550 5 cipher suite

This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. [STANDARDS-TRACK]

draft-ietf-tls-psk-null-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4785
RFC4786 Operation of Anycast Services J. Abley K. Lindqvist December 2006 ASCII 56818 24 ROUTING LOAD-BALANCING LOAD-SHARING

As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.

Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grow-anycast-04 BCP0126 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC4786
RFC4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP F. Audet Editor C. Jennings January 2007 ASCII 68693 29 nat sip udp

This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-nat-udp-08 RFC6888 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC4787
RFC4788 Enhancements to RTP Payload Formats for EVRC Family Codecs Q. Xie R. Kapoor January 2007 ASCII 42216 22 enhanced variable rate codec real time transmission protocol evrc-b dtx discontinuous transmission

This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. [STANDARDS-TRACK]

draft-ietf-avt-compact-bundled-evrc-11 RFC3558 RFC5188 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4788
RFC4789 Simple Network Management Protocol (SNMP) over IEEE 802 Networks J. Schoenwaelder T. Jeffree November 2006 ASCII 17839 9

This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.

This document obsoletes RFC 1089. [STANDARDS-TRACK]

draft-schoenw-snmp-ether-02 RFC1089 RFC3417 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4789
RFC4790 Internet Application Protocol Collation Registry C. Newman M. Duerst A. Gulbrandsen March 2007 ASCII 55591 26 collation sorting

Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. [STANDARDS-TRACK]

draft-newman-i18n-comparator-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4790 10.17487/RFC4790
RFC4791 Calendaring Extensions to WebDAV (CalDAV) C. Daboo B. Desruisseaux L. Dusseault March 2007 ASCII 206801 107 calsched calsch calcav calendar calendaring scheduling webdav ical icalendar itip text/calendar http

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. [STANDARDS-TRACK]

draft-dusseault-caldav-15 RFC5689 RFC6638 RFC6764 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4791 10.17487/RFC4791
RFC4792 Encoding Instructions for the Generic String Encoding Rules (GSER) S. Legg January 2007 ASCII 17637 9 ASN.1

Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. [STANDARDS-TRACK]

draft-legg-ldap-gser-ei-02 RFC3641 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4792
RFC4793 The EAP Protected One-Time Password Protocol (EAP-POTP) M. Nystroem February 2007 ASCII 172575 82 otp extensible authentication protocol

This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2). This memo provides information for the Internet community.

draft-nystrom-eap-potp-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4793
RFC4794 RFC 1264 Is Obsolete B. Fenner December 2006 ASCII 7554 4

RFC 1264 was written during what was effectively a completely different time in the life of the Internet. It prescribed rules to protect the Internet against new routing protocols that may have various undesirable properties. In today's Internet, there are so many other pressures against deploying unreasonable protocols that we believe that existing controls suffice, and the RFC 1264 rules just get in the way. This memo provides information for the Internet community.

draft-fenner-obsolete-1264-03 RFC1264 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4794
RFC4795 Link-local Multicast Name Resolution (LLMNR) B. Aboba D. Thaler L. Esibov January 2007 ASCII 71969 31

The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. This memo provides information for the Internet community.

draft-ietf-dnsext-mdns-47 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4795 10.17487/RFC4795
RFC4796 The Session Description Protocol (SDP) Content Attribute J. Hautakorpi G. Camarillo February 2007 ASCII 22886 11 media attribute content

This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-media-content-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4796
RFC4797 Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks Y. Rekhter R. Bonica E. Rosen January 2007 ASCII 18985 10 L3VPN GRE encapsulation

This document describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE).

The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. This memo provides information for the Internet community.

draft-ietf-l3vpn-gre-ip-2547-05 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4797
RFC4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) J. De Clercq D. Ooms S. Prevost F. Le Faucheur February 2007 ASCII 31381 14 mp-bgp

This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS-TRACK]

draft-ooms-v6ops-bgp-tunnel-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4798
RFC4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management T. Nadeau Editor A. Farrel Editor February 2007 ASCII 16347 9 management information base mib GMPLS-TC-STD-MIB

This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-tc-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4801
RFC4802 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base T. Nadeau Editor A. Farrel Ed. February 2007 ASCII 118164 60 mib GMPLS-TE-STD-MIB IANA-GMPLS-TC-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS)-based traffic engineering. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-te-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4802
RFC4803 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base T. Nadeau Editor A. Farrel Editor February 2007 ASCII 79925 42 mib GMPLS-LSR-STD-MIB GMPLS-LABEL-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-lsr-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4803 10.17487/RFC4803
RFC4804 Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels F. Le Faucheur Editor February 2007 ASCII 69473 31 multiprotocol label switching traffic engineering diffserv-aware mpls traffic engineering

RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-dste-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4804 10.17487/RFC4804
RFC4805 Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types O. Nicklass Editor March 2007 ASCII 189927 94 mib management information base DS1-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, J1, E1, DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types.

This document obsoletes RFC 3895. [STANDARDS-TRACK]

draft-orly-atommib-rfc3895bis-01 RFC3895 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4805
RFC4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2 M. Myers H. Tschofenig February 2007 ASCII 21991 11 internet key exchange version 2

While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.

When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. [STANDARDS-TRACK]

draft-myers-ikev2-ocsp-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4806
RFC4807 IPsec Security Policy Database Configuration MIB M. Baer R. Charlet W. Hardaker R. Story C. Wang March 2007 ASCII 136747 71 management information base IPSEC-SPD-MIB

This document defines a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol. The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. [STANDARDS-TRACK]

draft-ietf-ipsp-spd-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4807 10.17487/RFC4807
RFC4808 Key Change Strategies for TCP-MD5 S. Bellovin March 2007 ASCII 14939 8 bgp border gateway protocol

The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. This memo provides information for the Internet community.

draft-bellovin-keyroll2385-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4808
RFC4809 Requirements for an IPsec Certificate Management Profile C. Bonatti Editor S. Turner Editor G. Lebovitz Editor February 2007 ASCII 98400 45 internet protocol security

This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed to meet the needs of enterprise-scale IPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements. This memo provides information for the Internet community.

draft-ietf-pki4ipsec-mgmt-profile-rqts-07 INFORMATIONAL INFORMATIONAL IETF sec pki4ipsec 10.17487/RFC4809
RFC4810 Long-Term Archive Service Requirements C. Wallace U. Pordesch R. Brandner March 2007 ASCII 35690 17 data integrity digital signatures

There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. This memo provides information for the Internet community.

draft-ietf-ltans-reqs-10 INFORMATIONAL INFORMATIONAL IETF sec ltans 10.17487/RFC4810
RFC4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization L. Nguyen A. Roy A. Zinin March 2007 ASCII 18976 10 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.

This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.

draft-nguyen-ospf-oob-resync-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4811
RFC4812 OSPF Restart Signaling L. Nguyen A. Roy A. Zinin March 2007 ASCII 12111 7 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via the Hello subprotocol. Hello OSPF packets are also used to ensure two-way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a Hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions.

This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.

draft-nguyen-ospf-restart-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4812 10.17487/RFC4812
RFC4813 OSPF Link-Local Signaling B. Friedman L. Nguyen A. Roy D. Yeung A. Zinin March 2007 ASCII 19687 10 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This memo defines an Experimental Protocol for the Internet community.

draft-nguyen-ospf-lls-06 RFC5613 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4813
RFC4814 Hash and Stuffing: Overlooked Factors in Network Device Benchmarking D. Newman T. Player March 2007 ASCII 59272 26 bmwg benchmarking testing bit-stuffing byte-stuffing

Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. This memo provides information for the Internet community.

draft-ietf-bmwg-hash-stuffing-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4814
RFC4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 L-E. Jonsson K. Sandlund G. Pelletier P. Kremer February 2007 ASCII 74819 33 ip udp user datagram protocol rtp realtime transport protocol esp encapsulation security payload

RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided. [STANDARDS-TRACK]

draft-ietf-rohc-rtp-impl-guide-22 RFC3095 RFC3241 RFC3843 RFC4019 RFC4362 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4815
RFC4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service A. Malis L. Martini J. Brayley T. Walsh February 2007 ASCII 10269 5

The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation. [STANDARDS-TRACK]

draft-ietf-pwe3-cell-transport-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4816
RFC4817 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 M. Townsley C. Pignataro S. Wainner T. Seely J. Young March 2007 ASCII 26538 12 l2tpv3 multiprotocol label switching label stack label stack

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead. [STANDARDS-TRACK]

draft-ietf-mpls-over-l2tpv3-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4817
RFC4818 RADIUS Delegated-IPv6-Prefix Attribute J. Salowey R. Droms April 2007 ASCII 12993 7 remote authentication dial in user service diameter

This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. [STANDARDS-TRACK]

draft-ietf-radext-delegated-prefix-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4818
RFC4819 Secure Shell Public Key Subsystem J. Galbraith J. Van Dyke J. Bright March 2007 ASCII 32794 17 ssh ssh2

Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.

The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.

A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS-TRACK]

draft-ietf-secsh-publickey-subsystem-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4819
RFC4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) M. Tuexen R. Stewart P. Lei March 2007 ASCII 11597 6

This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size. The padding parameter is used to pad an SCTP INIT chunk to an arbitrary size. [STANDARDS-TRACK]

draft-ietf-tsvwg-sctp-padding-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4820 10.17487/RFC4820
RFC4821 Packetization Layer Path MTU Discovery M. Mathis J. Heffner March 2007 ASCII 75665 32 maximum transmission unit pmtud

This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]

draft-ietf-pmtud-method-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pmtud http://www.rfc-editor.org/errata_search.php?rfc=4821 10.17487/RFC4821
RFC4822 RIPv2 Cryptographic Authentication R. Atkinson M. Fanto February 2007 ASCII 53828 22 RIP2-MD5 Routing Information Protocol Encryption

This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section. [STANDARDS-TRACK]

draft-rja-ripv2-auth-06 RFC2082 RFC2453 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4822
RFC4823 FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet T. Harding R. Scott April 2007 ASCII 80992 40 applicability statement as business-to-business

This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. This memo provides information for the Internet community.

draft-ietf-ediint-as3-04 INFORMATIONAL INFORMATIONAL IETF app ediint http://www.rfc-editor.org/errata_search.php?rfc=4823 10.17487/RFC4823
RFC4824 The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS) J. Hofmueller Editor A. Bachmann Editor IO. zmoelnig Editor April 1 2007 ASCII 25521 13 internet protocol april fools

This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4824 10.17487/RFC4824
RFC4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) J. Rosenberg May 2007 ASCII 166627 71 sip xml http rest buddy list simple presence data manipulation

This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. [STANDARDS-TRACK]

draft-ietf-simple-xcap-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4825
RFC4826 Extensible Markup Language (XML) Formats for Representing Resource Lists J. Rosenberg May 2007 ASCII 68850 31 http sip xml rest buddy list simple presence data manipulation

In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). [STANDARDS-TRACK]

draft-ietf-simple-xcap-list-usage-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4826 10.17487/RFC4826
RFC4827 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents M. Isomaki E. Leppanen May 2007 ASCII 22896 11 PIDF AUID hard state PUBLISH SIP Presence SIMPLE pidf-manipulation XCAP application usage

This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. [STANDARDS-TRACK]

draft-ietf-simple-xcap-pidf-manipulation-usage-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4827
RFC4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant S. Floyd E. Kohler April 2007 ASCII 116808 46 transmission control protocol

This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.

TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.

Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dccp-tfrc-voip-07 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4828 10.17487/RFC4828
RFC4829 Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering J. de Oliveira Editor JP. Vasseur Editor L. Chen C. Scoglio April 2007 ASCII 43892 19 traffic engineering label switched path te lsp multiprotocol label switching protocol

When the establishment of a higher priority (Traffic Engineering Label Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select which TE LSPs will be preempted. The preempted LSPs are then rerouted by their respective \%Head-end Label Switch Router (LSR). This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TE LSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included. This memo provides information for the Internet community.

draft-deoliveira-diff-te-preemption-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4829
RFC4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM) J. Kempf Editor April 2007 ASCII 29815 13

Localized mobility management is a well-understood concept in the IETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management. This memo provides information for the Internet community.

draft-ietf-netlmm-nohost-ps-05 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4830
RFC4831 Goals for Network-Based Localized Mobility Management (NETLMM) J. Kempf Editor April 2007 ASCII 35232 14

In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed. This memo provides information for the Internet community.

draft-ietf-netlmm-nohost-req-05 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4831
RFC4832 Security Threats to Network-Based Localized Mobility Management (NETLMM) C. Vogt J. Kempf April 2007 ASCII 31467 12 localized mobility anchor mobile access gateway compromise impersonation man in the middle denial of service IP spoofing

This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself. This memo provides information for the Internet community.

draft-ietf-netlmm-threats-04 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4832
RFC4833 Timezone Options for DHCP E. Lear P. Eggert April 2007 ASCII 19573 10 time offset posix tz database tz

Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifies DHCP options for each of those methods. The DHCPv4 time offset option is deprecated. [STANDARDS-TRACK]

draft-ietf-dhc-timezone-option-05 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4833
RFC4834 Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) T. Morin Editor April 2007 ASCII 80341 37 vpn virtual private networks l3

This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. This memo provides information for the Internet community.

draft-ietf-l3vpn-ppvpn-mcast-reqts-10 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4834
RFC4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) V. Manral April 2007 ASCII 21492 10 ESP ipsec authentication mechanism header security architecture payload internet protocol encapsulating ipv4 ipv6

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

draft-manral-ipsec-rfc4305-bis-errata-03 RFC4305 RFC7321 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4835
RFC4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) E. Beili April 2007 ASCII 151012 67 MAU-MIB IANA-MAU-MIB management information base,

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This document obsoletes RFC 3636. It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. [STANDARDS-TRACK]

draft-ietf-hubmib-rfc3636bis-05 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib http://www.rfc-editor.org/errata_search.php?rfc=4836 10.17487/RFC4836
RFC4837 Managed Objects of Ethernet Passive Optical Networks (EPON) L. Khermosh July 2007 ASCII 206726 91 Ethernet Passive Optical Networks pon epon IEEE802.3ah 802.3ah p2mp mpcp llid onu olt optical access

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets. In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. [STANDARDS-TRACK]

draft-ietf-hubmib-efm-epon-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC4837
RFC4838 Delay-Tolerant Networking Architecture V. Cerf S. Burleigh A. Hooke L. Torgerson R. Durst K. Scott K. Fall H. Weiss April 2007 ASCII 89265 35 disruption tolerant irtf interplanetary internet

This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community.

draft-irtf-dtnrg-arch-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC4838
RFC4839 Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) G. Conboy J. Rivlin J. Ferraiolo April 2007 ASCII 7851 5

This document serves to register a media type for the Open eBook Publication Structure (OEBPS) Package Files. This memo provides information for the Internet community.

draft-conboy-mime-opf-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4839
RFC4840 Multiple Encapsulation Methods Considered Harmful B. Aboba Editor E. Davies D. Thaler April 2007 ASCII 65287 27 iab link-layer protocol ip encapsulation internet protocol encapsulation

This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods. This memo provides information for the Internet community.

draft-iab-link-encaps-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4840
RFC4841 RFC 4181 Update to Recognize the IETF Trust C. Heard Editor March 2007 ASCII 4414 3 management information base standards-track specifications mib review

This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-heard-rfc4181-update-00 RFC4181 BCP0111 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4841
RFC4842 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) A. Malis P. Pate R. Cohen Editor D. Zelig April 2007 ASCII 96719 43 multiprotocol label switching

This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK]

draft-ietf-pwe3-sonet-14 RFC5143 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4842 10.17487/RFC4842
RFC4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) P. Nikander J. Laganier F. Dupont April 2007 ASCII 32483 14

This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.

This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.

draft-laganier-ipv6-khi-07 RFC7343 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4843
RFC4844 The RFC Series and RFC Editor L. Daigle Editor Internet Architecture Board July 2007 ASCII 38752 20 technical publisher

This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This memo provides information for the Internet community.

draft-iab-rfc-editor-04 RFC5741 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4844
RFC4845 Process for Publication of IAB RFCs L. Daigle Editor Internet Architecture Board July 2007 ASCII 9228 5

From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series. This memo provides information for the Internet community.

draft-iab-publication-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4845
RFC4846 Independent Submissions to the RFC Editor J. Klensin Editor D. Thaler Editor July 2007 ASCII 36562 16

There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. This memo provides information for the Internet community.

draft-iab-rfc-independent-00 RFC5744 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4846
RFC4847 Framework and Requirements for Layer 1 Virtual Private Networks T. Takeda Editor April 2007 ASCII 85807 38 L1VPN

This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.

The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. This memo provides information for the Internet community.

draft-ietf-l1vpn-framework-05 INFORMATIONAL INFORMATIONAL IETF rtg l1vpn 10.17487/RFC4847
RFC4848 Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) L. Daigle April 2007 ASCII 19341 10 service-parms service parameters

The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK]

draft-daigle-unaptr-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4848 10.17487/RFC4848
RFC4849 RADIUS Filter Rule Attribute P. Congdon M. Sanchez B. Aboba April 2007 ASCII 18162 9 remote authentication dial in user service nas-filter-rule

While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. [STANDARDS-TRACK]

draft-ietf-radext-filter-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4849
RFC4850 Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture D. Wysochanski April 2007 ASCII 16430 9 transport protocol tcp transmission control protocol

The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-nodearch-key-03 RFC7143 RFC3720 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4850
RFC4851 The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) N. Cam-Winget D. McGrew J. Salowey H. Zhou May 2007 ASCII 131460 64 eap

This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. This memo provides information for the Internet community.

draft-cam-winget-eap-fast-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4851 10.17487/RFC4851
RFC4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus J. Bound Y. Pouffary S. Klynsma T. Chown D. Green April 2007 ASCII 76199 32 internet protocol version 6 notational network

This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network. This memo provides information for the Internet community.

draft-ietf-v6ops-ent-analysis-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4852 10.17487/RFC4852
RFC4853 Cryptographic Message Syntax (CMS) Multiple Signer Clarification R. Housley April 2007 ASCII 10146 5 signeddata digitally sign authenticate encrypt arbitrary message content

This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. [STANDARDS-TRACK]

draft-ietf-smime-cms-mult-sign-03 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4853 10.17487/RFC4853
RFC4854 A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre April 2007 ASCII 15911 9 Extensible Messaging and Presence Protocol XMPP Jabber Instant Messaging Presence Uniform Resource Name URN

This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging and Presence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF). This memo provides information for the Internet community.

draft-saintandre-xmpp-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4854
RFC4855 Media Type Registration of RTP Payload Formats S. Casner February 2007 ASCII 24404 11 realtime transport protocol multipurpose internet mail extensions

This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. [STANDARDS-TRACK]

draft-ietf-avt-rfc3555bis-05 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4855
RFC4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences S. Casner February 2007 ASCII 45881 29 realtime transport protocol multipurpose internet mail extensions

This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]

draft-ietf-avt-rfc3555bis-part2-02 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4856 10.17487/RFC4856
RFC4857 Mobile IPv4 Regional Registration E. Fogelstroem A. Jonsson C. Perkins June 2007 ASCII 79939 35 GFA gateway foreign agent

Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mip4-reg-tunnel-04 EXPERIMENTAL EXPERIMENTAL IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4857 10.17487/RFC4857
RFC4858 Document Shepherding from Working Group Last Call to Publication H. Levkowetz D. Meyer L. Eggert A. Mankin May 2007 ASCII 48572 21 document shepherding ietf documents

This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. This memo provides information for the Internet community.

draft-ietf-proto-wgchair-doc-shepherding-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4858
RFC4859 Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object A. Farrel April 2007 ASCII 7511 5

This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaling messages used in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling. This memo provides information for the Internet community.

draft-ietf-mpls-iana-rsvp-session-flags-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4859
RFC4860 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations F. Le Faucheur B. Davie P. Bose C. Christou M. Davenport May 2007 ASCII 73010 32 session object session of interest phb per hop behavior

RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-ipsec-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4860
RFC4861 Neighbor Discovery for IP version 6 (IPv6) T. Narten E. Nordmark W. Simpson H. Soliman September 2007 ASCII 235106 97 IPV6-ND internet protocol link-layer link-layer address

This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]

draft-ietf-ipv6-2461bis-11 RFC2461 RFC5942 RFC6980 RFC7048 RFC7527 RFC7559 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4861 10.17487/RFC4861
RFC4862 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten T. Jinmei September 2007 ASCII 72482 30 IPV6-AUTO host link-local internet protocol version 6 link-local address duplicate address detection

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2462bis-08 RFC2462 RFC7527 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4862 10.17487/RFC4862
RFC4863 Wildcard Pseudowire Type L. Martini G. Swallow May 2007 ASCII 11321 6 pw type pw

Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these two LSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need. [STANDARDS-TRACK]

draft-ietf-pwe3-wildcard-pw-type-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4863
RFC4864 Local Network Protection for IPv6 G. Van de Velde T. Hain R. Droms B. Carpenter E. Klein May 2007 ASCII 95448 36 ipv6 address protection nat

Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. This memo provides information for the Internet community.

draft-ietf-v6ops-nap-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4864
RFC4865 SMTP Submission Service Extension for Future Message Release G. White G. Vaudreuil May 2007 ASCII 21495 11 simple mail transfer protocol future-release-integer

This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS-TRACK]

draft-vaudreuil-futuredelivery-04 RFC3463 RFC3464 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4865 10.17487/RFC4865
RFC4866 Enhanced Route Optimization for Mobile IPv6 J. Arkko C. Vogt W. Haddad May 2007 ASCII 145757 54 mobility cryptographically generated addresses cga credit-based authorization cba

This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. [STANDARDS-TRACK]

draft-ietf-mipshop-cga-cba-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=4866 10.17487/RFC4866
RFC4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs J. Sjoberg M. Westerlund A. Lakaniemi Q. Xie April 2007 ASCII 139584 59 interoperate applications

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. [STANDARDS-TRACK]

draft-ietf-avt-rtp-amr-bis-06 RFC3267 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4867 10.17487/RFC4867
RFC4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec S. Kelly S. Frankel May 2007 ASCII 41432 21 hashed authentication mode data authentication integrity verification

This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK]

draft-kelly-ipsec-ciph-sha2-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4868 10.17487/RFC4868
RFC4869 Suite B Cryptographic Suites for IPsec L. Law J. Solinas May 2007 ASCII 17043 9 ui suites user interface suites elliptic curve ike

This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This memo provides information for the Internet community.

draft-solinas-ui-suites-01 RFC6379 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4869
RFC4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) M. Delany May 2007 ASCII 87378 41

"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.

This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.

Proof and protection of email identity may assist in the global control of "spam" and "phishing". This memo defines a Historic Document for the Internet community.

draft-delany-domainkeys-base-06 RFC4871 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC4870
RFC4871 DomainKeys Identified Mail (DKIM) Signatures E. Allman J. Callas M. Delany M. Libbey J. Fenton M. Thomas May 2007 ASCII 166054 71 internet mail authentication spam phishing spoofing digital signature

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". [STANDARDS-TRACK]

draft-ietf-dkim-base-10 RFC4870 RFC6376 RFC5672 PROPOSED STANDARD PROPOSED STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=4871 10.17487/RFC4871
RFC4872 RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery J.P. Lang Editor Y. Rekhter Editor D. Papadimitriou Editor May 2007 ASCII 111882 47 resource reservation protocol traffic engineering

This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04 RFC3471 RFC4873 RFC6780 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4872 10.17487/RFC4872
RFC4873 GMPLS Segment Recovery L. Berger I. Bryskin D. Papadimitriou A. Farrel May 2007 ASCII 56919 25 generalized multipoint label switching rsvp-te resource reservation protocol traffic engineering NOTIFY_REQUEST

This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-segment-recovery-03 RFC3473 RFC4872 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4873 10.17487/RFC4873
RFC4874 Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) CY. Lee A. Farrel S. De Cnodder April 2007 ASCII 59569 27 srlg shared risk link groups

This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE).

The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.

In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document. [STANDARDS-TRACK]

draft-ietf-ccamp-rsvp-te-exclude-route-06 RFC3209 RFC3473 RFC6001 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4874 10.17487/RFC4874
RFC4875 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) R. Aggarwal Editor D. Papadimitriou Editor S. Yasukawa Editor May 2007 ASCII 125394 53 p2mp point-to-multipoint traffic engineering

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.

There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-te-p2mp-07 RFC6510 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4875 10.17487/RFC4875
RFC4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents B. Neal-Joslin Editor L. Howard M. Ansari May 2007 ASCII 73468 39 ldap schema profile configuration nameservice nss pam_ldap nss_ldap rfc2307 rfc 2307

This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support. In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. This memo provides information for the Internet community.

draft-joslin-config-schema-17 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4876 10.17487/RFC4876
RFC4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture V. Devarapalli F. Dupont April 2007 ASCII 57941 26 Bootstrapping MIP6 Selector Granularity Mobility Header EAP Authentication

This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS-TRACK]

draft-ietf-mip6-ikev2-ipsec-08 RFC3776 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4877 10.17487/RFC4877
RFC4878 Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces M. Squire June 2007 ASCII 130067 58 efm ethernet in the first mile snmp DOT3-OAM-MIB

This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to the Simple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those link OAM functions and for providing results and status of the OAM functions to management entities. [STANDARDS-TRACK]

draft-ietf-hubmib-efm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC4878
RFC4879 Clarification of the Third Party Disclosure Procedure in RFC 3979 T. Narten April 2007 ASCII 5570 4 ipr copyright

This document clarifies and updates a single sentence in RFC 3979. Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-narten-ipr-3979-3rd-party-fix-00 RFC3979 BCP0079 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC4879
RFC4880 OpenPGP Message Format J. Callas L. Donnerhacke H. Finney D. Shaw R. Thayer November 2007 ASCII 203706 90 public-key cryptography symmetric cryptography

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.

OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]

draft-ietf-openpgp-rfc2440bis-22 RFC1991 RFC2440 RFC5581 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp http://www.rfc-editor.org/errata_search.php?rfc=4880 10.17487/RFC4880
RFC4881 Low-Latency Handoffs in Mobile IPv4 K. El Malki Editor June 2007 ASCII 151124 64 mip4

Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mobileip-lowlatency-handoffs-v4-11 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC4881
RFC4882 IP Address Location Privacy and Mobile IPv6: Problem Statement R. Koodli May 2007 ASCII 24987 11 internet protocol home address care-of address

In this document, we discuss location privacy as applicable to Mobile IPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent. This memo provides information for the Internet community.

draft-ietf-mip6-location-privacy-ps-06 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4882
RFC4883 Benchmarking Terminology for Resource Reservation Capable Routers G. Feher K. Nemeth A. Korn I. Cselenyi July 2007 ASCII 54205 24 intserv integrated services benchmarking methodologies

The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services (IntServ) IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. This memo provides information for the Internet community.

draft-ietf-bmwg-benchres-term-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4883
RFC4884 Extended ICMP to Support Multi-Part Messages R. Bonica D. Gan D. Tappan C. Pignataro April 2007 ASCII 42169 19 internet control message protocol length attribute

This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.

Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.

This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field.

The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.

This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]

draft-bonica-internet-icmp-16 RFC0792 RFC4443 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4884 10.17487/RFC4884
RFC4885 Network Mobility Support Terminology T. Ernst H-Y. Lach July 2007 ASCII 37967 19 nemo

This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements. This memo provides information for the Internet community.

draft-ietf-nemo-terminology-06 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4885 10.17487/RFC4885
RFC4886 Network Mobility Support Goals and Requirements T. Ernst July 2007 ASCII 29083 13 nemo

Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. This memo provides information for the Internet community.

draft-ietf-nemo-requirements-06 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4886 10.17487/RFC4886
RFC4887 Network Mobility Home Network Models P. Thubert R. Wakikawa V. Devarapalli July 2007 ASCII 40372 19 nemo mobile routers

This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists. This memo provides information for the Internet community.

draft-ietf-nemo-home-network-models-06 INFORMATIONAL INFORMATIONAL IETF int nemo 10.17487/RFC4887
RFC4888 Network Mobility Route Optimization Problem Statement C. Ng P. Thubert M. Watari F. Zhao July 2007 ASCII 56756 26 nemo

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO. This memo provides information for the Internet community.

draft-ietf-nemo-ro-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4888 10.17487/RFC4888
RFC4889 Network Mobility Route Optimization Solution Space Analysis C. Ng F. Zhao M. Watari P. Thubert July 2007 ASCII 95880 38 nemo mrha mobile router and home agent ro

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. This memo provides information for the Internet community.

draft-ietf-nemo-ro-space-analysis-03 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4889 10.17487/RFC4889
RFC4890 Recommendations for Filtering ICMPv6 Messages in Firewalls E. Davies J. Mohacsi May 2007 ASCII 83479 38 Internet Control Message Protocol version 6 ipv6 security filter firewall icmpv6

In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.

This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks. This memo provides information for the Internet community.

draft-ietf-v6ops-icmpv6-filtering-recs-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4890 10.17487/RFC4890
RFC4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels R. Graveman M. Parthasarathy P. Savola H. Tschofenig May 2007 ASCII 46635 23 internet protocol internet protocol security ip security

This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework. This memo provides information for the Internet community.

draft-ietf-v6ops-ipsec-tunnels-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4891
RFC4892 Requirements for a Mechanism Identifying a Name Server Instance S. Woolf D. Conrad June 2007 ASCII 17605 8 domain name service dns name server

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism. This memo provides information for the Internet community.

draft-ietf-dnsop-serverid-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4892
RFC4893 BGP Support for Four-octet AS Number Space Q. Vohra E. Chen May 2007 ASCII 21520 10 autonomous system border gateway protocol

Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. [STANDARDS-TRACK]

draft-ietf-idr-as4bytes-13 RFC6793 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4893
RFC4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec P. Hoffman May 2007 ASCII 22899 11 md5 pkix certificates

This document describes how the IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms. This memo provides information for the Internet community.

draft-hoffman-ike-ipsec-hash-use-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4894
RFC4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) M. Tuexen R. Stewart P. Lei E. Rescorla August 2007 ASCII 42507 19 chunk type shared keys RANDOM CHUNKS HMAC-ALGO

This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. [STANDARDS-TRACK]

draft-ietf-tsvwg-sctp-auth-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4895 10.17487/RFC4895
RFC4896 Signaling Compression (SigComp) Corrections and Clarifications A. Surtees M. West A.B. Roach June 2007 ASCII 58435 28 sip session initiation protocol udvm universal decompressor virtual machine algorithm

This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485. [STANDARDS-TRACK]

draft-ietf-rohc-sigcomp-impl-guide-10 RFC3320 RFC3321 RFC3485 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4896
RFC4897 Handling Normative References to Standards-Track Documents J. Klensin S. Hartman June 2007 ASCII 13023 6

The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed on a way to bypass this rule with RFC 3967. This document describes a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, namely "note and move on". The procedure in RFC 3967 still applies for downward references to other classes of documents. In both cases, annotations should be added to such References. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klensin-norm-ref-04 RFC3967 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4897 10.17487/RFC4897
RFC4898 TCP Extended Statistics MIB M. Mathis J. Heffner R. Raghunarayan May 2007 ASCII 153768 75 transmission control protocol management information base TCP-ESTATS-MIB

This document describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. [STANDARDS-TRACK]

draft-ietf-tsvwg-tcp-mib-extension-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4898
RFC4901 Protocol Extensions for Header Compression over MPLS J. Ash Editor J. Hand Editor A. Malis Editor June 2007 ASCII 78801 34 multiprotocol label switching hc

This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP. This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to-point link. [STANDARDS-TRACK]

draft-ietf-avt-hc-over-mpls-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4901
RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP M. Stecher May 2007 ASCII 30120 14

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the "SMTP adaptation with OPES" document.

The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date. This memo provides information for the Internet community.

draft-ietf-opes-smtp-security-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC4902
RFC4903 Multi-Link Subnet Issues D. Thaler June 2007 ASCII 39671 17

There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach. This memo provides information for the Internet community.

draft-iab-multilink-subnet-issues-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4903
RFC4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs) V. Gurbani C. Jennings June 2007 ASCII 41027 19 SIP TEL Trunk group trunkgroup PSTN

This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose. [STANDARDS-TRACK]

draft-ietf-iptel-trunk-group-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4904
RFC4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks L. Martini Editor E. Rosen Editor N. El-Aawar Editor June 2007 ASCII 40020 20 multiprotocol label switching pdu protocol data unit draft-martini

This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM), or Ethernet for transport across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community.

draft-martini-l2circuit-encap-mpls-12 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4905 10.17487/RFC4905
RFC4906 Transport of Layer 2 Frames Over MPLS L. Martini Editor E. Rosen Editor N. El-Aawar Editor June 2007 ASCII 47403 22 multiprotocol label switching pdu protocol data unit sonet synchronized optical network

This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community.

draft-martini-l2circuit-trans-mpls-19 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4906 10.17487/RFC4906
RFC4907 Architectural Implications of Link Indications B. Aboba Editor June 2007 ASCII 160604 62

A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications. This memo provides information for the Internet community.

draft-iab-link-indications-10 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4907 10.17487/RFC4907
RFC4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO K. Nagami S. Uda N. Ogashiwa H. Esaki R. Wakikawa H. Ohnishi June 2007 ASCII 20230 10 care-of addresses

Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care-of Addresses (CoAs) can be used. In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy. This memo defines an Experimental Protocol for the Internet community.

draft-nagami-mip6-nemo-multihome-fixed-network-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4908
RFC4909 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport L. Dondeti Editor D. Castleford F. Hartung June 2007 ASCII 12228 7 short-term key message long-term key message oma bac browser and content broadcast

This document specifies a new Multimedia Internet KEYing (MIKEY) General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast (BCAST) group's Service and Content protection specification. This memo provides information for the Internet community.

draft-dondeti-msec-mikey-genext-oma-04 RFC5410 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4909 10.17487/RFC4909
RFC4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1) S. Legg D. Prager July 2007 ASCII 182175 80 extensible markup language canonical rxer crxer

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined. This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-rxer-07 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4910
RFC4911 Encoding Instructions for the Robust XML Encoding Rules (RXER) S. Legg July 2007 ASCII 178977 91 extensible markup language asn.1 abstract syntax notation one robust xml encoding rules rxer canonical robust xml encoding rules crxer asn.x

This document defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined. This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-rxer-ei-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4911
RFC4912 Abstract Syntax Notation X (ASN.X) S. Legg July 2007 ASCII 325190 165 extensible markup language asn.1 abstract syntax notation one robust xml encoding rules rxer

Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents. This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-asd-07 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4912
RFC4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER) S. Legg July 2007 ASCII 17194 9 extensible markup language

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER). This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-asd-gserei-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4913
RFC4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER) S. Legg July 2007 ASCII 71526 38 extensible markup language

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER). This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-asd-xerei-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4914
RFC4915 Multi-Topology (MT) Routing in OSPF P. Psenak S. Mirtorabi A. Roy L. Nguyen P. Pillay-Esnault June 2007 ASCII 43115 20 open shortest path first

This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.

An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]

draft-ietf-ospf-mt-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4915
RFC4916 Connected Identity in the Session Initiation Protocol (SIP) J. Elwell June 2007 ASCII 42924 24 user agent ua application-layer application layer multimedia multicast unicast

This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). [STANDARDS-TRACK]

draft-ietf-sip-connected-identity-05 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4916
RFC4917 Mobile IPv4 Message String Extension V. Sastry K. Leung A. Patel June 2007 ASCII 13302 7 home agent foreign agent registration reply

This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node. [STANDARDS-TRACK]

draft-ietf-mip4-message-string-ext-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC4917
RFC4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) L. Dusseault Editor June 2007 ASCII 276352 127 WEBDAV hypertext transfer protocol web content

Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).

RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS-TRACK]

draft-ietf-webdav-rfc2518bis-18 RFC2518 RFC5689 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=4918 10.17487/RFC4918
RFC4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals N. Kushalnagar G. Montenegro C. Schumacher August 2007 ASCII 27650 12 ieee 802.15.4

This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community.

draft-ietf-6lowpan-problem-08 INFORMATIONAL INFORMATIONAL IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=4919 10.17487/RFC4919
RFC4920 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE A. Farrel Editor A. Satyanarayana A. Iwata N. Fujita G. Ash July 2007 ASCII 88679 38 multiprotocol label switching generalized multiprotocol label switching traffic engineered te lsp label switched path

In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.

This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK]

draft-ietf-ccamp-crankback-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4920 10.17487/RFC4920
RFC4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network F. Baker P. Bose August 2007 ASCII 92632 38 vpn nested vpn integrated services

Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over Diffserv networks as described in RFC 2998. This memo provides information for the Internet community.

draft-ietf-tsvwg-vpn-signaled-preemption-02 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4923
RFC4924 Reflections on Internet Transparency B. Aboba Editor E. Davies July 2007 ASCII 35040 15

This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts. This memo provides information for the Internet community.

draft-iab-net-transparent-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4924
RFC4925 Softwire Problem Statement X. Li Editor S. Dawkins Editor D. Ward Editor A. Durand Editor July 2007 ASCII 49299 23

This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope. This memo provides information for the Internet community.

draft-ietf-softwire-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC4925
RFC4926 A URN Namespace for GEANT T.Kalin M.Molina July 2007 ASCII 16672 9 uniform resource name dante

This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing European Research and academic networks, for naming persistent resources defined by GEANT, the Consortium of European Academic and Research Networks, its projects, activities, working groups, and other designated subordinates. This memo provides information for the Internet community.

draft-kalin-geant-urn-namespace-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4926
RFC4927 Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering J.-L. Le Roux Editor June 2007 ASCII 25016 12 gmpls te-lsp traffic engineered label switched path pce path computation element

For scalability purposes, a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area Traffic Engineered Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths. The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol. This memo provides information for the Internet community.

draft-ietf-pce-pcecp-interarea-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4927
RFC4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks G. Swallow S. Bryant L. Andersson June 2007 ASCII 18376 8 ecmp

This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mpls-ecmp-bcp-03 RFC7274 BCP0128 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4928 10.17487/RFC4928
RFC4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures L. Andersson Editor A. Farrel Editor June 2007 ASCII 56742 23

This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-andersson-rtg-gmpls-change-08 BCP0129 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4929
RFC4930 Extensible Provisioning Protocol (EPP) S. Hollenbeck May 2007 ASCII 135648 72 shared framework mapping

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3730bis-04 RFC3730 RFC5730 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4930
RFC4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck May 2007 ASCII 88729 46 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 3731. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3731bis-05 RFC3731 RFC5731 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4931
RFC4932 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck May 2007 ASCII 57623 30 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 3732. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3732bis-04 RFC3732 RFC5732 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4932
RFC4933 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck May 2007 ASCII 82254 43 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3733bis-06 RFC3733 RFC5733 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4933
RFC4934 Extensible Provisioning Protocol (EPP) Transport Over TCP S. Hollenbeck May 2007 ASCII 22914 10 mapping client server tls transport layer security

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3734bis-05 RFC3734 RFC5734 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4934
RFC4935 Fibre Channel Fabric Configuration Server MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII 97345 50 management information base T11-FC-FABRIC-CONFIG-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. [STANDARDS-TRACK]

draft-ietf-imss-fc-fcs-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4935 10.17487/RFC4935
RFC4936 Fibre Channel Zone Server MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII 170801 84 management information base T11-FC-FABRIC-LOCK-MIB T11-FC-ZONE-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. [STANDARDS-TRACK]

draft-ietf-imss-fc-zs-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4936
RFC4937 IANA Considerations for PPP over Ethernet (PPPoE) P. Arberg V. Mammoliti June 2007 ASCII 11070 6

This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. This memo provides information for the Internet community.

draft-arberg-pppoe-iana-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4937
RFC4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics B. Berry H. Holgate June 2007 ASCII 38288 17

This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with a credit-based flow control mechanism and Link Quality Metric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. This memo provides information for the Internet community.

draft-bberry-pppoe-credit-06 RFC5578 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4938 10.17487/RFC4938
RFC4939 Definitions of Managed Objects for iSNS (Internet Storage Name Service) K. Gibbons G. Ramkumar S. Kipp July 2007 ASCII 165381 80 mib management information base iscsi internet small computer system interface ifcp internet fibre channel protocol ISNS-MIB

The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. [STANDARDS-TRACK]

draft-ietf-ips-isns-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4939 10.17487/RFC4939
RFC4940 IANA Considerations for OSPF K. Kompella B. Fenner July 2007 ASCII 27595 15 open shortest path first

This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ospf-iana-03 BCP0130 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4940 10.17487/RFC4940
RFC4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 T. Narten R. Draves S. Krishnan September 2007 ASCII 56699 23 privacy anonymity unlinkability crypto-based address changing

Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]

draft-ietf-ipv6-privacy-addrs-v2-05 RFC3041 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4941 10.17487/RFC4941
RFC4942 IPv6 Transition/Co-existence Security Considerations E. Davies S. Krishnan P. Savola September 2007 ASCII 102878 41 internet protocol version 6 dual-protocol network ipv4

The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories:

o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.

This memo provides information for the Internet community.

draft-ietf-v6ops-security-overview-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4942
RFC4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful S. Roy A. Durand J. Paugh September 2007 ASCII 16719 8 internet protocol version 6

This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm. This memo provides information for the Internet community.

draft-ietf-v6ops-onlinkassumption-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4943
RFC4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks G. Montenegro N. Kushalnagar J. Hui D. Culler September 2007 ASCII 67232 30 internet protocol version 6 link-local address stateless autoconfiguration

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]

draft-ietf-6lowpan-format-13 RFC6282 RFC6775 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=4944 10.17487/RFC4944
RFC4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX B. Korver August 2007 ASCII 101495 43 internet key exchange public key infrastructure for x.509 ipsec

The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec. [STANDARDS-TRACK]

draft-ietf-pki4ipsec-ikecert-profile-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec pki4ipsec 10.17487/RFC4945
RFC4946 Atom License Extension J. Snell July 2007 ASCII 14602 8 atom syndication format atom feeds atom entries

This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries. This memo defines an Experimental Protocol for the Internet community.

draft-snell-atompub-feed-license-11 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4946
RFC4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks G. Fairhurst M. Montpetit July 2007 ASCII 102717 41 encapsulate motion picture experts group unidirectional link protocol UniDirectional Link Routing address resolution protocol

This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.

In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol. This memo provides information for the Internet community.

draft-ietf-ipdvb-ar-06 INFORMATIONAL INFORMATIONAL IETF int ipdvb 10.17487/RFC4947
RFC4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006 L. Andersson E. Davies L. Zhang August 2007 ASCII 106199 43 spam botnet

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA. The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic. This memo provides information for the Internet community.

draft-iab-iwout-report-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4948 10.17487/RFC4948
RFC4949 Internet Security Glossary, Version 2 R. Shirey August 2007 ASCII 867626 365 abbreviation clarity definition dictionary language punctuation synonym terminology writing

This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.

draft-shirey-secgloss-v2-08 RFC2828 FYI0036 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4949
RFC4950 ICMP Extensions for Multiprotocol Label Switching R. Bonica D. Gan D. Tappan C. Pignataro August 2007 ASCII 15091 8 Internet Control Message Protocol

This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed. [STANDARDS-TRACK]

draft-ietf-mpls-icmp-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4950
RFC4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" V. Jain Editor August 2007 ASCII 53659 26 control connection layer 2 connectivity

Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity. [STANDARDS-TRACK]

draft-ietf-l2tpext-failover-12 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4951
RFC4952 Overview and Framework for Internationalized Email J. Klensin Y. Ko July 2007 ASCII 48409 20 smtp

Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This memo provides information for the Internet community.

draft-ietf-eai-framework-05 RFC6530 RFC5336 INFORMATIONAL INFORMATIONAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=4952 10.17487/RFC4952
RFC4953 Defending TCP Against Spoofing Attacks J. Touch July 2007 ASCII 72756 28 rst transport control protocol

Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. This memo provides information for the Internet community.

draft-ietf-tcpm-tcp-antispoof-06 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4953
RFC4954 SMTP Service Extension for Authentication R. Siemborski Editor A. Melnikov Editor July 2007 ASCII 43493 20 simple mail transport protocol security layer sasl

This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.

This document obsoletes RFC 2554. [STANDARDS-TRACK]

draft-siemborski-rfc2554bis-09 RFC2554 RFC3463 RFC5248 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4954 10.17487/RFC4954
RFC4955 DNS Security (DNSSEC) Experiments D. Blacka July 2007 ASCII 15417 7 domain namespace

This document describes a methodology for deploying alternate, non-backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-experiments-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC4955
RFC4956 DNS Security (DNSSEC) Opt-In R. Arends M. Kosters D. Blacka July 2007 ASCII 32033 17 domain namespace

In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dnsext-dnssec-opt-in-09 EXPERIMENTAL EXPERIMENTAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4956 10.17487/RFC4956
RFC4957 Link-Layer Event Notifications for Detecting Network Attachments S. Krishnan Editor N. Montavont E. Njedjou S. Veerepalli A. Yegin Editor August 2007 ASCII 41840 18

Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies. This memo provides information for the Internet community.

draft-ietf-dna-link-information-06 INFORMATIONAL INFORMATIONAL IETF int dna http://www.rfc-editor.org/errata_search.php?rfc=4957 10.17487/RFC4957
RFC4958 A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain K. Carlberg July 2007 ASCII 44008 28 priority prioritization preferential service

This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. This memo provides information for the Internet community.

draft-ietf-ieprep-domain-frame-08 INFORMATIONAL INFORMATIONAL IETF rai ieprep http://www.rfc-editor.org/errata_search.php?rfc=4958 10.17487/RFC4958
RFC4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response R. Siemborski A. Gulbrandsen September 2007 ASCII 12284 7 imap authenticate internet message access protocol

To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high.

This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. [STANDARDS-TRACK]

draft-siemborski-imap-sasl-initial-response-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4959 10.17487/RFC4959
RFC4960 Stream Control Transmission Protocol R. Stewart Editor September 2007 ASCII 346022 152 SCTP IP internet transport packet network

This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.

SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:

-- acknowledged error-free non-duplicated transfer of user data,

-- data fragmentation to conform to discovered path MTU size,

-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,

-- optional bundling of multiple user messages into a single SCTP packet, and

-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]

draft-ietf-tsvwg-2960bis-05 RFC2960 RFC3309 RFC6096 RFC6335 RFC7053 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4960 10.17487/RFC4960
RFC4961 Symmetric RTP / RTP Control Protocol (RTCP) D. Wing July 2007 ASCII 12539 6 real time transport protocol symmetric rtcp

This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-wing-behave-symmetric-rtprtcp-03 BCP0131 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4961
RFC4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management R. Housley B. Aboba July 2007 ASCII 54927 23

This document provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-housley-aaa-key-mgmt-09 BCP0132 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4962
RFC4963 IPv4 Reassembly Errors at High Data Rates J. Heffner M. Mathis B. Chandler July 2007 ASCII 22399 10

IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. This memo provides information for the Internet community.

draft-heffner-frag-harmful-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4963
RFC4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular A. Allen Editor J. Holm T. Hallin September 2007 ASCII 67505 32 p-header oma open mobile alliance poc

This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application. This memo provides information for the Internet community.

draft-allen-sipping-poc-p-answer-state-header-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4964
RFC4965 CableLabs - IETF Standardization Collaboration J-F. Mule W. Townsley September 2007 ASCII 20885 10 IETF CableLabs Collaboration liaison Cable Television Laboratories DOCSIS PacketCable OpenCable

This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the Cable Television Laboratories, Inc. (CableLabs). This memo provides information for the Internet community.

draft-mule-ietf-cablelabs-collaboration-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4965
RFC4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status C. Aoun E. Davies July 2007 ASCII 60284 25 NAT-PT v6ops

This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status. This memo provides information for the Internet community.

draft-ietf-v6ops-natpt-to-historic-00 RFC2766 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4966 10.17487/RFC4966
RFC4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier B. Rosen July 2007 ASCII 12659 6 dialstring

RFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI. [STANDARDS-TRACK]

draft-rosen-iptel-dialstring-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4967 10.17487/RFC4967
RFC4968 Analysis of IPv6 Link Models for 802.16 Based Networks S. Madanapalli Editor August 2007 ASCII 34536 16 wimax

This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks. This memo provides information for the Internet community.

draft-ietf-16ng-ipv6-link-model-analysis-03 INFORMATIONAL INFORMATIONAL IETF int 16ng http://www.rfc-editor.org/errata_search.php?rfc=4968 10.17487/RFC4968
RFC4969 IANA Registration for vCard Enumservice A. Mayrhofer August 2007 ASCII 14038 7 enum e.164

This memo registers the Enumservice "vCard" using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number.

Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. [STANDARDS-TRACK]

draft-ietf-enum-vcard-06 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4969
RFC4970 Extensions to OSPF for Advertising Optional Router Capabilities A. Lindem Editor N. Shen JP. Vasseur R. Aggarwal S. Shaffer July 2007 ASCII 26416 13 ospfv2 ospfv3 open shortest path first ri router information lsa link state advertisement

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). [STANDARDS-TRACK]

draft-ietf-ospf-cap-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4970
RFC4971 Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information JP. Vasseur Editor N. Shen Editor R. Aggarwal Editor July 2007 ASCII 18541 9 capabilty

This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. [STANDARDS-TRACK]

draft-ietf-isis-caps-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC4971
RFC4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership JP. Vasseur Editor JL. Leroux Editor S. Yasukawa S. Previdi P. Psenak P. Mabbey July 2007 ASCII 32044 15 mpls-te lsp label switched path igp is-is ospf

The setup of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TE LSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs. [STANDARDS-TRACK]

draft-ietf-ccamp-automesh-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4972
RFC4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering P. Srisuresh P. Joseph July 2007 ASCII 115361 50 ospf-te link state advertisement lsa

This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs. OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time Division Multiplexing (TDM) and optical networks. This memo defines an Experimental Protocol for the Internet community.

draft-srisuresh-ospf-te-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4973
RFC4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls D. Papadimitriou A. Farrel August 2007 ASCII 72000 31

In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.

A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs).

This document specifies how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation.

The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-rsvp-te-call-04 RFC3473 RFC6001 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4974
RFC4975 The Message Session Relay Protocol (MSRP) B. Campbell Editor R. Mahy Editor C. Jennings Editor September 2007 ASCII 144254 63 instant message

This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]

draft-ietf-simple-message-sessions-19 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4975 10.17487/RFC4975
RFC4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP) C. Jennings R. Mahy A. B. Roach September 2007 ASCII 84244 36 instante message page-mode session-mode relay intermediary

Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. [STANDARDS-TRACK]

draft-ietf-simple-msrp-relays-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4976 10.17487/RFC4976
RFC4977 Problem Statement: Dual Stack Mobility G. Tsirtsis H. Soliman August 2007 ASCII 16758 8 mobility management protocol mipv4 mipv6 mobile ip

This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems. Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node. This memo provides information for the Internet community.

draft-ietf-mip6-dsmip-problem-03 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4977
RFC4978 The IMAP COMPRESS Extension A. Gulbrandsen August 2007 ASCII 17554 9 Internet Message Access Protocol

The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. [STANDARDS-TRACK]

draft-ietf-lemonade-compress-08 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4978 10.17487/RFC4978
RFC4979 IANA Registration for Enumservice 'XMPP' A. Mayrhofer August 2007 ASCII 11719 7 extensible messaging and presence protocol e.164

This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM). [STANDARDS-TRACK]

draft-ietf-enum-xmpp-02 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4979
RFC4980 Analysis of Multihoming in Network Mobility Support C. Ng T. Ernst E. Paik M. Bagnulo October 2007 ASCII 88572 39 nemo ipv6 mobile networks

This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. This memo provides information for the Internet community.

draft-ietf-nemo-multihoming-issues-07 INFORMATIONAL INFORMATIONAL IETF int nemo 10.17487/RFC4980
RFC4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods J. Risson T. Moors September 2007 ASCII 239752 91 Peer-to-peer network Distributed hash table Structured overlay Unstructured overlay Key-based routing Consistent hashing Scalable distributed data structure Dependability Hypercube Plaxton tree de Bruijn graph Skip graph Torus Butterfly network Vector model Latent semantic indexing

The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology -- it can aggregate enormous storage and processing resources while minimizing entry and scaling costs.

Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus, the key to realizing P2P's potential in applications other than casual file sharing is robustness.

P2P search methods are first couched within an overall P2P taxonomy. P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs, and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join, and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research. This memo provides information for the Internet community.

draft-irtf-p2prg-survey-search-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4981
RFC4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) M. Bagnulo J. Arkko July 2007 ASCII 20961 9

This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. [STANDARDS-TRACK]

draft-bagnulo-multiple-hash-cga-03 RFC3972 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4982 10.17487/RFC4982
RFC4983 Fibre Channel Registered State Change Notification (RSCN) MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII 56049 28 management information base T11-FC-RSCN-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the management of Fibre Channel's Registered State Change Notifications (RSCNs). [STANDARDS-TRACK]

draft-ietf-imss-fc-rscn-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4983
RFC4984 Report from the IAB Workshop on Routing and Addressing D. Meyer Editor L. Zhang Editor K. Fall Editor September 2007 ASCII 96153 39 routing and addressing workshop routing table growth addressing architecture

This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.

draft-iab-raws-report-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4984 10.17487/RFC4984
RFC4985 Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name S. Santesson August 2007 ASCII 17868 10 othername

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK]

draft-ietf-pkix-srvsan-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4985 10.17487/RFC4985
RFC4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover H. Eland R. Mundy S. Crocker S. Krishnaswamy August 2007 ASCII 22647 11 dns signed zone

Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. This memo provides information for the Internet community.

draft-ietf-dnsext-rollover-requirements-04 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC4986
RFC4987 TCP SYN Flooding Attacks and Common Mitigations W. Eddy August 2007 ASCII 48753 19 TCP SYN Flood TCP SYN Cookies denial-of-service DoS

This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. This memo provides information for the Internet community.

draft-ietf-tcpm-syn-flood-05 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4987
RFC4988 Mobile IPv4 Fast Handovers R. Koodli C. Perkins October 2007 ASCII 57921 28 mip4 delay packet loss movement detection ip address configuration loation update latency care-of address care of address coa

This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mip4-fmipv4-07 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC4988
RFC4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks K. Shiomoto R. Papneja R. Rabbat September 2007 ASCII 50908 23 address field identifier field

This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.

The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.

This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-addressing-08 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4990
RFC4991 A Common Schema for Internet Registry Information Service Transfer Protocols A. Newton August 2007 ASCII 24418 13 iris xml

This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. [STANDARDS-TRACK]

draft-ietf-crisp-iris-common-transport-05 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4991 10.17487/RFC4991
RFC4992 XML Pipelining with Chunks for the Internet Registry Information Service A. Newton August 2007 ASCII 55848 29 tcp transport control protocol iris

This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining. [STANDARDS-TRACK]

draft-ietf-crisp-iris-xpc-06 RFC3981 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4992 10.17487/RFC4992
RFC4993 A Lightweight UDP Transfer Protocol for the Internet Registry Information Service A. Newton August 2007 ASCII 34383 19 iris

This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. [STANDARDS-TRACK]

draft-ietf-crisp-iris-lwz-08 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4993 10.17487/RFC4993
RFC4994 DHCPv6 Relay Agent Echo Request Option S. Zeng B. Volz K. Kinnear J. Brzozowski September 2007 ASCII 10978 6 dynamic host configuration protocol relay agent option

This memo defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-ero-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4994
RFC4995 The RObust Header Compression (ROHC) Framework L-E. Jonsson G. Pelletier K. Sandlund July 2007 ASCII 87198 40

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. [STANDARDS-TRACK]

draft-ietf-rohc-rfc3095bis-framework-04 RFC5795 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4995 10.17487/RFC4995
RFC4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) G. Pelletier K. Sandlund L-E. Jonsson M. West July 2007 ASCII 183113 94

This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. [STANDARDS-TRACK]

draft-ietf-rohc-tcp-16 RFC6846 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4996 10.17487/RFC4996
RFC4997 Formal Notation for RObust Header Compression (ROHC-FN) R. Finking G. Pelletier July 2007 ASCII 131231 62 Robust Header Compression - Formal Notation

This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work. [STANDARDS-TRACK]

draft-ietf-rohc-formal-notation-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4997
RFC4998 Evidence Record Syntax (ERS) T. Gondrom R. Brandner U. Pordesch August 2007 ASCII 66888 32 long-term archive security timestamp evidence record archive timestamp

In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK]

draft-ietf-ltans-ers-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC4998
RFC5000 Internet Official Protocol Standards RFC Editor May 2008 ASCII 222566 75

This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, and Experimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred.

For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily. This memo provides information for the Internet community.

RFC3700 RFC7100 HISTORIC INFORMATIONAL INDEPENDENT 10.17487/RFC5000
RFC5001 DNS Name Server Identifier (NSID) Option R. Austein August 2007 ASCII 23754 11 domain name space namespace

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. [STANDARDS-TRACK]

draft-ietf-dnsext-nsid-02 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5001
RFC5002 The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header) G. Camarillo G. Blanco August 2007 ASCII 15137 7 3gpp ims ip multimedia subsystem

This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request. This memo provides information for the Internet community.

draft-camarillo-sipping-profile-key-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5002 10.17487/RFC5002
RFC5003 Attachment Individual Identifier (AII) Types for Aggregation C. Metz L. Martini F. Balus J. Sugimoto September 2007 ASCII 14559 7 tlv pseudowire

The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and Virtual Private Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. [STANDARDS-TRACK]

draft-ietf-pwe3-aii-aggregate-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5003 10.17487/RFC5003
RFC5004 Avoid BGP Best Path Transitions from One External to Another E. Chen S. Sangli September 2007 ASCII 11437 6 border gateway protocol

In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. [STANDARDS-TRACK]

draft-ietf-idr-avoid-transition-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5004
RFC5005 Feed Paging and Archiving M. Nottingham September 2007 ASCII 28937 15 atom rss

This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents. This includes "paged" feeds for piecemeal access, "archived" feeds that allow reconstruction of the feed's contents, and feeds that are explicitly "complete". [STANDARDS-TRACK]

draft-nottingham-atompub-feed-history-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5005 10.17487/RFC5005
RFC5006 IPv6 Router Advertisement Option for DNS Configuration J. Jeong Editor S. Park L. Beloeil S. Madanapalli September 2007 ASCII 26136 12 domain namespace

This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts. This memo defines an Experimental Protocol for the Internet community.

draft-jeong-dnsop-ipv6-dns-discovery-12 RFC6106 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5006
RFC5007 DHCPv6 Leasequery J. Brzozowski K. Kinnear B. Volz S. Zeng September 2007 ASCII 47186 23 dhc dhcp ipv6

This document specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-leasequery-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=5007 10.17487/RFC5007
RFC5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) R. Housley J. Solinas September 2007 ASCII 32869 15 nsa

This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 3851. This memo provides information for the Internet community.

draft-housley-smime-suite-b-02 RFC6318 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5008 10.17487/RFC5008
RFC5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media R. Ejza September 2007 ASCII 36092 15 IMS NGN ETSI TISPAN Gating Cut-through Call progress Charging PSTN Interworking Gateway Ringback Trust domain

This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet-converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. This memo provides information for the Internet community.

draft-ejzak-sipping-p-em-auth-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5009
RFC5010 The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption K. Kinnear M. Normoyle M. Stapp September 2007 ASCII 13834 7 unicast flag broadcast flag

This memo defines a new suboption of the Dynamic Host Configuration Protocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. [STANDARDS-TRACK]

draft-ietf-dhc-relay-agent-flags-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5010
RFC5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors M. StJohns September 2007 ASCII 30138 14 n-1 key n keys

This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).

This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK]

draft-ietf-dnsext-trustupdate-timers-06 STD0074 INTERNET STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5011
RFC5012 Requirements for Emergency Context Resolution with Internet Technologies H. Schulzrinne R. Marshall Editor January 2008 ASCII 54599 23 emergency calling ecrit

This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end. This memo provides information for the Internet community.

draft-ietf-ecrit-requirements-13 INFORMATIONAL INFORMATIONAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5012 10.17487/RFC5012
RFC5013 The Dublin Core Metadata Element Set J. Kunze T. Baker August 2007 ASCII 17776 9 resource description object descriptors digital library collections

This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment. This memo provides information for the Internet community.

draft-kunze-rfc2413bis-07 RFC2413 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5013
RFC5014 IPv6 Socket API for Source Address Selection E. Nordmark S. Chakrabarti J. Laganier September 2007 ASCII 53601 24 getaddrinfo()cga cryptographically generated address

The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API. However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents. This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses. This memo provides information for the Internet community.

draft-chakrabarti-ipv6-addrselect-api-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5014
RFC5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM) M. Handley I. Kouvelas T. Speakman L. Vicisano October 2007 ASCII 96431 43 pim sparse-mode shared trees

This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK]

draft-ietf-pim-bidir-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5015 10.17487/RFC5015
RFC5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol M. Thomas October 2007 ASCII 33710 15 cryptographic

DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD). This memo provides information for the Internet community.

draft-ietf-dkim-ssp-requirements-05 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5016
RFC5017 MIB Textual Conventions for Uniform Resource Identifiers (URIs) D. McWalter Editor September 2007 ASCII 14826 7 management information base URI-TC-MIB

This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). [STANDARDS-TRACK]

draft-mcwalter-uri-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5017
RFC5018 Connection Establishment in the Binary Floor Control Protocol (BFCP) G. Camarillo September 2007 ASCII 20244 9 floor control server tls transport layer security

This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]

draft-ietf-xcon-bfcp-connection-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC5018
RFC5019 The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments A. Deacon R. Hurst September 2007 ASCII 46371 22 OCSP Online Certificate Status Protocol certificate status http caching http proxies efficient cacheable pre-produced

This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]

draft-ietf-pkix-lightweight-ocsp-profile-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5019
RFC5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute K. Zeilenga August 2007 ASCII 8607 5 x.500

This document describes the Lightweight Directory Access Protocol (LDAP) / X.500 'entryDN' operational attribute. The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. [STANDARDS-TRACK]

draft-zeilenga-ldap-entrydn-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5020
RFC5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP S. Josefsson August 2007 ASCII 13431 7

This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiate TCP-specific Kerberos extensions. [STANDARDS-TRACK]

draft-ietf-krb-wg-tcp-expansion-02 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC5021
RFC5022 Media Server Control Markup Language (MSCML) and Protocol J. Van Dyke E. Burger Editor A. Spitzer September 2007 ASCII 184482 81 sip ivr interactive voice response

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. This memo provides information for the Internet community.

RFC4722 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5022 10.17487/RFC5022
RFC5023 The Atom Publishing Protocol J. Gregorio Editor B. de hOra Editor October 2007 ASCII 102274 53 atompub http transfer atom syndication format

The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format. [STANDARDS-TRACK]

draft-ietf-atompub-protocol-17 PROPOSED STANDARD PROPOSED STANDARD IETF app atompub http://www.rfc-editor.org/errata_search.php?rfc=5023 10.17487/RFC5023
RFC5024 ODETTE File Transfer Protocol 2.0 I. Friend November 2007 ASCII 276953 135

This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.

The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.

The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks. This memo provides information for the Internet community.

draft-friend-oftp2-04 RFC2204 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5024 10.17487/RFC5024
RFC5025 Presence Authorization Rules J. Rosenberg December 2007 ASCII 65880 28 presence systems authorization policies xml extensible markup language

Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. [STANDARDS-TRACK]

draft-ietf-simple-presence-rules-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5025 10.17487/RFC5025
RFC5026 Mobile IPv6 Bootstrapping in Split Scenario G. Giaretta Editor J. Kempf V. Devarapalli Editor October 2007 ASCII 63138 28 mip6 bootstrapping problem statement

A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. [STANDARDS-TRACK]

draft-ietf-mip6-bootstrapping-split-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5026
RFC5027 Security Preconditions for Session Description Protocol (SDP) Media Streams F. Andreasen D. Wing October 2007 ASCII 37229 16 DTLS DTLS-SRTP TLS MIKEY Security Descriptions SRTP

This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. [STANDARDS-TRACK]

draft-ietf-mmusic-securityprecondition-04 RFC3312 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5027
RFC5028 A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services R. Mahy October 2007 ASCII 9804 5 'im:' uri uniform resource identifier

This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. [STANDARDS-TRACK]

draft-ietf-enum-im-service-03 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5028
RFC5029 Definition of an IS-IS Link Attribute Sub-TLV JP. Vasseur S. Previdi September 2007 ASCII 9887 6 link-attributes tlv 22

This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. [STANDARDS-TRACK]

draft-ietf-isis-link-attr-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5029
RFC5030 Mobile IPv4 RADIUS Requirements M. Nakhjiri Editor K. Chowdhury A. Lior K. Leung October 2007 ASCII 20319 9 remote authentication dial-in user service mip mipv4

This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service (RADIUS) extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures. This memo provides information for the Internet community.

draft-ietf-mip4-radius-requirements-04 INFORMATIONAL INFORMATIONAL IETF int mip4 10.17487/RFC5030
RFC5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services H. Schulzrinne January 2008 ASCII 32960 14 urn ecrit

The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines. [STANDARDS-TRACK]

draft-ietf-ecrit-service-urn-07 RFC7163 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5031 10.17487/RFC5031
RFC5032 WITHIN Search Extension to the IMAP Protocol E. Burger Editor September 2007 ASCII 8921 5 imap search older younger

This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. [STANDARDS-TRACK]

draft-ietf-lemonade-search-within-05 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5032
RFC5033 Specifying New Congestion Control Algorithms S. Floyd M. Allman August 2007 ASCII 23469 10

The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-tsvwg-cc-alt-04 BCP0133 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC5033
RFC5034 The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism R. Siemborski A. Menon-Sen July 2007 ASCII 24170 12 POP3-AUTH Post Office Protocol Email

This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session.

This document seeks to consolidate the information related to POP3 AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained in Section 6.3 of RFC 2449. [STANDARDS-TRACK]

draft-siemborski-rfc1734bis-11 RFC1734 RFC2449 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5034
RFC5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility J. Schaad August 2007 ASCII 32674 17 validation signature certificate

In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS-TRACK]

draft-ietf-smime-escertid-06 RFC2634 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5035 10.17487/RFC5035
RFC5036 LDP Specification L. Andersson Editor I. Minei Editor B. Thomas Editor October 2007 ASCII 287101 135 label distribution protocol

The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]

draft-ietf-mpls-rfc3036bis-04 RFC3036 RFC6720 RFC6790 RFC7358 RFC7552 DRAFT STANDARD DRAFT STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5036 10.17487/RFC5036
RFC5037 Experience with the Label Distribution Protocol (LDP) L. Andersson Editor I. Minei Editor B. Thomas Editor October 2007 ASCII 13886 7

The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-experience-00 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5037
RFC5038 The Label Distribution Protocol (LDP) Implementation Survey Results B. Thomas L. Andersson October 2007 ASCII 46890 23 multiprotocol label switching mpls lsr label switched routers

Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a Label Distribution Protocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made. One such protocol, called LDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-survey2002-00 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5038
RFC5039 The Session Initiation Protocol (SIP) and Spam J. Rosenberg C. Jennings January 2008 ASCII 73341 28

Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. This memo provides information for the Internet community.

draft-ietf-sipping-spam-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5039
RFC5040 A Remote Direct Memory Access Protocol Specification R. Recio B. Metzler P. Culley J. Hilland D. Garcia October 2007 ASCII 142247 66 rdmap ddp direct data placement protocol

This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation. [STANDARDS-TRACK]

draft-ietf-rddp-rdmap-07 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5040
RFC5041 Direct Data Placement over Reliable Transports H. Shah J. Pinkerton R. Recio P. Culley October 2007 ASCII 84642 38 ddp cpu

The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. [STANDARDS-TRACK]

draft-ietf-rddp-ddp-07 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5041
RFC5042 Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security J. Pinkerton E. Deleganes October 2007 ASCII 127453 52 rdma network interface card rnic

This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from Local Peers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. [STANDARDS-TRACK]

draft-ietf-rddp-security-10 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5042
RFC5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation C. Bestler Editor R. Stewart Editor October 2007 ASCII 38740 18 lower layer protocol llp

This document specifies an adaptation layer to provide a Lower Layer Protocol (LLP) service for Direct Data Placement (DDP) using the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]

draft-ietf-rddp-sctp-07 RFC6581 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5043
RFC5044 Marker PDU Aligned Framing for TCP Specification P. Culley U. Elzur R. Recio S. Bailey J. Carrier October 2007 ASCII 168918 74 mpa adaaptation layer ddp direct data placement protocol transmission

Marker PDU Aligned Framing (MPA) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement protocol (DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. [STANDARDS-TRACK]

draft-ietf-rddp-mpa-08 RFC6581 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp http://www.rfc-editor.org/errata_search.php?rfc=5044 10.17487/RFC5044
RFC5045 Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) C. Bestler Editor L. Coene October 2007 ASCII 51749 22 rdmap

This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. This memo provides information for the Internet community.

draft-ietf-rddp-applicability-08 RFC7146 INFORMATIONAL INFORMATIONAL IETF tsv rddp 10.17487/RFC5045
RFC5046 Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) M. Ko M. Chadalapaka J. Hufferd U. Elzur H. Shah P. Thaler October 2007 ASCII 202216 85 rdma data transfer

Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol, such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. [STANDARDS-TRACK]

draft-ietf-ips-iser-06 RFC7145 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC5046
RFC5047 DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI) M. Chadalapaka J. Hufferd J. Satran H. Shah October 2007 ASCII 107970 49 scsi transport protocol tcp/ip

The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols. Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access (RDMA)-capable IP fabrics in the future comprising TCP, the Stream Control Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand. This memo provides information for the Internet community.

draft-ietf-ips-iwarp-da-05 RFC7146 INFORMATIONAL INFORMATIONAL IETF tsv ips 10.17487/RFC5047
RFC5048 Internet Small Computer System Interface (iSCSI) Corrections and Clarifications M. Chadalapaka Editor October 2007 ASCII 80149 38 scsi iscsi protocol

The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-impl-guide-09 RFC7143 RFC3720 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC5048
RFC5049 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) C. Bormann Z. Liu R. Price G. Camarillo Editor December 2007 ASCII 47891 21

This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. [STANDARDS-TRACK]

draft-ietf-rohc-sigcomp-sip-08 RFC3486 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC5049
RFC5050 Bundle Protocol Specification K. Scott S. Burleigh November 2007 ASCII 120435 50 delay tolerant networking dtn dtnrg exchange of messages

This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).

This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-bundle-spec-10 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5050 10.17487/RFC5050
RFC5051 i;unicode-casemap - Simple Unicode Collation Algorithm M. Crispin October 2007 ASCII 14965 7 unicode strings i;ascii-casemap

This document describes "i;unicode-casemap", a simple case-insensitive collation for Unicode strings. It provides equality, substring, and ordering operations. [STANDARDS-TRACK]

draft-crispin-collation-unicasemap-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5051
RFC5052 Forward Error Correction (FEC) Building Block M. Watson M. Luby L. Vicisano August 2007 ASCII 57754 25 bulk data transfer

This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452. [STANDARDS-TRACK]

draft-ietf-rmt-fec-bb-revised-07 RFC3452 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5052 10.17487/RFC5052
RFC5053 Raptor Forward Error Correction Scheme for Object Delivery M. Luby A. Shokrollahi M. Watson T. Stockhammer October 2007 ASCII 113743 46 fec fec encoding raptor code

This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects.

Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols.

The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-raptor-object-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5053
RFC5054 Using the Secure Remote Password (SRP) Protocol for TLS Authentication D. Taylor T. Wu N. Mavrogiannopoulos T. Perrin November 2007 ASCII 44445 24 secure remote password protocol transport layer security

This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. This memo provides information for the Internet community.

draft-ietf-tls-srp-14 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5054 10.17487/RFC5054
RFC5055 Server-Based Certificate Validation Protocol (SCVP) T. Freeman R. Housley A. Malpani D. Cooper W. Polk December 2007 ASCII 198764 88 certification path construction certification path validation

The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. [STANDARDS-TRACK]

draft-ietf-pkix-scvp-33 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5055
RFC5056 On the Use of Channel Bindings to Secure Channels N. Williams November 2007 ASCII 49995 23

The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.

This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK]

draft-williams-on-channel-binding-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5056 10.17487/RFC5056
RFC5057 Multiple Dialog Usages in the Session Initiation Protocol R. Sparks November 2007 ASCII 62654 26

Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.

This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.

This is an informative document and makes no normative statements of any kind. This memo provides information for the Internet community.

draft-ietf-sipping-dialogusage-06 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5057
RFC5058 Explicit Multicast (Xcast) Concepts and Options R. Boivie N. Feldman Y. Imai W. Livens D. Ooms November 2007 ASCII 80072 35 explicit multi-unicast

While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.

This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. This memo defines an Experimental Protocol for the Internet community.

draft-ooms-xcast-basic-spec-13 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5058 10.17487/RFC5058
RFC5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) N. Bhaskar A. Gall J. Lingard S. Venaas January 2008 ASCII 100749 42 PDF 85519 rendezvous point rp multicast router

This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. [STANDARDS-TRACK]

draft-ietf-pim-sm-bsr-12 RFC2362 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5059 10.17487/RFC5059
RFC5060 Protocol Independent Multicast MIB R. Sivaramu J. Lingard D. McWalter B. Joshi A. Kessler January 2008 ASCII 170123 90 PIM PIM-SM BIDIR-PIM PIM-DM Multicast Routing PIM-STD-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode), BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934. [STANDARDS-TRACK]

draft-ietf-pim-mib-v2-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5060 10.17487/RFC5060
RFC5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration R. Stewart Q. Xie M. Tuexen S. Maruyama M. Kozuka September 2007 ASCII 91851 41

A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. Stream Control Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. [STANDARDS-TRACK]

draft-ietf-tsvwg-addip-sctp-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5061
RFC5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures R. Stewart M. Tuexen G. Camarillo September 2007 ASCII 29704 14

This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460). These techniques are included in RFC 4960, which obsoletes RFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 4960. This memo provides information for the Internet community.

draft-ietf-tsvwg-sctpthreat-05 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5062
RFC5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart A. Satyanarayana Editor R. Rahman Editor October 2007 ASCII 58542 24 nodal faults rsvp hello state recovery

This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.

Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.

The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.

These extensions are not used to create or restore data plane state.

The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). [STANDARDS-TRACK]

draft-ietf-ccamp-rsvp-restart-ext-09 RFC2961 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5063 10.17487/RFC5063
RFC5064 The Archived-At Message Header Field M. Duerst December 2007 ASCII 20863 10

This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. [STANDARDS-TRACK]

draft-duerst-archived-at-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5064
RFC5065 Autonomous System Confederations for BGP P. Traina D. McPherson J. Scudder August 2007 ASCII 28732 14 border gateway protocol tcp/ip full mesh

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.

This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.

This document obsoletes RFC 3065. [STANDARDS-TRACK]

draft-ietf-idr-rfc3065bis-06 RFC3065 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5065 10.17487/RFC5065
RFC5066 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB E. Beili November 2007 ASCII 193465 90 Network Management Simple Network Management Protocol SNMP Management Information Base MIB Textual Conventions 2BASE-TL 10PASS-TS 802.3ah EFM PAF PME

This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets. This document describes extensions to the Ethernet-like Interfaces MIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3- 2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. [STANDARDS-TRACK]

draft-ietf-hubmib-efm-cu-mib-08 RFC7124 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC5066
RFC5067 Infrastructure ENUM Requirements S. Lind P. Pfautz November 2007 ASCII 14311 7 e.164 number mapping carrier

This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) This memo provides information for the Internet community.

draft-ietf-enum-infrastructure-enum-reqs-04 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5067
RFC5068 Email Submission Operations: Access and Accountability Requirements C. Hutzler D. Crocker P. Resnick E. Allman T. Finch November 2007 ASCII 24481 12 spam email abuse phishing email e-mail service mime rfc2822 rfc 2822 rfc822 rfc 822 rfc2821 rfc 2821 rfc821 rfc 821 architecture mta mua msa mda user delivery relay header gateway agent sieve dsn mdn tussle mhs mail handling service message transfer agent message user agent mail submission agent mail delivery agent

Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.

Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hutzler-spamops-08 BCP0134 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5068
RFC5069 Security Threats and Requirements for Emergency Call Marking and Mapping T. Taylor Editor H. Tschofenig H. Schulzrinne M. Shanmugam January 2008 ASCII 26230 12 ecrit public safety answering points pasp

This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.

Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. This memo provides information for the Internet community.

draft-ietf-ecrit-security-threats-05 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC5069
RFC5070 The Incident Object Description Exchange Format R. Danyliw J. Meijer Y. Demchenko December 2007 ASCII 171529 92 incident data format compuer security incident computer security incident response team csirt cert security data sharing computer network defense service provider cndsp

The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. [STANDARDS-TRACK]

draft-ietf-inch-iodef-14 RFC6685 PROPOSED STANDARD PROPOSED STANDARD IETF sec inch http://www.rfc-editor.org/errata_search.php?rfc=5070 10.17487/RFC5070
RFC5071 Dynamic Host Configuration Protocol Options Used by PXELINUX D. Hankins December 2007 ASCII 26777 14 dhcp dhcp option codes

This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211. This memo provides information for the Internet community.

draft-ietf-dhc-pxelinux-03 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC5071
RFC5072 IP Version 6 over PPP S. Varada Editor D. Haskins E. Allen September 2007 ASCII 33910 16 IPv6-PPP internet protocol point-to-point ipv6

The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.

It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.

This document obsoletes RFC 2472. [STANDARDS-TRACK]

draft-ietf-ipv6-over-ppp-v2-03 RFC2472 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 10.17487/RFC5072
RFC5073 IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities J.P. Vasseur Editor J.L. Le Roux Editor December 2007 ASCII 27004 13 interior gateway protocol

It is highly desired, in several cases, to take into account Traffic Engineering (TE) node capabilities during Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies Open Shortest Path First (OSPF) and Intermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. [STANDARDS-TRACK]

draft-ietf-ccamp-te-node-cap-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5073
RFC5074 DNSSEC Lookaside Validation (DLV) S. Weiler November 2007 ASCII 23375 11 dns security trust anchors

DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNS Security (DNSSEC) trust anchors outside of the DNS delegation chain. It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publish Delegation Signer (DS) records for their children. This memo provides information for the Internet community.

draft-weiler-dnssec-dlv-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5074
RFC5075 IPv6 Router Advertisement Flags Option B. Haberman Editor R. Hinden November 2007 ASCII 12499 7 neighbor discovery protocol ndp expanded flags option efo ndp router advertisement message

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. [STANDARDS-TRACK]

draft-ietf-ipv6-ra-flags-option-02 RFC5175 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=5075 10.17487/RFC5075
RFC5076 ENUM Validation Information Mapping for the Extensible Provisioning Protocol B. Hoeneisen December 2007 ASCII 44679 24 epp validation process e.164 enum enum domain name

This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names. [STANDARDS-TRACK]

draft-ietf-enum-validation-epp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5076
RFC5077 Transport Layer Security (TLS) Session Resumption without Server-Side State J. Salowey H. Zhou P. Eronen H. Tschofenig January 2008 ASCII 41989 20

This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]

draft-salowey-tls-rfc4507bis-01 RFC4507 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5077
RFC5078 IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline S. Dawkins October 2007 ASCII 19870 9 Internet Architecture Board Engineering Steering Group nomcom

RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in the NomCom process that meets the minimum normative requirements for the process. Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson (2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier. This document restructures the sample timeline, but makes no normative process changes. This memo provides information for the Internet community.

draft-dawkins-nomcom-start-earlier-02 RFC7437 RFC3777 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5078
RFC5079 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) J. Rosenberg December 2007 ASCII 15670 8 anonymous calls

The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. [STANDARDS-TRACK]

draft-ietf-sip-acr-code-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5079
RFC5080 Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes D. Nelson A. DeKok December 2007 ASCII 64138 28

This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [STANDARDS-TRACK]

draft-ietf-radext-fixes-08 RFC2865 RFC2866 RFC2869 RFC3579 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC5080
RFC5081 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication N. Mavrogiannopoulos November 2007 ASCII 15300 8 tls handshake protocol handshake

This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tls-openpgp-keys-11 RFC6091 EXPERIMENTAL EXPERIMENTAL IETF sec tls 10.17487/RFC5081
RFC5082 The Generalized TTL Security Mechanism (GTSM) V. Gill J. Heasley D. Meyer P. Savola Editor C. Pignataro October 2007 ASCII 36579 16 time to live packet hop limit

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]

draft-ietf-rtgwg-rfc3682bis-10 RFC3682 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC5082
RFC5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type R. Housley November 2007 ASCII 22810 10 encryption mode

This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]

draft-ietf-smime-cms-auth-enveloped-06 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC5083
RFC5084 Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) R. Housley November 2007 ASCII 21821 11 authenticated encryption algorithm

This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK]

draft-ietf-smime-cms-aes-ccm-and-gcm-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC5084
RFC5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires T. Nadeau Editor C. Pignataro Editor December 2007 ASCII 67847 30 pw

This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS-TRACK]

draft-ietf-pwe3-vccv-15 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5085
RFC5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) A. Vainshtein Editor I. Sasson E. Metz T. Frost P. Pate December 2007 ASCII 83233 38 nxds0 psn

This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553). This memo provides information for the Internet community.

draft-ietf-pwe3-cesopsn-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC5086
RFC5087 Time Division Multiplexing over IP (TDMoIP) Y(J). Stein R. Shashoua R. Insler M. Anavi December 2007 ASCII 113071 50 TDM pseudowire PWE3 TDMoIP structure-aware TDM emulation

Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensure TDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accessibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling. This memo provides information for the Internet community.

draft-ietf-pwe3-tdmoip-06 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5087 10.17487/RFC5087
RFC5088 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery JL. Le Roux Editor JP. Vasseur Editor Y. Ikejiri R. Zhang January 2008 ASCII 40936 20 pcc path computation client open shortest path first

There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. [STANDARDS-TRACK]

draft-ietf-pce-disco-proto-ospf-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5088 10.17487/RFC5088
RFC5089 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery JL. Le Roux Editor JP. Vasseur Editor Y. Ikejiri R. Zhang January 2008 ASCII 34257 17 path computation client pcc intermediate system to intermediate system

There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. [STANDARDS-TRACK]

draft-ietf-pce-disco-proto-isis-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5089 10.17487/RFC5089
RFC5090 RADIUS Extension for Digest Authentication B. Sterman D. Sadolevsky D. Schwartz D. Williams W. Beck February 2008 ASCII 68299 33 remote authentication dial-in user service sip http

This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]

draft-ietf-radext-rfc4590bis-02 RFC4590 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5090 10.17487/RFC5090
RFC5091 Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems X. Boyen L. Martin December 2007 ASCII 103464 63 Encryption Cryptography Security Elliptic Curves Elliptic Curve Cryptography Pairing-based Cryptography Identity-based Cryptography Identity-based Encryption Boneh-Franklin Encryption Scheme Boneh-Boyen Encryption Scheme

This document describes the algorithms that implement Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document. This memo provides information for the Internet community.

draft-martin-ibcs-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5091 10.17487/RFC5091
RFC5092 IMAP URL Scheme A. Melnikov Editor C. Newman November 2007 ASCII 65197 32 IMAP-URL remote access store Internet Message Access Protocol Uniform Resource Identifiers

IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.

This document obsoletes RFC 2192. It also updates RFC 4467. [STANDARDS-TRACK]

draft-ietf-lemonade-rfc2192bis-09 RFC2192 RFC4467 RFC5593 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5092 10.17487/RFC5092
RFC5093 BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ) G. Hunt December 2007 ASCII 15110 8 next-generation network rtcp xr real time control protocol extended reports transport metrics

This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre-standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network. This memo provides information for the Internet community.

draft-hunt-avt-rtcpxnq-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5093
RFC5094 Mobile IPv6 Vendor Specific Option V. Devarapalli A. Patel K. Leung December 2007 ASCII 11430 7 mobility header mip6 mipv6

There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor-specific mobility option. [STANDARDS-TRACK]

draft-ietf-mip6-vsm-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5094
RFC5095 Deprecation of Type 0 Routing Headers in IPv6 J. Abley P. Savola G. Neville-Neil December 2007 ASCII 13423 7 ipv6 type 0 routing header traffic amplification

The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK]

draft-ietf-ipv6-deprecate-rh0-01 RFC2460 RFC4294 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC5095
RFC5096 Mobile IPv6 Experimental Messages V. Devarapalli December 2007 ASCII 13669 7 mip6 mobility header mobility option mipv6

This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. [STANDARDS-TRACK]

draft-ietf-mip6-experimental-messages-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5096
RFC5097 MIB for the UDP-Lite protocol G. Renker G. Fairhurst January 2008 ASCII 48944 23 SMIv2 UDPLITE-MIB management information base lightweight user datagram protocol

This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite). It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP-Lite resembles UDP, but differs from the semantics of UDP by the addition of a single option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. [STANDARDS-TRACK]

draft-ietf-tsvwg-udplite-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5097
RFC5098 Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) G. Beacham S. Kumar S. Channabasappa February 2008 ASCII 159415 79 PKTC-IETF-SIG-MIB snmp simple network management protocol packetcable-compliant ipcablecom-compliant

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

draft-ietf-ipcdn-pktc-signaling-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn http://www.rfc-editor.org/errata_search.php?rfc=5098 10.17487/RFC5098
RFC5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information B. Claise Editor January 2008 ASCII 147196 63 exporting process collecting process template records

This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. [STANDARDS-TRACK]

draft-ietf-ipfix-protocol-26 RFC7011 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5101 10.17487/RFC5101
RFC5102 Information Model for IP Flow Information Export J. Quittek S. Bryant B. Claise P. Aitken J. Meyer January 2008 ASCII 335617 171 ipfix ip flow information export protocol measured traffic observation point metering process exporting process

This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. [STANDARDS-TRACK]

draft-ietf-ipfix-info-15 RFC7012 RFC6313 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5102 10.17487/RFC5102
RFC5103 Bidirectional Flow Export Using IP Flow Information Export (IPFIX) B. Trammell E. Boschi January 2008 ASCII 53534 24 flow record biflow

This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK]

draft-ietf-ipfix-biflow-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5103 10.17487/RFC5103
RFC5104 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) S. Wenger U. Chandra M. Westerlund B. Burman February 2008 ASCII 158098 64 real time protocol real-time protocol itu-t rec. h271 video back channel full intra request temporary maximum media stream bit rate temporal-spatial trade-off

This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.

The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]

draft-ietf-avt-avpf-ccm-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5104
RFC5105 ENUM Validation Token Format Definition O. Lendl December 2007 ASCII 33057 17 telephone number mapping e.164

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes a signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. [STANDARDS-TRACK]

draft-ietf-enum-validation-token-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5105
RFC5106 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method H. Tschofenig D. Kroeselberg A. Pashalidis Y. Ohba F. Bersani February 2008 ASCII 76645 33 cryptographic ciphersuite negotiation hash function agility identity confidentiality fragmentation fast reconnect mode

This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode. This memo defines an Experimental Protocol for the Internet community.

draft-tschofenig-eap-ikev2-15 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5106 10.17487/RFC5106
RFC5107 DHCP Server Identifier Override Suboption R. Johnson J. Kumarasamy K. Kinnear M. Stapp February 2008 ASCII 14837 7 xml extensible markup langauge dynamic host configuration protocol RENEW DHCPREQUEST DHCP RENEW

This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages. [STANDARDS-TRACK]

draft-ietf-dhc-server-override-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5107
RFC5109 RTP Payload Format for Generic Forward Error Correction A. Li Editor December 2007 ASCII 100538 44 fec realtime transport protocol

This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. [STANDARDS-TRACK]

draft-ietf-avt-ulp-23 RFC2733 RFC3009 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5109 10.17487/RFC5109
RFC5110 Overview of the Internet Multicast Routing Architecture P. Savola January 2008 ASCII 56217 25 RFC 3913 RFC 2189 RFC 2201 RFC 1584

This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.

This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. This memo provides information for the Internet community.

draft-ietf-mboned-routingarch-12 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC5110
RFC5111 Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF) B. Aboba L. Dondeti January 2008 ASCII 16740 8 working group formation bof birds of a feather

This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. Exploratory Groups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather (BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension. This memo defines an Experimental Protocol for the Internet community.

draft-aboba-sg-experiment-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5111
RFC5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) M. Garcia-Martin January 2008 ASCII 67257 25 communication session event notification presence

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by using Signaling Compression (SigComp), which is enhanced by using the SIP/ Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent. [STANDARDS-TRACK]

draft-garcia-simple-presence-dictionary-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5112
RFC5113 Network Discovery and Selection Problem J. Arkko B. Aboba J. Korhonen Editor F. Bari January 2008 ASCII 93250 39

When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub- problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed. This memo provides information for the Internet community.

draft-ietf-eap-netsel-problem-09 INFORMATIONAL INFORMATIONAL IETF int eap 10.17487/RFC5113
RFC5114 Additional Diffie-Hellman Groups for Use with IETF Standards M. Lepinski S. Kent January 2008 ASCII 49565 23 elliptic curve ike tls ssh smime x.509

This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE).

All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography.

These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal Information Processing Standard (FIPS) validation of implementations that make use of these groups. This memo provides information for the Internet community.

draft-lepinski-dh-groups-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5114
RFC5115 Telephony Routing over IP (TRIP) Attribute for Resource Priority K. Carlberg P. O'Hanlon January 2008 ASCII 17194 8 ip telephony ResourcePriority

This document defines a new attribute for the Telephony Routing over IP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. [STANDARDS-TRACK]

draft-carlberg-trip-attribute-rp-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5115 10.17487/RFC5115
RFC5116 An Interface and Algorithms for Authenticated Encryption D. McGrew January 2008 ASCII 50539 22 Encryption Authentication AEAD authenticated encryption with associated data

This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]

draft-mcgrew-auth-enc-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5116 10.17487/RFC5116
RFC5117 RTP Topologies M. Westerlund S. Wenger January 2008 ASCII 50293 21 multi-endpoint topologies real-time transport protocol

This document discusses multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This memo provides information for the Internet community.

draft-ietf-avt-topologies-07 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5117 10.17487/RFC5117
RFC5118 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) V. Gurbani C. Boulton R. Sparks February 2008 ASCII 31829 18 Torture test IPv6 SIP

This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of an IPv6-enabled SIP implementation. This memo provides information for the Internet community.

draft-ietf-sipping-ipv6-torture-tests-04 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5118 10.17487/RFC5118
RFC5119 A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE) T. Edwards February 2008 ASCII 17024 9 persistent resources universal labels,

This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages. A subnamespace for Universal Labels is specifically described. This memo provides information for the Internet community.

draft-edwards-urn-smpte-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5119 10.17487/RFC5119
RFC5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) T. Przygienda N. Shen N. Sheth February 2008 ASCII 30318 14 is-is

This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]

draft-ietf-isis-wg-multi-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5120
RFC5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks B. Patil F. Xia B. Sarikaya JH. Choi S. Madanapalli February 2008 ASCII 50092 22 Neighbor Discovery Per-MS Perfix

IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN CSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. [STANDARDS-TRACK]

draft-ietf-16ng-ipv6-over-ipv6cs-11 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng http://www.rfc-editor.org/errata_search.php?rfc=5121 10.17487/RFC5121
RFC5122 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre February 2008 ASCII 55566 26 Extensible Messaging and Presence Protocol Internationalized Resource Identifier Uniform Resource Identifier Jabber xmpp iri uri

This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

draft-saintandre-rfc4622bis-01 RFC4622 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5122
RFC5123 Considerations in Validating the Path in BGP R. White B. Akyol February 2008 ASCII 39948 16 bgp autonomous system path bgp as path

This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path. This memo provides information for the Internet community.

draft-white-pathconsiderations-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5123 10.17487/RFC5123
RFC5124 Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) J. Ott E. Carrara February 2008 ASCII 37856 18 avpf rtp communication

An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK]

draft-ietf-avt-profile-savpf-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5124
RFC5125 Reclassification of RFC 3525 to Historic T. Taylor February 2008 ASCII 6646 4 MEGACO H.248 media gateway control

This document reclassifies RFC 3525, Gateway Control Protocol Version 1, to Historic Status. This memo also obsoletes RFC 3525. This memo provides information for the Internet community.

draft-taylor-megaco-obsol3525-01 RFC3525 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5125
RFC5126 CMS Advanced Electronic Signatures (CAdES) D. Pinkas N. Pope J. Ross March 2008 ASCII 309173 141 verifying party signer purchase contract invoice application smart cards data

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates) the validity of the signature.

The format can be considered as an extension to RFC 3852 and RFC 2634, where, when appropriate, additional signed and unsigned attributes have been defined.

The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced Electronic Signatures -- CAdES) and is technically equivalent to it.

The technical contents of this specification are maintained by ETSI. The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx This memo provides information for the Internet community.

draft-ietf-smime-cades-07 RFC3126 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5126
RFC5127 Aggregation of Diffserv Service Classes K. Chan J. Babiarz F. Baker February 2008 ASCII 43751 19 Treatment Aggregate forwarding treatment

In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments. This memo provides information for the Internet community.

draft-ietf-tsvwg-diffserv-class-aggr-07 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5127
RFC5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) P. Srisuresh B. Ford D. Kegel March 2008 ASCII 81008 32

This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP- and UDP-based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. This memo provides information for the Internet community.

draft-ietf-behave-p2p-state-06 INFORMATIONAL INFORMATIONAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5128 10.17487/RFC5128
RFC5129 Explicit Congestion Marking in MPLS B. Davie B. Briscoe J. Tay January 2008 ASCII 49496 21 Diffserv Differentiated Services QOS ECN tunnel

RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. [STANDARDS-TRACK]

draft-ietf-tsvwg-ecn-mpls-02 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5129
RFC5130 A Policy Control Mechanism in IS-IS Using Administrative Tags S. Previdi M. Shand Editor C. Martin February 2008 ASCII 16284 8 intermediate systetm to intermediate system ip prefix distribution lsp link state protocol

This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. [STANDARDS-TRACK]

draft-ietf-isis-admin-tags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5130
RFC5131 A MIB Textual Convention for Language Tags D. McWalter Editor December 2007 ASCII 11119 6 LANGTAG-TC-MIB

This MIB module defines a textual convention to represent BCP 47 language tags. The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. [STANDARDS-TRACK]

draft-mcwalter-langtag-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5131
RFC5132 IP Multicast MIB D. McWalter D. Thaler A. Kessler December 2007 ASCII 120340 59 managament information base IPMCAST-MIB,

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing multicast function, independent of the specific multicast protocol(s) in use. This document obsoletes RFC 2932. [STANDARDS-TRACK]

draft-ietf-mboned-ip-mcast-mib-07 RFC2932 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC5132
RFC5133 Terminal Endpoint Identifier (TEI) Query Request Number Change M. Tuexen K. Morneault December 2007 ASCII 7279 4 isdn q.921-user adaptation layer iua

The Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer (IUA) Protocol, described in RFC 4233, defines the message type of Terminal Endpoint Identifier (TEI) Query Request messages as 5. However, this number is already being used by the Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129. This document updates RFC 4233 such that the message type of TEI Query Request messages is 8. [STANDARDS-TRACK]

draft-ietf-sigtran-rfc4233update-02 RFC4233 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC5133
RFC5134 A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards M. Mealling January 2008 ASCII 18352 10 uniform resource name Auto-ID RFID EPCglobal EPC UPC supply chain management bar code

This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications. This memo provides information for the Internet community.

draft-mealling-epc-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5134 10.17487/RFC5134
RFC5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) D. Wing T. Eckert February 2008 ASCII 36528 16 multicast application multicast nat

This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-multicast-12 BCP0135 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5135 10.17487/RFC5135
RFC5136 Defining Network Capacity P. Chimento J. Ishac February 2008 ASCII 30682 14 bandwidth bandwidth estimation capacity estimation link capacity available capacity narrow link tight link

Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. This memo provides information for the Internet community.

draft-ietf-ippm-bw-capacity-05 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5136
RFC5137 ASCII Escaping of Unicode Characters J. Klensin February 2008 ASCII 27742 13 Text internationalization ascii unicode utf-8 encoding

There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klensin-unicode-escapes-07 BCP0137 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5137
RFC5138 A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI) S. Cox February 2008 ASCII 15005 8

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Commission for the Management and Application of Geoscience Information (CGI) for naming (i) persistent resources published by the CGI and (ii) resources published by organizations that wish them to be used in the context of services conforming to protocols and agreements issued by CGI. The formal Namespace Identifier (NID) is "cgi". This memo provides information for the Internet community.

draft-sjdcox-cgi-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5138
RFC5139 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) M. Thomson J. Winterbottom February 2008 ASCII 27470 14 location civic location pidf-lo civic address

This document defines an XML format for the representation of civic location. This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. [STANDARDS-TRACK]

draft-ietf-geopriv-revised-civic-lo-07 RFC4119 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5139
RFC5140 A Telephony Gateway REgistration Protocol (TGREP) M. Bangalore R. Kumar J. Rosenberg H. Salama D.N. Shah March 2008 ASCII 59511 28 telephony prefix soft switches telephony routing over ip trip internet telephony administrative domains itad

This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. [STANDARDS-TRACK]

draft-ietf-iptel-tgrep-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=5140 10.17487/RFC5140
RFC5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) J. Goodwin H. Apel March 2008 ASCII 57820 28 urn nid uniform resource name namespace identification NSS

This document describes a Uniform Resource Name Namespace Identification (URN NID) for the International Organization for Standardization (ISO). This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources). This memo provides information for the Internet community.

draft-goodwin-iso-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5141
RFC5142 Mobility Header Home Agent Switch Message B. Haley V. Devarapalli H. Deng J. Kempf January 2008 ASCII 27460 13

This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent. [STANDARDS-TRACK]

draft-ietf-mip6-ha-switch-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5142
RFC5143 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation A. Malis J. Brayley J. Shirron L. Martini S. Vogelsang February 2008 ASCII 52534 24 psn packet switched network RFC4842

This document describes a historical method for encapsulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Path signals for transport across packet-switched networks (PSNs). The PSNs explicitly supported by this document include MPLS and IP. Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired. This memo defines a Historic Document for the Internet community.

draft-malis-sonet-ces-mpls-09 RFC4842 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5143
RFC5144 A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS) A. Newton M. Sanz February 2008 ASCII 30063 17 dreg iris domain registry

This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service. [STANDARDS-TRACK]

draft-ietf-crisp-iris-dchk-09 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=5144 10.17487/RFC5144
RFC5145 Framework for MPLS-TE to GMPLS Migration K. Shiomoto Editor March 2008 ASCII 44646 19 multiprotocol label switching traffic engineering control plane

The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.

This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.

This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. This memo provides information for the Internet community.

draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5145
RFC5146 Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks K. Kumaki Editor March 2008 ASCII 31624 15 multiprotocol label switching traffic engineering service provider requirements

Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer).

The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP.

This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. This memo provides information for the Internet community.

draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5146
RFC5147 URI Fragment Identifiers for the text/plain Media Type E. Wilde M. Duerst April 2008 ASCII 37422 17 uniform resource identifier mime entity

This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust. [STANDARDS-TRACK]

draft-wilde-text-fragment-09 RFC2046 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5147
RFC5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs) T. Clausen C. Dearlove B. Adamson February 2008 ASCII 26379 12 randomly modifying timing control traffic transmission tranmission collision

This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions. This memo provides information for the Internet community.

draft-ietf-manet-jitter-04 INFORMATIONAL INFORMATIONAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5148 10.17487/RFC5148
RFC5149 Service Selection for Mobile IPv6 J. Korhonen U. Nilsson V. Devarapalli February 2008 ASCII 18746 9 mipv6 service selection mobility option proxy mobile ipv6 mobilty service subscription binding registration procedure

In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This memo provides information for the Internet community.

draft-korhonen-mip6-service-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5149
RFC5150 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) A. Ayyangar K. Kompella JP. Vasseur A. Farrel February 2008 ASCII 47099 19 lsp label switched paths e2e lsp lsp stitching lsp segments s-lsp

In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).

This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.

It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]

draft-ietf-ccamp-lsp-stitching-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5150 10.17487/RFC5150
RFC5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions A. Farrel Editor A. Ayyangar JP. Vasseur February 2008 ASCII 56663 25 multiprotocol label switching mpls-te

This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries.

For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK]

draft-ietf-ccamp-inter-domain-rsvp-te-07 RFC3209 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5151 10.17487/RFC5151
RFC5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) JP. Vasseur Editor A. Ayyangar Editor R. Zhang February 2008 ASCII 50563 21 mpls gmpls

This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.

Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. [STANDARDS-TRACK]

draft-ietf-ccamp-inter-domain-pd-path-comp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5152
RFC5153 IP Flow Information Export (IPFIX) Implementation Guidelines E. Boschi L. Mark J. Quittek M. Stiemerling P. Aitken April 2008 ASCII 82845 35 template mangaement exporting processes collecting processes ipfix middleboxes

The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). This memo provides information for the Internet community.

draft-ietf-ipfix-implementation-guidelines-08 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5153 10.17487/RFC5153
RFC5154 IP over IEEE 802.16 Problem Statement and Goals J. Jee Editor S. Madanapalli J. Mandin April 2008 ASCII 29853 14 WiMAX Mobile WiMAX WiBro

This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media Access Control (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented. This memo provides information for the Internet community.

draft-ietf-16ng-ps-goals-04 INFORMATIONAL INFORMATIONAL IETF int 16ng 10.17487/RFC5154
RFC5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence B. Laurie G. Sisson R. Arends D. Blacka March 2008 ASCII 112338 52 domain name system nsec resource record nsec3

The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]

draft-ietf-dnsext-nsec3-13 RFC6840 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=5155 10.17487/RFC5155
RFC5156 Special-Use IPv6 Addresses M. Blanchet April 2008 ASCII 11931 7 invalid routing prefix

This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets. It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. This memo provides information for the Internet community.

draft-ietf-v6ops-rfc3330-for-ipv6-04 RFC6890 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5156
RFC5157 IPv6 Implications for Network Scanning T. Chown March 2008 ASCII 29054 13 subnet address space

The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. This memo provides information for the Internet community.

draft-ietf-v6ops-scanning-implications-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5157
RFC5158 6to4 Reverse DNS Delegation Specification G. Huston March 2008 ASCII 25536 12 dns domain name system

This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block. This memo provides information for the Internet community.

draft-huston-6to4-reverse-dns-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5158 10.17487/RFC5158
RFC5159 Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection L. Dondeti Editor A. Jerichow March 2008 ASCII 13921 8 SDP IANA registration OMA BCAST

This document provides descriptions of Session Description Protocol (SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. This memo provides information for the Internet community.

draft-dondeti-oma-mmusic-sdp-attrs-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5159
RFC5160 Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS) P. Levis M. Boucadair March 2008 ASCII 44317 19 sls bgp peering diffserv parallel internet

This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It proposes a new concept denoted by Meta-QoS-Class (MQC). This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers. It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. This memo provides information for the Internet community.

draft-levis-provider-qos-agreement-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5160
RFC5161 The IMAP ENABLE Extension A. Gulbrandsen Editor A. Melnikov Editor March 2008 ASCII 12220 7 Internet Message Access Protocol

Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. [STANDARDS-TRACK]

draft-gulbrandsen-imap-enable-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5161
RFC5162 IMAP4 Extensions for Quick Mailbox Resynchronization A. Melnikov D. Cridland C. Wilson March 2008 ASCII 51620 23 Internet Message Access Protocol

This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). [STANDARDS-TRACK]

draft-ietf-lemonade-reconnect-client-06 RFC7162 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5162 10.17487/RFC5162
RFC5163 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) G. Fairhurst B. Collini-Nocker April 2008 ASCII 42935 18 digital video broadcasting dvb mpeg-2 ts-concat pdu-concat timestamp

This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326.

The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications. [STANDARDS-TRACK]

draft-ietf-ipdvb-ule-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ipdvb 10.17487/RFC5163
RFC5164 Mobility Services Transport: Problem Statement T. Melia Editor March 2008 ASCII 33726 16 intelligent access selection ip handover mechanism

There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF. This document presents a problem statement for this core problem. This memo provides information for the Internet community.

draft-ietf-mipshop-mis-ps-05 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5164
RFC5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC) C. Reed April 2008 ASCII 14681 7 location geospatial namespace OGC URN Open Geospatial Consortium

This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal Namespace IDentifier (NID) is "ogc". This memo provides information for the Internet community.

draft-creed-ogc-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5165
RFC5166 Metrics for the Evaluation of Congestion Control Mechanisms S. Floyd Editor March 2008 ASCII 53609 23 transport protocol transport modeling research group tmrg

This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.

This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric. This memo provides information for the Internet community.

draft-irtf-tmrg-metrics-11 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5166
RFC5167 Media Server Control Protocol Requirements M. Dolly R. Even March 2008 ASCII 17147 9 logical entities mcp interactive voice response conferencing media services

This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.

This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services. This memo provides information for the Internet community.

draft-ietf-mediactrl-requirements-04 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC5167
RFC5168 XML Schema for Media Control O. Levin R. Even P. Hagendorf March 2008 ASCII 17845 10 extensible markup language video fast update

This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. This memo provides information for the Internet community.

draft-levin-mmusic-xml-media-control-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5168
RFC5169 Handover Key Management and Re-Authentication Problem Statement T. Clancy M. Nakhjiri V. Narayanan L. Dondeti March 2008 ASCII 34082 15 hokey handover key management fast re-authentication mobility

This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover. This memo provides information for the Internet community.

draft-ietf-hokey-reauth-ps-09 INFORMATIONAL INFORMATIONAL IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5169 10.17487/RFC5169
RFC5170 Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes V. Roca C. Neumann D. Furodet June 2008 ASCII 68567 33 LDPC FEC

This document describes two Fully-Specified Forward Error Correction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). These systematic FEC codes belong to the well- known class of "Low Density Parity Check" codes, and are large block FEC codes in the sense of RFC 3453. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-ldpc-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5170
RFC5171 Cisco Systems UniDirectional Link Detection (UDLD) Protocol M. Foschiano April 2008 ASCII 28149 13 Ethernet switches LAN IEEE 802 spanning tree STP FEFI autonegotiation

This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms.

This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization. This memo provides information for the Internet community.

draft-foschiano-udld-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5171
RFC5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol S. Varada Editor March 2008 ASCII 14646 7 IPv6-PPP internet protocol point-to-point ipv6

The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.

This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]

draft-ietf-ipv6-compression-nego-v2-02 RFC2472 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5172
RFC5173 Sieve Email Filtering: Body Extension J. Degener P. Guenther April 2008 ASCII 17429 10 search full text email

This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. [STANDARDS-TRACK]

draft-ietf-sieve-body-09 RFC5229 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5173
RFC5174 A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU) J-P. Evain May 2008 ASCII 13732 8 EBU namespace urn broadcast metadata classification schema

This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the EBU. This memo provides information for the Internet community.

draft-evain-ebu-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5174
RFC5175 IPv6 Router Advertisement Flags Option B. Haberman Editor R. Hinden March 2008 ASCII 12463 7 neighbor discovery protocol ndp expanded flags option efo ndp router advertisement message

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the number of flag bits available. [STANDARDS-TRACK]

RFC5075 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC5175
RFC5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) M. Chiba G. Dommety M. Eklund D. Mitton B. Aboba January 2008 ASCII 79541 34 user session

This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.

draft-ietf-radext-rfc3576bis-13 RFC3576 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5176 10.17487/RFC5176
RFC5177 Network Mobility (NEMO) Extensions for Mobile IPv4 K. Leung G. Dommety V. Narayanan A. Petrescu April 2008 ASCII 56094 26 NEMOv4 Mobile Networks Moving Networks Mobile Router Local Fixed Node Prefix Table Mobile Network Prefix Nested Mobile Networks Nested Network Mobility

This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function.

Extensions to Mobile IPv4 are introduced to support Mobile Networks. [STANDARDS-TRACK]

draft-ietf-mip4-nemo-v4-base-11 RFC6626 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC5177
RFC5178 Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type N. Williams A. Melnikov May 2008 ASCII 17262 9 domain-based-name gss-domain-based-services GSS_C_NT_DOMAINBASED_SERVICE

This document describes domain-name-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.

Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. [STANDARDS-TRACK]

draft-ietf-kitten-gssapi-domain-based-names-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5178
RFC5179 Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism N. Williams May 2008 ASCII 8017 5 domain-name-based GSS_C_NT_DOMAINBASED_SERVICE

This document describes the mapping of Generic Security Service Application Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names. [STANDARDS-TRACK]

draft-ietf-kitten-krb5-gssapi-domain-based-names-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5179
RFC5180 IPv6 Benchmarking Methodology for Network Interconnect Devices C. Popoviciu A. Hamza G. Van de Velde D. Dugatkin May 2008 ASCII 41712 20 rfc2544 ipv6 benchmarking guidelines

The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document. This memo provides information for the Internet community.

draft-ietf-bmwg-ipv6-meth-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=5180 10.17487/RFC5180
RFC5181 IPv6 Deployment Scenarios in 802.16 Networks M-K. Shin Editor Y-H. Han S-E. Kim D. Premec May 2008 ASCII 36671 16 Ethernet CS (Convergence Sublayer) IPv6 CS (Convergence Sublayer)

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies. This memo provides information for the Internet community.

draft-ietf-v6ops-802-16-deployment-scenarios-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5181
RFC5182 IMAP Extension for Referencing the Last SEARCH Result A. Melnikov March 2008 ASCII 24520 13 uid unique identifier searchres internet message access protocol

Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.

This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.

This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command. [STANDARDS-TRACK]

draft-melnikov-imap-search-res-07 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5182
RFC5183 Sieve Email Filtering: Environment Extension N. Freed May 2008 ASCII 16950 10 vnd

This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. [STANDARDS-TRACK]

draft-freed-sieve-environment-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5183
RFC5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover F. Teraoka K. Gogo K. Mitsuya R. Shibui K. Mitani May 2008 ASCII 64137 29 l2 triggers primitives l3-driven fast handover ip mobility optimizations mobopts

This document proposes unified Layer 2 (L2) abstractions for Layer 3 (L3)-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers. This document defines nine kinds of L2 abstractions in the form of "primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-mobopts-l2-abstractions-07 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5184
RFC5185 OSPF Multi-Area Adjacency S. Mirtorabi P. Psenak A. Lindem Editor A. Oswal May 2008 ASCII 18698 11 open shortest path first inter-area intra-area path

This document describes an extension to the Open Shortest Path First (OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra- area path in each of the corresponding areas sharing the same link. [STANDARDS-TRACK]

draft-ietf-ospf-multi-area-adj-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5185 10.17487/RFC5185
RFC5186 Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction B. Haberman J. Martin May 2008 ASCII 12403 6 source information source-filtering group management

The definitions of the Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information. This document describes how multicast routing protocols will interact with these source-filtering group management protocols. This memo provides information for the Internet community.

draft-ietf-magma-igmpv3-and-routing-05 INFORMATIONAL INFORMATIONAL IETF int magma 10.17487/RFC5186
RFC5187 OSPFv3 Graceful Restart P. Pillay-Esnault A. Lindem June 2008 ASCII 14860 7 open shortest path first

This document describes the OSPFv3 graceful restart. The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document. These differences include the format of the grace Link State Advertisements (LSAs) and other considerations. [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-graceful-restart-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5187 10.17487/RFC5187
RFC5188 RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec H. Desineni Q. Xie February 2008 ASCII 44821 25

This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and updates the media type registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as email. [STANDARDS-TRACK]

draft-ietf-avt-rtp-evrc-wb-09 RFC4788 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5188
RFC5189 Middlebox Communication (MIDCOM) Protocol Semantics M. Stiemerling J. Quittek T. Taylor March 2008 ASCII 161167 70 nat network address translator firewall

This document specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989. [STANDARDS-TRACK]

draft-ietf-midcom-rfc3989-bis-02 RFC3989 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC5189
RFC5190 Definitions of Managed Objects for Middlebox Communication J. Quittek M. Stiemerling P. Srisuresh March 2008 ASCII 204929 92 management information base mib midcom MIDCOM-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189. [STANDARDS-TRACK]

draft-ietf-midcom-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC5190
RFC5191 Protocol for Carrying Authentication for Network Access (PANA) D. Forsberg Y. Ohba Editor B. Patil H. Tschofenig A. Yegin May 2008 ASCII 96716 46 eap exensible authentication protocol

This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. [STANDARDS-TRACK]

draft-ietf-pana-pana-18 RFC5872 PROPOSED STANDARD PROPOSED STANDARD IETF int pana http://www.rfc-editor.org/errata_search.php?rfc=5191 10.17487/RFC5191
RFC5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents L. Morand A. Yegin S. Kumar S. Madanapalli May 2008 ASCII 14986 8 dynamic host configuration protocol pac pana client

This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents (PAAs). This is one of the methods that a PANA Client (PaC) can use to locate PAAs. [STANDARDS-TRACK]

draft-ietf-dhc-paa-option-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5192
RFC5193 Protocol for Carrying Authentication for Network Access (PANA) Framework P. Jayaraman R. Lopez Y. Ohba Editor M. Parthasarathy A. Yegin May 2008 ASCII 24474 11

This document defines the general Protocol for Carrying Authentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments. This memo provides information for the Internet community.

draft-ietf-pana-framework-10 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC5193
RFC5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) A. van Wijk Editor G. Gybels Editor June 2008 ASCII 68636 31 text telephone textphone deaf hard-of-hearing speech-impaired interactive text transcoding speech-to-text user alerting emergency services gateway analog terminal adapters PSTN interworking text presentation user alerting instant messaging conversation conversational text interactivity total conversation user requirements text gateway relay relay service text relay TTY text transport text interworking combination gateway

This document lists the essential requirements for real-time Text-over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks. This memo provides information for the Internet community.

draft-ietf-sipping-toip-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5194
RFC5195 BGP-Based Auto-Discovery for Layer-1 VPNs H. Ould-Brahim D. Fedyk Y. Rekhter June 2008 ASCII 21480 10 import route target l1vpn single-end provisioning

The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. [STANDARDS-TRACK]

draft-ietf-l1vpn-bgp-auto-discovery-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn 10.17487/RFC5195
RFC5196 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) M. Lonnfors K. Kiss September 2008 ASCII 58488 30 common presence data format cpp common profile for presence

Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP User Agent capabilities. [STANDARDS-TRACK]

draft-ietf-simple-prescaps-ext-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5196
RFC5197 On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions S. Fries D. Ignjatic June 2008 ASCII 76848 31 key management media stream security end-to-end SRTP

Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for \%real-time applications. In particular, it has been defined focusing on the support of the Secure \%Real-time Transport Protocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.

This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session Description Protocol (SDP) answer, forking, and shared key conferencing. This memo provides information for the Internet community.

draft-ietf-msec-mikey-applicability-09 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC5197
RFC5198 Unicode Format for Network Interchange J. Klensin M. Padlipsky March 2008 ASCII 45708 19 internationalized utf-8

The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]

draft-klensin-net-utf8-09 RFC0698 RFC0854 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5198 10.17487/RFC5198
RFC5201 Host Identity Protocol R. Moskowitz P. Nikander P. Jokela Editor T. Henderson April 2008 ASCII 240492 104 hip ip-layer state integrity protection optional encryption

This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-base-10 RFC7401 RFC6253 EXPERIMENTAL EXPERIMENTAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=5201 10.17487/RFC5201
RFC5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) P. Jokela R. Moskowitz P. Nikander April 2008 ASCII 68195 30 user data packets

This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-esp-06 RFC7402 EXPERIMENTAL EXPERIMENTAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=5202 10.17487/RFC5202
RFC5203 Host Identity Protocol (HIP) Registration Extension J. Laganier T. Koponen L. Eggert April 2008 ASCII 26620 13 register

This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-registration-02 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5203
RFC5204 Host Identity Protocol (HIP) Rendezvous Extension J. Laganier L. Eggert April 2008 ASCII 30233 15 hip registration extension hip nodes hip redezvous server

This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-rvs-05 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5204
RFC5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions P. Nikander J. Laganier April 2008 ASCII 34799 17 hip host identity protocol host identity payload dns domain name system

This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-dns-09 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5205
RFC5206 End-Host Mobility and Multihoming with the Host Identity Protocol P. Nikander T. Henderson Editor C. Vogt J. Arkko April 2008 ASCII 99430 40 hip multihoming extensions mobility extentions locator

This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-mm-05 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5206
RFC5207 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication M. Stiemerling J. Quittek L. Eggert April 2008 ASCII 27873 13 HIP host identity protocol host identity payload NAT traversal middlebox traversal firewall traversal ID locator split problem statement

The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group. This memo provides information for the Internet community.

draft-irtf-hiprg-nat-04 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5207
RFC5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 B. Kaliski May 2008 ASCII 12063 8 rsa laboratories private-key syntax change control

This document represents a republication of PKCS #8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.

This document describes a syntax for private-key information. This memo provides information for the Internet community.

draft-kaliski-pkcs8-00 RFC5958 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5208 10.17487/RFC5208
RFC5209 Network Endpoint Assessment (NEA): Overview and Requirements P. Sangster H. Khosravi M. Mani K. Narayan J. Tardo June 2008 ASCII 132227 53 Posture Remediation reassessment Validator Collector Broker compliance privacy disclosure replay trust policy

This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. This memo provides information for the Internet community.

draft-ietf-nea-requirements-07 INFORMATIONAL INFORMATIONAL IETF sec nea 10.17487/RFC5209
RFC5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience J. Wu J. Bi X. Li G. Ren K. Xu M. Williams June 2008 ASCII 58363 25 Source Address Validation Source Addressing Spoofing Network Security Testbed IPv6

Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. This memo defines an Experimental Protocol for the Internet community.

draft-wu-sava-testbed-experience-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5210
RFC5211 An Internet Transition Plan J. Curran July 2008 ASCII 17158 8

This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model. This memo provides information for the Internet community.

draft-jcurran-v6transitionplan-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5211
RFC5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) K. Shiomoto D. Papadimitriou JL. Le Roux M. Vigoureux D. Brungard July 2008 ASCII 70286 28 generalized mpls switching technology

Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.

In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-mln-reqs-11 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5212
RFC5213 Proxy Mobile IPv6 S. Gundavelli Editor K. Leung V. Devarapalli K. Chowdhury B. Patil August 2008 ASCII 226902 92 mobility management

Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. [STANDARDS-TRACK]

draft-ietf-netlmm-proxymip6-18 RFC6543 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm http://www.rfc-editor.org/errata_search.php?rfc=5213 10.17487/RFC5213
RFC5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin T. Gleeson D. Thaler March 2008 ASCII 30126 15 ipv6 ipv4 non-broadcast multiple access nbma dual-stack

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo provides information for the Internet community.

draft-templin-rfc4214bis-05 RFC4214 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5214
RFC5215 RTP Payload Format for Vorbis Encoded Audio L. Barbato August 2008 ASCII 54327 26 realtime transport protocol codebook

This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.

Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avt-rtp-vorbis-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5215 10.17487/RFC5215
RFC5216 The EAP-TLS Authentication Protocol D. Simon B. Aboba R. Hurst March 2008 ASCII 71599 34 extensible authentication protocol point-to-point link control compression extensible transport level security

The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.

This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]

draft-simon-emu-rfc2716bis-13 RFC2716 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu http://www.rfc-editor.org/errata_search.php?rfc=5216 10.17487/RFC5216
RFC5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability M. Shimaoka Editor N. Hastings R. Nielsen July 2008 ASCII 64814 29 pki multi-domain pki pki domain

The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi-domain PKI. This memo provides information for the Internet community.

draft-shimaoka-multidomain-pki-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5217
RFC5218 What Makes For a Successful Protocol? D. Thaler B. Aboba July 2008 ASCII 58409 28

The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community.

draft-iab-protocol-success-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5218
RFC5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio R. Finlayson February 2008 ASCII 42830 22 real time protocol real-time protocol mpeg moving picture experts group,

This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices. [STANDARDS-TRACK]

draft-ietf-avt-rfc3119bis-05 RFC3119 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5219
RFC5220 Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules A. Matsumoto T. Fujisaki R. Hiromi K. Kanayama July 2008 ASCII 33661 17 multiple prefixes

A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes. This memo provides information for the Internet community.

draft-ietf-v6ops-addr-select-ps-09 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=5220 10.17487/RFC5220
RFC5221 Requirements for Address Selection Mechanisms A. Matsumoto T. Fujisaki R. Hiromi K. Kanayama July 2008 ASCII 13732 7 default address selection

There are some problematic cases when using the default address selection mechanism that RFC 3484 defines. This document describes additional requirements that operate with RFC 3484 to solve the problems. This memo provides information for the Internet community.

draft-ietf-v6ops-addr-select-req-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5221
RFC5222 LoST: A Location-to-Service Translation Protocol T. Hardie A. Newton H. Schulzrinne H. Tschofenig August 2008 ASCII 123252 69 emergency services emergency call routing

This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS-TRACK]

draft-ietf-ecrit-lost-10 RFC6848 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5222 10.17487/RFC5222
RFC5223 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) H. Schulzrinne J. Polk H. Tschofenig August 2008 ASCII 14936 8 mapping service emergency service emergency communication

The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.

This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). [STANDARDS-TRACK]

draft-ietf-ecrit-dhc-lost-discovery-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC5223
RFC5224 Diameter Policy Processing Application M. Brenner March 2008 ASCII 10283 5 policy evaluation or evaluation and enforcement pem-1 peem oma open mobile alliance

This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation of Policy Processing (Policy Evaluation, or Evaluation and Enforcement). This application is needed as one of the implementations of the Open Mobile Alliance (OMA) Policy Evaluation, Enforcement and Management (PEEM) enabler, namely for the PEM-1 interface used to send a request/response for Policy Processing. This memo provides information for the Internet community.

draft-brenner-dime-peem-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5224
RFC5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite G. Pelletier K. Sandlund April 2008 ASCII 246120 124 rohc 3095 3843 4019

This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers.

This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.

The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation. [STANDARDS-TRACK]

draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5225 10.17487/RFC5225
RFC5226 Guidelines for Writing an IANA Considerations Section in RFCs T. Narten H. Alvestrand May 2008 ASCII 66160 27 internet assigned numbers authority values implementations code point protocol constant protocol parameter

Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).

In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.

This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-narten-iana-considerations-rfc2434bis-09 RFC2434 BCP0026 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5226 10.17487/RFC5226
RFC5227 IPv4 Address Conflict Detection S. Cheshire July 2008 ASCII 53548 21 internet protocol version 4

When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem. [STANDARDS-TRACK]

draft-cheshire-ipv4-acd-06 RFC0826 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5227
RFC5228 Sieve: An Email Filtering Language P. Guenther Editor T. Showalter Editor January 2008 ASCII 87531 42

This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. [STANDARDS-TRACK]

draft-ietf-sieve-3028bis-13 RFC3028 RFC5229 RFC5429 RFC6785 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5228
RFC5229 Sieve Email Filtering: Variables Extension K. Homme January 2008 ASCII 20023 11

In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables. The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. [STANDARDS-TRACK]

draft-ietf-sieve-variables-08 RFC5228 RFC5173 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5229
RFC5230 Sieve Email Filtering: Vacation Extension T. Showalter N. Freed Editor January 2008 ASCII 29822 16 autoresponder

This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. [STANDARDS-TRACK]

draft-ietf-sieve-vacation-06 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5230 10.17487/RFC5230
RFC5231 Sieve Email Filtering: Relational Extension W. Segmuller B. Leiba January 2008 ASCII 15243 9 relational operators

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields.

This document obsoletes RFC 3431. [STANDARDS-TRACK]

draft-ietf-sieve-3431bis-04 RFC3431 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5231
RFC5232 Sieve Email Filtering: Imap4flags Extension A. Melnikov January 2008 ASCII 21964 12 imap internet message access control protocol imap flags imap system flags imap keywords

Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent.

This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. [STANDARDS-TRACK]

draft-ietf-sieve-imapflags-05 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5232
RFC5233 Sieve Email Filtering: Subaddress Extension K. Murchison January 2008 ASCII 12448 7 subaddressing detailed addressing :user :detail

On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve Email Filtering Language that allows users to compare against the user and detail sub-parts of an address. [STANDARDS-TRACK]

draft-ietf-sieve-rfc3598bis-05 RFC3598 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5233 10.17487/RFC5233
RFC5234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell January 2008 ASCII 26359 16 ABNF backus-naur form augmented backus-naur form rule definitions encoding core lexical analyzer

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

draft-crocker-rfc4234bis-01 RFC4234 RFC7405 STD0068 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5234 10.17487/RFC5234
RFC5235 Sieve Email Filtering: Spamtest and Virustest Extensions C. Daboo January 2008 ASCII 25957 13 spamtest spamtestplus virustest scores

The Sieve email filtering language "spamtest", "spamtestplus", and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric "scores". It is the responsibility of the underlying Sieve implementation to do the actual checks that result in proper input to the tests. [STANDARDS-TRACK]

draft-ietf-sieve-spamtestbis-05 RFC3685 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5235
RFC5236 Improved Packet Reordering Metrics A. Jayasumana N. Piratla T. Banka A. Bare R. Whitner June 2008 ASCII 57805 26 reorder density rd reorder buffer-occupancy density rbd

This document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering.

These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. This memo provides information for the Internet community.

draft-jayasumana-reorder-density-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5236
RFC5237 IANA Allocation Guidelines for the Protocol Field J. Arkko S. Bradner February 2008 ASCII 9303 5 ipv4 header next header field internet assigned numbers authority IP

This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC 2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-arkko-rfc2780-proto-update-02 RFC2780 BCP0037 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5237 10.17487/RFC5237
RFC5238 Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) T. Phelan May 2008 ASCII 24394 10 tls transport protocol

This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK]

draft-ietf-dccp-dtls-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5238
RFC5239 A Framework for Centralized Conferencing M. Barnes C. Boulton O. Levin June 2008 ASCII 146927 57 call signaling call signalling

This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. [STANDARDS-TRACK]

draft-ietf-xcon-framework-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon http://www.rfc-editor.org/errata_search.php?rfc=5239 10.17487/RFC5239
RFC5240 Protocol Independent Multicast (PIM) Bootstrap Router MIB B. Joshi R. Bijlani June 2008 ASCII 42636 23 management information base bootstrap router bsr PIM-BSR-MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM (Protocol Independent Multicast). [STANDARDS-TRACK]

draft-ietf-pim-bsr-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5240 10.17487/RFC5240
RFC5241 Naming Rights in IETF Protocols A. Falk S. Bradner April 1 2008 ASCII 25304 12 april fools field naming rights

This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5241
RFC5242 A Generalized Unified Character Code: Western European and CJK Sections J. Klensin H. Alvestrand April 1 2008 ASCII 31314 14 idn latin greek cyrilllic chinese internationalized domain names

Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5242
RFC5243 OSPF Database Exchange Summary List Optimization R. Ogier May 2008 ASCII 11029 5

This document describes a backward-compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. This memo provides information for the Internet community.

draft-ogier-ospf-dbex-opt-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5243 10.17487/RFC5243
RFC5244 Definition of Events for Channel-Oriented Telephony Signalling H. Schulzrinne T. Taylor June 2008 ASCII 55321 23 event code telephony event rtp payload

This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833. [STANDARDS-TRACK]

draft-ietf-avt-rfc2833biscas-05 RFC4733 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5244
RFC5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols J. Rosenberg April 2010 ASCII 285120 117

This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]

draft-ietf-mmusic-ice-19 RFC4091 RFC4092 RFC6336 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5245 10.17487/RFC5245
RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 T. Dierks E. Rescorla August 2008 ASCII 222395 104 idea international data algorithm symmetric transport protocol layer authentication privacy

This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

draft-ietf-tls-rfc4346-bis-10 RFC3268 RFC4346 RFC4366 RFC4492 RFC5746 RFC5878 RFC6176 RFC7465 RFC7507 RFC7568 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5246 10.17487/RFC5246
RFC5247 Extensible Authentication Protocol (EAP) Key Management Framework B. Aboba D. Simon P. Eronen August 2008 ASCII 193535 79 extensible network access authentication key hierarchy methods

The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK]

draft-ietf-eap-keying-22 RFC3748 PROPOSED STANDARD PROPOSED STANDARD IETF int eap http://www.rfc-editor.org/errata_search.php?rfc=5247 10.17487/RFC5247
RFC5248 A Registry for SMTP Enhanced Mail System Status Codes T. Hansen J. Klensin June 2008 ASCII 23845 11 simple mail transfer protocol

The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes. While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hansen-4468upd-mailesc-registry-05 RFC3463 RFC4468 RFC4954 BCP0138 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5248
RFC5249 Templates for Internet-Drafts Containing MIB Modules D. Harrington Editor July 2008 ASCII 7362 4 network management management information base mib smiv2 template

This memo references three annotated templates for IETF documents that contain the definition of MIB modules. It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-harrington-text-mib-doc-template-06 BCP0139 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5249
RFC5250 The OSPF Opaque LSA Option L. Berger I. Bryskin A. Zinin R. Coltun July 2008 ASCII 37657 17 OSPF-LSA] open shortest path first link state advertisement opaque lsas

This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.

This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. [STANDARDS-TRACK]

draft-ietf-ospf-rfc2370bis-05 RFC2370 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5250 10.17487/RFC5250
RFC5251 Layer 1 VPN Basic Mode D. Fedyk Editor Y. Rekhter Editor D. Papadimitriou R. Rabbat L. Berger July 2008 ASCII 57599 24 virtual private network l1vpn l1vpn bm

This document describes the Basic Mode of Layer 1 VPNs (L1VPNs). L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. [STANDARDS-TRACK]

draft-ietf-l1vpn-basic-mode-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn http://www.rfc-editor.org/errata_search.php?rfc=5251 10.17487/RFC5251
RFC5252 OSPF-Based Layer 1 VPN Auto-Discovery I. Bryskin L. Berger July 2008 ASCII 23232 11 open shortest path first l1vpn layer 1 virtual private network

This document defines an Open Shortest Path First (OSPF) based Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations with L1VPNs. This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism. [STANDARDS-TRACK]

draft-ietf-l1vpn-ospf-auto-discovery-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn http://www.rfc-editor.org/errata_search.php?rfc=5252 10.17487/RFC5252
RFC5253 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode T. Takeda Editor July 2008 ASCII 42675 19 gmpls generalized multiprotocol label switching l1vpn bm

This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs).

L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. This memo provides information for the Internet community.

draft-ietf-l1vpn-applicability-basic-mode-05 INFORMATIONAL INFORMATIONAL IETF rtg l1vpn 10.17487/RFC5253
RFC5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) N. Bitar Editor M. Bocci Editor L. Martini Editor October 2008 ASCII 64584 27 Pseudowire PWE3 multi-segment MS-PW SS-PW S-PE T-PE

This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. This memo provides information for the Internet community.

draft-ietf-pwe3-ms-pw-requirements-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5254 10.17487/RFC5254
RFC5255 Internet Message Access Protocol Internationalization C. Newman A. Gulbrandsen A. Melnikov June 2008 ASCII 41403 20 imap imapv4 imap4

Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. [STANDARDS-TRACK]

draft-ietf-imapext-i18n-15 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=5255 10.17487/RFC5255
RFC5256 Internet Message Access Protocol - SORT and THREAD Extensions M. Crispin K. Murchison June 2008 ASCII 40779 19 ordered subject references imap capability

This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [STANDARDS-TRACK]

draft-ietf-imapext-sort-20 RFC5957 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext 10.17487/RFC5256
RFC5257 Internet Message Access Protocol - ANNOTATE Extension C. Daboo R. Gellens June 2008 ASCII 58786 31 imap

The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.

Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress.

Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-imapext-annotate-16 EXPERIMENTAL EXPERIMENTAL IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=5257 10.17487/RFC5257
RFC5258 Internet Message Access Protocol version 4 - LIST Command Extensions B. Leiba A. Melnikov June 2008 ASCII 65074 31 imap4 ,list lsub extended list email

IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. [STANDARDS-TRACK]

draft-ietf-imapext-list-extensions-18 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext 10.17487/RFC5258
RFC5259 Internet Message Access Protocol - CONVERT Extension A. Melnikov Editor P. Coates Editor July 2008 ASCII 63831 30 IMAP Lemonade CONVERT conversion transcoding

CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings. [STANDARDS-TRACK]

draft-ietf-lemonade-convert-20 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5259
RFC5260 Sieve Email Filtering: Date and Index Extensions N. Freed July 2008 ASCII 25735 13 smtp esmtp date index

This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. [STANDARDS-TRACK]

draft-freed-sieve-date-index-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5260 10.17487/RFC5260
RFC5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors J. Urpalainen September 2008 ASCII 78036 40

Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic &lt;add&gt;, &lt;replace&gt;, and &lt;remove&gt; directives a set of patches can then be applied to update an existing XML document. [STANDARDS-TRACK]

draft-ietf-simple-xml-patch-ops-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5261 10.17487/RFC5261
RFC5262 Presence Information Data Format (PIDF) Extension for Partial Presence M. Lonnfors E. Leppanen H. Khartabil J. Urpalainen September 2008 ASCII 28527 16

The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information. [STANDARDS-TRACK]

draft-ietf-simple-partial-pidf-format-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5262
RFC5263 Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information M. Lonnfors J. Costa-Requena E. Leppanen H. Khartabil September 2008 ASCII 32556 16 pidf presence information data format

By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. [STANDARDS-TRACK]

draft-ietf-simple-partial-notify-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5263
RFC5264 Publication of Partial Presence Information A. Niemi M. Lonnfors E. Leppanen September 2008 ASCII 30594 15

The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. [STANDARDS-TRACK]

draft-ietf-simple-partial-publish-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5264
RFC5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways S. Vaarala E. Klovning June 2008 ASCII 86254 39 mobile ip mobile ipv4 ipsec mipv4

This document outlines a solution for the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. [STANDARDS-TRACK]

draft-ietf-mip4-vpn-problem-solution-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC5265
RFC5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) V. Devarapalli P. Eronen June 2008 ASCII 33186 15

Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mip4-mobike-connectivity-03 BCP0136 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int mip4 10.17487/RFC5266
RFC5267 Contexts for IMAP4 D. Cridland C. King July 2008 ASCII 36709 18 imap4rev1 esort context

The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. [STANDARDS-TRACK]

draft-cridland-imap-context-05 RFC5465 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5267
RFC5268 Mobile IPv6 Fast Handovers R. Koodli Editor June 2008 ASCII 113090 48 mipv6 handover latency

Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. [STANDARDS-TRACK]

draft-ietf-mipshop-fmipv6-rfc4068bis-07 RFC4068 RFC5568 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5268
RFC5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND) J. Kempf R. Koodli June 2008 ASCII 32742 14 fast binding update

Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971). The Mobile Node sends the public key to the Access Router. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node. This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key. [STANDARDS-TRACK]

draft-ietf-mipshop-handover-key-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5269
RFC5270 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks H. Jang J. Jee Y. Han S. Park J. Cha June 2008 ASCII 42358 18 Mobile IPv6 Handover optimization Cross-layer design

This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently. This memo provides information for the Internet community.

draft-ietf-mipshop-fh80216e-07 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5270
RFC5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks H. Yokota G. Dommety June 2008 ASCII 49316 22 FMIP handoff 3GPP2

Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new Care-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover. This memo provides information for the Internet community.

draft-ietf-mipshop-3gfh-07 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5271
RFC5272 Certificate Management over CMS (CMC) J. Schaad M. Myers June 2008 ASCII 167138 83 certificate management protocol cryptographic message syntax pki public key infrastructure

This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:

1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and

2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.

CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]

draft-ietf-pkix-2797-bis-07 RFC2797 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5272 10.17487/RFC5272
RFC5273 Certificate Management over CMS (CMC): Transport Protocols J. Schaad M. Myers June 2008 ASCII 14030 7 cryptographic message syntax http file mail tcp

This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS-TRACK]

draft-ietf-pkix-cmc-trans-08 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5273 10.17487/RFC5273
RFC5274 Certificate Management Messages over CMS (CMC): Compliance Requirements J. Schaad M. Myers June 2008 ASCII 27380 13 cryptographic message syntax cmc enrollment protocol

This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. [STANDARDS-TRACK]

draft-ietf-pkix-cmc-compl-05 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5274
RFC5275 CMS Symmetric Key Management and Distribution S. Turner June 2008 ASCII 207920 89 cryptographic message syntax symmetric cryptographic algorithms certificate management over cms cmc

This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs). [STANDARDS-TRACK]

draft-ietf-smime-symkeydist-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5275 10.17487/RFC5275
RFC5276 Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records C. Wallace August 2008 ASCII 27422 13 ERS Evidence Record SCVP Server-based Certificate Validation Protocol PKI artifact preservation

The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs). [STANDARDS-TRACK]

draft-ietf-ltans-ers-scvp-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC5276
RFC5277 NETCONF Event Notifications S. Chisholm H. Trevino July 2008 ASCII 70878 35 XML Extensible Markup Language NETCONF Event Asynchronous Message Notification

This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF). This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. [STANDARDS-TRACK]

draft-ietf-netconf-notification-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC5277
RFC5278 IANA Registration of Enumservices for Voice and Video Messaging J. Livingood D. Troshynski July 2008 ASCII 39745 22 vmsg voicemsg videomsg unifmsg sip sips http https tel

This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type. [STANDARDS-TRACK]

draft-ietf-enum-vmsg-02 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5278
RFC5279 A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP) A. Monrad S. Loreto July 2008 ASCII 11582 7 nid namespace identifier 3gpp

This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the 3rd Generation Partnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team. This memo provides information for the Internet community.

draft-monrad-sipping-3gpp-urn-namespace-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5279 10.17487/RFC5279
RFC5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile D. Cooper S. Santesson S. Farrell S. Boeyen R. Housley W. Polk May 2008 ASCII 352580 151 X.509 v3 X.509 v2 certificate extensions

This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]

draft-ietf-pkix-rfc3280bis-11 RFC3280 RFC4325 RFC4630 RFC6818 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5280 10.17487/RFC5280
RFC5281 Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) P. Funk S. Blake-Wilson August 2008 ASCII 117059 51 EAP AAA Authentication TLS

EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community.

draft-funk-eap-ttls-v0-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5281 10.17487/RFC5281
RFC5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol D. Black D. McGrew August 2008 ASCII 42137 19 encryption cipher combined mode algorithms aes gcm advanced encryption standard in galois/counter mode aes ccm aes in couner with cbc-mac mode

An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol.

The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. [STANDARDS-TRACK]

draft-black-ipsec-ikev2-aead-modes-01 RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5282 10.17487/RFC5282
RFC5283 LDP Extension for Inter-Area Label Switched Paths (LSPs) B. Decraene JL. Le Roux I. Minei July 2008 ASCII 26534 12 LDP label mapping procedures longest-match prefix aggregation

To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP).

This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-interarea-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5283 10.17487/RFC5283
RFC5284 User-Defined Errors for RSVP G. Swallow A. Farrel August 2008 ASCII 17452 9 resource reservation protocol user_error_spec error_spec

The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.

This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-user-error-spec-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5284
RFC5285 A General Mechanism for RTP Header Extensions D. Singer H. Desineni July 2008 ASCII 36844 17 real-time transport protocol extmap

This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. [STANDARDS-TRACK]

draft-ietf-avt-rtp-hdrext-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5285
RFC5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates A. Atlas Editor A. Zinin Editor September 2008 ASCII 71027 31 FRR LFA recovery failure routing

This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]

draft-ietf-rtgwg-ipfrr-spec-base-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=5286 10.17487/RFC5286
RFC5287 Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks A. Vainshtein Y(J). Stein August 2008 ASCII 33070 16 pwe3 pseudowire emulation edge-to-edge tdmoip tdm options

This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS-TRACK]

draft-ietf-pwe3-tdm-control-protocol-extensi-07 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5287
RFC5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS J. Salowey A. Choudhury D. McGrew August 2008 ASCII 16468 8 advanced encryption standard transport layer security data origin confidentiality

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms. [STANDARDS-TRACK]

draft-ietf-tls-rsa-aes-gcm-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC5288
RFC5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) E. Rescorla August 2008 ASCII 12195 6 transport layer security mac algorithm

RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm. This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms. Eight use Hashed Message Authentication Code (HMAC) with SHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM). This memo provides information for the Internet community.

draft-ietf-tls-ecc-new-mac-07 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC5289
RFC5290 Comments on the Usefulness of Simple Best-Effort Traffic S. Floyd M. Allman July 2008 ASCII 48612 20 flow-rate fairness

This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document as Internet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping. While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best- effort traffic, not as *replacements* of simple best-effort traffic. A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where "flow-rate fairness" is defined by the goal of equal flow rates for different flows over the same path. This memo provides information for the Internet community.

draft-floyd-tsvwg-besteffort-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5290
RFC5291 Outbound Route Filtering Capability for BGP-4 E. Chen Y. Rekhter August 2008 ASCII 23949 12 border gatway protocol orf

This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker. [STANDARDS-TRACK]

draft-ietf-idr-route-filter-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5291 10.17487/RFC5291
RFC5292 Address-Prefix-Based Outbound Route Filter for BGP-4 E. Chen S. Sangli August 2008 ASCII 10429 6 orf border gateway protocol Address Prefix Outbound Route Filter

This document defines a new Outbound Router Filter (ORF) type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address-prefix-based route filtering. This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families. [STANDARDS-TRACK]

draft-ietf-idr-bgp-prefix-orf-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5292
RFC5293 Sieve Email Filtering: Editheader Extension J. Degener P. Guenther August 2008 ASCII 17674 9 addheadaer deleteheader

This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. [STANDARDS-TRACK]

draft-ietf-sieve-editheader-11 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5293
RFC5294 Host Threats to Protocol Independent Multicast (PIM) P. Savola J. Lingard August 2008 ASCII 26525 12 security threat analysis

This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts. This memo provides information for the Internet community.

draft-ietf-pim-lasthop-threats-04 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC5294
RFC5295 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) J. Salowey L. Dondeti V. Narayanan M. Nakhjiri August 2008 ASCII 45622 21 EAP keying EMSK DSRK DSUSRK Domain-Specific Key Derivation Usage-Specific Key Derivation

The Extensible Authentication Protocol (EAP) defined the Extended Master Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. [STANDARDS-TRACK]

draft-ietf-hokey-emsk-hierarchy-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5295 10.17487/RFC5295
RFC5296 EAP Extensions for EAP Re-authentication Protocol (ERP) V. Narayanan L. Dondeti August 2008 ASCII 98264 43 extensible authentication protocol authentication modes

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]

draft-ietf-hokey-erx-14 RFC6696 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5296 10.17487/RFC5296
RFC5297 Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) D. Harkins October 2008 ASCII 50374 26 authenticated encryption key wrapping key derivation block cipher pseudo-random function

This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption. This memo provides information for the Internet community.

draft-dharkins-siv-aes-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5297
RFC5298 Analysis of Inter-Domain Label Switched Path (LSP) Recovery T. Takeda Editor A. Farrel Editor Y. Ikejiri JP. Vasseur August 2008 ASCII 59894 26 mpls gmpls multi-domain environment end-to-end diverse Traffic Engineering LSPs

Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.

Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering".

This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. This memo provides information for the Internet community.

draft-ietf-ccamp-inter-domain-recovery-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5298 10.17487/RFC5298
RFC5301 Dynamic Hostname Exchange Mechanism for IS-IS D. McPherson N. Shen October 2008 ASCII 11740 6 intermediate system to intermediate system routers tlv name-to-systemID

RFC 2763 defined a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.

This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. [STANDARDS-TRACK]

draft-ietf-isis-rfc2763bis-00 RFC2763 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5301 10.17487/RFC5301
RFC5302 Domain-Wide Prefix Distribution with Two-Level IS-IS T. Li H. Smit T. Przygienda October 2008 ASCII 36742 16 intermediate system to intermediate system routers loops IP internet protocol

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966.

This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. [STANDARDS-TRACK]

draft-ietf-isis-rfc2966bis-03 RFC2966 RFC1195 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5302 10.17487/RFC5302
RFC5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies D. Katz R. Saluja D. Eastlake 3rd October 2008 ASCII 23203 11 intermediate system to intermediate system

The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.

Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router.

This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors. [STANDARDS-TRACK]

draft-ietf-isis-rfc3373bis-01 RFC3373 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5303 10.17487/RFC5303
RFC5304 IS-IS Cryptographic Authentication T. Li R. Atkinson October 2008 ASCII 24131 11 intermediate system to intermediate system IS-IS authentication MD5 HMAC-MD5 security routing iso international standards organization

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.

This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]

draft-ietf-isis-rfc3567bis-03 RFC3567 RFC1195 RFC6233 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5304
RFC5305 IS-IS Extensions for Traffic Engineering T. Li H. Smit October 2008 ASCII 35313 17 intermediate system to intermediate system te router lsp data units link state protocol data units

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]

draft-ietf-isis-te-bis-00 RFC3784 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5305
RFC5306 Restart Signaling for IS-IS M. Shand L. Ginsberg October 2008 ASCII 51234 22 intermediate system to intermediate system LSP database synchronization Link State Routing

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.

This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 3847. [STANDARDS-TRACK]

draft-ietf-isis-rfc3847bis-00 RFC3847 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5306
RFC5307 IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2008 ASCII 22619 12 intermediate system to intermediate system

This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]

draft-ietf-isis-rfc4205bis-00 RFC4205 RFC5305 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5307 10.17487/RFC5307
RFC5308 Routing IPv6 with IS-IS C. Hopps October 2008 ASCII 13324 7 intermediate system to intermediate system tlv osi

This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]

draft-ietf-isis-ipv6-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5308
RFC5309 Point-to-Point Operation over LAN in Link State Routing Protocols N. Shen Editor A. Zinin Editor October 2008 ASCII 21287 10 broadcast

The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. This memo provides information for the Internet community.

draft-ietf-isis-igp-p2p-over-lan-06 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC5309
RFC5310 IS-IS Generic Cryptographic Authentication M. Bhatia V. Manral T. Li R. Atkinson R. White M. Fanto February 2009 ASCII 24521 12 IS-IS Security HMAC-SHA Cryptographic Authentication

This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.

Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]

draft-ietf-isis-hmac-sha-07 RFC6233 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5310 10.17487/RFC5310
RFC5311 Simplified Extension of Link State PDU (LSP) Space for IS-IS D. McPherson Editor L. Ginsberg S. Previdi M. Shand February 2009 ASCII 23886 12

This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK]

draft-ietf-isis-wg-extlsp-05 RFC3786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5311
RFC5316 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering M. Chen R. Zhang X. Duan December 2008 ASCII 45408 19 multiprotocol label switching generalized mpls gmpls-te mpls-te isis-te flooding

This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation.

No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]

draft-ietf-ccamp-isis-interas-te-extension-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5316
RFC5317 Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile S. Bryant Editor L. Andersson Editor February 2009 ASCII 18367 10 PDF 1411313 ITU-T MPLS-TP JWT GMPLS agreement PWE3 OAM transport network

This RFC archives the report of the IETF - ITU-T Joint Working Team (JWT) on the application of MPLS to transport networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM (Operations, Administration, and Management), survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process. This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides). This memo provides information for the Internet community.

draft-bryant-mpls-tp-jwt-report-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5317 10.17487/RFC5317
RFC5318 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) J. Hautakorpi G. Camarillo December 2008 ASCII 24589 12 oma open mobile alliance push to talk over cellular poc

This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list. This memo provides information for the Internet community.

draft-hautakorpi-sipping-uri-list-handling-refused-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5318
RFC5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL) F. Templin Editor February 2010 ASCII 67712 29 virtual topologies mtu maximum transmission units

For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. This document defines an Experimental Protocol for the Internet community.

draft-templin-seal-23 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5320 10.17487/RFC5320
RFC5321 Simple Mail Transfer Protocol J. Klensin October 2008 ASCII 225929 95 SMTP]

This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]

draft-klensin-rfc2821bis-11 RFC2821 RFC1123 RFC7504 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5321 10.17487/RFC5321
RFC5322 Internet Message Format P. Resnick Editor October 2008 ASCII 122322 57 MAIL] e-mail email electronic mail header address mailbox reply forward resend resent folding Date From Sender Reply-To To Cc Bcc Message-ID In-Reply-To References Subject Comments Keywords Resent-Date Resent-From Resent-Sender Resent-To Resent-Cc Resent-Bcc Resent-Reply-To Resent-Message-ID Return-Path Received

This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]

draft-resnick-2822upd-06 RFC2822 RFC4021 RFC6854 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5322 10.17487/RFC5322
RFC5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH J. Reschke Editor S. Reddy J. Davis A. Babich November 2008 ASCII 91077 49 HTTP Query Properties

This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. [STANDARDS-TRACK]

draft-reschke-webdav-search-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5323
RFC5324 MIB for Fibre-Channel Security Protocols (FC-SP) C. DeSanti F. Maino K. McCloghrie September 2008 ASCII 449246 216 management information base T11-FC-SP-TC-MIB T11-FC-SP-AUTHENTICATION-MIB T11-FC-SP-ZONING-MIB T11-FC-SP-POLICY-MIB T11-FC-SP-SA-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to FC-SP, the Security Protocols defined for Fibre Channel. [STANDARDS-TRACK]

draft-ietf-imss-fc-fcsp-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC5324
RFC5325 Licklider Transmission Protocol - Motivation S. Burleigh M. Ramadas S. Farrell September 2008 ASCII 57016 23 ltp round-trip times long-haul

This document describes the motivation for the development of the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.

In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes.

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-ltp-motivation-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5325
RFC5326 Licklider Transmission Protocol - Specification M. Ramadas S. Burleigh S. Farrell September 2008 ASCII 120567 54 ltp round-trip times rtt long-haul

This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-ltp-10 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5326 10.17487/RFC5326
RFC5327 Licklider Transmission Protocol - Security Extensions S. Farrell M. Ramadas S. Burleigh September 2008 ASCII 23269 11 ltp radio frequency automatic repeat request arq

The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-ltp-extensions-08 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5327
RFC5328 A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) A. Adolf P. MacAvock September 2008 ASCII 26369 12 tv television digital television mpeg-2 iptv multimedia content guide program guide metadata

This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. This memo provides information for the Internet community.

draft-adolf-dvb-urn-05 RFC7354 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5328 10.17487/RFC5328
RFC5329 Traffic Engineering Extensions to OSPF Version 3 K. Ishiguro V. Manral A. Davey A. Lindem Editor September 2008 ASCII 25864 12 open shortest path first ospfv3 te

This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-traffic-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5329
RFC5330 A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link JP. Vasseur Editor M. Meyer K. Kumaki A. Bonda October 2008 ASCII 15730 8 te lsp

Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth (referred to as "unconstrained TE LSP" in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link. [STANDARDS-TRACK]

draft-ietf-mpls-number-0-bw-te-lsps-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5330
RFC5331 MPLS Upstream Label Assignment and Context-Specific Label Space R. Aggarwal Y. Rekhter E. Rosen August 2008 ASCII 30779 13 upstream-assigned mpls labels

RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]

draft-ietf-mpls-upstream-label-07 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5331 10.17487/RFC5331
RFC5332 MPLS Multicast Encapsulations T. Eckert E. Rosen Editor R. Aggarwal Y. Rekhter August 2008 ASCII 22887 11 data link layer codepoint multiaccess media upstream-assigned label mac da medium access layer destination address

RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label".

RFC 3032 does not specify the destination address to be placed in the "MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification.

This document updates RFC 3032 and RFC 4023. [STANDARDS-TRACK]

draft-ietf-mpls-multicast-encaps-10 RFC3032 RFC4023 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5332
RFC5333 IANA Registration of Enumservices for Internet Calendaring R. Mahy B. Hoeneisen October 2009 ASCII 13945 8 ENUM iCal iMIP i TIP CalDAV

This document registers Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV). [STANDARDS-TRACK]

draft-ietf-enum-calendar-service-04 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5333
RFC5334 Ogg Media Types I. Goncalves S. Pfeiffer C. Montgomery September 2008 ASCII 27018 14 Ogg MIME Video Audio Codecs

This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types. This document obsoletes RFC 3534. [STANDARDS-TRACK]

draft-goncalves-rfc3534bis-07 RFC3534 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5334
RFC5335 Internationalized Email Headers A. Yang Editor September 2008 ASCII 27945 14 unicode utf-8

Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-eai-utf8headers-12 RFC6532 RFC2045 RFC2822 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5335 10.17487/RFC5335
RFC5336 SMTP Extension for Internationalized Email Addresses J. Yao Editor W. Mao Editor September 2008 ASCII 48110 22 EAI UTF8SMTP MAIL TRANSFER

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952This memo defines an Experimental Protocol for the Internet community.

draft-ietf-eai-smtpext-13 RFC6531 RFC2821 RFC2822 RFC4952 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5336 10.17487/RFC5336
RFC5337 Internationalized Delivery Status and Disposition Notifications C. Newman A. Melnikov Editor September 2008 ASCII 36324 18 EAI DSN SMTP

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.

This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-eai-dsn-06 RFC6533 RFC3461 RFC3462 RFC3464 RFC3798 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5337 10.17487/RFC5337
RFC5338 Using the Host Identity Protocol with Legacy Applications T. Henderson P. Nikander M. Komu September 2008 ASCII 34882 14 hip cryptographic name space network stack names api application programming interface

This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. This memo provides information for the Internet community.

draft-ietf-hip-applications-04 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5338
RFC5339 Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) JL. Le Roux Editor D. Papadimitriou Editor September 2008 ASCII 53998 25 general multiprotocol label switching

This document provides an evaluation of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-Region Networks (MRNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-mln-eval-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5339 10.17487/RFC5339
RFC5340 OSPF for IPv6 R. Coltun D. Ferguson J. Moy A. Lindem July 2008 ASCII 225664 94 open shortest path first ospfv3

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).

Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).

Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.

All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-update-23 RFC2740 RFC6845 RFC6860 RFC7503 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5340 10.17487/RFC5340
RFC5341 The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry C. Jennings V. Gurbani September 2008 ASCII 13944 7 uniform resource locator schemes

This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. [STANDARDS-TRACK]

draft-ietf-iptel-tel-reg-06 RFC3966 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC5341
RFC5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters D. Eastlake 3rd September 2008 ASCII 42800 21 Ethernet Ethertype 802 OUI EUI LSAP

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-eastlake-ethernet-iana-considerations-08 RFC7042 RFC2153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5342
RFC5343 Simple Network Management Protocol (SNMP) Context EngineID Discovery J. Schoenwaelder September 2008 ASCII 19938 9 snmpv3 snmpengineid localengineid

The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.

This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.

This document updates RFC 3411. [STANDARDS-TRACK]

draft-ietf-opsawg-snmp-engineid-discovery-03 RFC3411 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5343
RFC5344 Presence and Instant Messaging Peering Use Cases A. Houri E. Aoki S. Parameswar October 2008 ASCII 18389 9 non-voip collaboration service instant messaging im

This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM). This memo provides information for the Internet community.

draft-ietf-speermint-consolidated-presence-im-usecases-05 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC5344
RFC5345 Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats J. Schoenwaelder October 2008 ASCII 52411 23 large-scale snmp irtf nmrg network management research group

The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.

This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.

This document was produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group. This memo provides information for the Internet community.

draft-irtf-nmrg-snmp-measure-06 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5345 10.17487/RFC5345
RFC5346 Operational Requirements for ENUM-Based Softswitch Use J. Lim W. Kim C. Park L. Conroy October 2008 ASCII 31050 14 Applications ENUM DNS E.164 NAPTR Softswitch Field Trial

This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006.

These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. This memo provides information for the Internet community.

draft-ietf-enum-softswitch-req-04 INFORMATIONAL INFORMATIONAL IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=5346 10.17487/RFC5346
RFC5347 Media Gateway Control Protocol Fax Package F. Andreasen D. Hancock October 2008 ASCII 86532 46 mgcp fax calls fax relay fax transmission

This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. This memo provides information for the Internet community.

draft-andreasen-mgcp-fax-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5347 10.17487/RFC5347
RFC5348 TCP Friendly Rate Control (TFRC): Protocol Specification S. Floyd M. Handley J. Padhye J. Widmer September 2008 ASCII 133185 58 tcp-friendly rate control congestion control

This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.

This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]

draft-ietf-dccp-rfc3448bis-06 RFC3448 RFC4342 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=5348 10.17487/RFC5348
RFC5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu K. Jaganathan K. Lauter September 2008 ASCII 19706 10 ecdh elliptic curve diffie-hellman

This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography. This memo provides information for the Internet community.

draft-zhu-pkinit-ecc-04 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC5349
RFC5350 IANA Considerations for the IPv4 and IPv6 Router Alert Options J. Manner A. McDonald September 2008 ASCII 17812 8

This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS-TRACK]

draft-manner-router-alert-iana-03 RFC2113 RFC3175 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5350
RFC5351 An Overview of Reliable Server Pooling Protocols P. Lei L. Ong M. Tuexen T. Dreibholz September 2008 ASCII 33062 15 rserpool

The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite. This memo provides information for the Internet community.

draft-ietf-rserpool-overview-06 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC5351
RFC5352 Aggregate Server Access Protocol (ASAP) R. Stewart Q. Xie M. Stillman M. Tuexen September 2008 ASCII 118712 53 rserpool enrp endpoint handlespace redundancy protocol

Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.

In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.

ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.

The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-asap-21 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5352
RFC5353 Endpoint Handlespace Redundancy Protocol (ENRP) Q. Xie R. Stewart M. Stillman M. Tuexen A. Silverton September 2008 ASCII 83657 39 rserpool asap aggregate server access protocol fault-tolerant registry

The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-enrp-21 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5353
RFC5354 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters R. Stewart Q. Xie M. Stillman M. Tuexen September 2008 ASCII 50217 23 rserpool

This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-common-param-18 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5354
RFC5355 Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats M. Stillman Editor R. Gopal E. Guttman S. Sengodan M. Holdrege September 2008 ASCII 38042 19

Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats. This memo provides information for the Internet community.

draft-ietf-rserpool-threats-15 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC5355
RFC5356 Reliable Server Pooling Policies T. Dreibholz M. Tuexen September 2008 ASCII 33394 16 rserpool enrp endpoint handlespace redundancy protocol

This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-policies-10 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5356
RFC5357 A Two-Way Active Measurement Protocol (TWAMP) K. Hedayat R. Krzanowski A. Morton K. Yum J. Babiarz October 2008 ASCII 61960 26 two-way measaurement round-trip measurement

The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]

draft-ietf-ippm-twamp-09 RFC5618 RFC5938 RFC6038 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5357 10.17487/RFC5357
RFC5358 Preventing Use of Recursive Nameservers in Reflector Attacks J. Damas F. Neves October 2008 ASCII 14957 7 denial of service dos

This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsop-reflectors-are-evil-06 BCP0140 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC5358
RFC5359 Session Initiation Protocol Service Examples A. Johnston Editor R. Sparks C. Cunningham S. Donovan K. Summers October 2008 ASCII 289446 170 sip pbx centrex features hold transfer forwarding screening park pickup redial click call flows

This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-service-examples-15 BCP0144 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC5359
RFC5360 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) J. Rosenberg G. Camarillo Editor D. Willis October 2008 ASCII 70658 31

SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP. [STANDARDS-TRACK]

draft-ietf-sip-consent-framework-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5360
RFC5361 A Document Format for Requesting Consent G. Camarillo October 2008 ASCII 28256 14 xml extensible markup language premission document

This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation. [STANDARDS-TRACK]

draft-ietf-sipping-consent-format-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5361
RFC5362 The Session Initiation Protocol (SIP) Pending Additions Event Package G. Camarillo October 2008 ASCII 32137 16 consent-related resource list

This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. [STANDARDS-TRACK]

draft-ietf-sipping-pending-additions-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5362
RFC5363 Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services G. Camarillo A.B. Roach October 2008 ASCII 22912 10

This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services. [STANDARDS-TRACK]

draft-ietf-sipping-uri-services-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5363
RFC5364 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists M. Garcia-Martin G. Camarillo October 2008 ASCII 40497 17 XML copy control resource list

In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. [STANDARDS-TRACK]

draft-ietf-sipping-capacity-attribute-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5364
RFC5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) M. Garcia-Martin G. Camarillo October 2008 ASCII 41393 18 user agent client uac sip message request uniform resource identifier list message uri list

This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list. [STANDARDS-TRACK]

draft-ietf-sip-uri-list-message-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5365
RFC5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) G. Camarillo A. Johnston October 2008 ASCII 28369 13 sip uri list invite-contatined uri

This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list. [STANDARDS-TRACK]

draft-ietf-sip-uri-list-conferencing-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5366
RFC5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) G. Camarillo A.B. Roach O. Levin October 2008 ASCII 18329 9 subscribe request resrouce list

This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a single SUBSCRIBE dialog. [STANDARDS-TRACK]

draft-ietf-sip-uri-list-subscribe-02 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5367
RFC5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP) G. Camarillo A. Niemi M. Isomaki M. Garcia-Martin H. Khartabil October 2008 ASCII 29389 13 sip refer refer-to multipler-refer

This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag. [STANDARDS-TRACK]

draft-ietf-sip-multiple-refer-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5368
RFC5369 Framework for Transcoding with the Session Initiation Protocol (SIP) G. Camarillo October 2008 ASCII 20428 10 transcoding services conference bridge model third-party call control model deaf hard of hearing speech-impaired

This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. This memo provides information for the Internet community.

draft-ietf-sipping-transc-framework-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5369
RFC5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model G. Camarillo October 2008 ASCII 23184 11 transcoding service deaf hard of hearing speech-impaired

This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. [STANDARDS-TRACK]

draft-ietf-sipping-transc-conf-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5370
RFC5371 RTP Payload Format for JPEG 2000 Video Streams S. Futemma E. Itakura A. Leung October 2008 ASCII 62655 31 JPEG 2000 video RTP Real-time Transport Protocol main header tile number Sony Corporation

This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, better known as JPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways. The JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images. [STANDARDS-TRACK]

draft-ietf-avt-rtp-jpeg2000-20 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5371
RFC5372 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery A. Leung S. Futemma E. Itakura October 2008 ASCII 53150 26 Real-time Transport Protocol main header compensation priority field priority mapping table packet-number-based ordering progression-based ordering layer-based ordering resolution-based ordering component-based ordering Sony Corporation

This memo describes extended uses for the payload header in "RTP Payload Format for JPEG 2000 Video Streams" as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery.

This memo must be accompanied with a complete implementation of "RTP Payload Format for JPEG 2000 Video Streams". That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and Session Description Protocol (SDP) marker signaling for implementations of this document. [STANDARDS-TRACK]

draft-ietf-avt-rtp-jpeg2000-beam-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5372
RFC5373 Requesting Answering Modes for the Session Initiation Protocol (SIP) D. Willis Editor A. Allen November 2008 ASCII 59839 24 PoC PTT auto automatic manual answer loopback diagnostic answer-mode priv-answer-mode

This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. [STANDARDS-TRACK]

draft-ietf-sip-answermode-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5373
RFC5374 Multicast Extensions to the Security Architecture for the Internet Protocol B. Weis G. Gross D. Ignjatic November 2008 ASCII 87729 38 ip ipsec ip multicast packets

The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast. [STANDARDS-TRACK]

draft-ietf-msec-ipsec-extensions-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC5374
RFC5375 IPv6 Unicast Address Assignment Considerations G. Van de Velde C. Popoviciu T. Chown O. Bonness C. Hahn December 2008 ASCII 83809 35 internet protocol version 6 address architecture

One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. This memo provides information for the Internet community.

draft-ietf-v6ops-addcon-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=5375 10.17487/RFC5375
RFC5376 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) N. Bitar R. Zhang K. Kumaki November 2008 ASCII 33114 14 PCE PCECP inter-AS PCE inter-provider PCE inter-AS MPLS-TE inter-provider MPLS-TE inter-AS PCECP inter-provider PCECP GMPLS path computation MPLS-TE path computation path computation element path computation communication protocol path computing element Interas Interas TE

Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries.

The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as between PCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS TE. This memo provides information for the Internet community.

draft-ietf-pce-interas-pcecp-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5376
RFC5377 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents J. Halpern Editor November 2008 ASCII 17843 8 contributors ietf contributions outbound rights

Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This memo provides information for the Internet community.

draft-ietf-ipr-outbound-rights-07 INFORMATIONAL INFORMATIONAL IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=5377 10.17487/RFC5377
RFC5378 Rights Contributors Provide to the IETF Trust S. Bradner Editor J. Contreras Editor November 2008 ASCII 37980 16 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-3978-incoming-09 RFC3978 RFC4748 RFC2026 BCP0078 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC5378
RFC5379 Guidelines for Using the Privacy Mechanism for SIP M. Munakata S. Schubert T. Ohba February 2010 ASCII 52595 23 SIP Privacy priv-value guideline

This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-munakata-sip-privacy-guideline-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5379
RFC5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management H. Soliman C. Castelluccia K. ElMalki L. Bellier October 2008 ASCII 58330 26 mobile ipv6 ipv6 neighbor discovery map mobility anchor point

This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. [STANDARDS-TRACK]

draft-ietf-mipshop-4140bis-05 RFC4140 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5380
RFC5381 Experience of Implementing NETCONF over SOAP T. Iijima Y. Atarashi H. Kimura M. Kitani H. Okita October 2008 ASCII 47724 22 simple object access protocol network configuration protocol mns network management system

This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. This memo provides information for the Internet community.

draft-iijima-netconf-soap-implementation-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5381 10.17487/RFC5381
RFC5382 NAT Behavioral Requirements for TCP S. Guha Editor K. Biswas B. Ford S. Sivakumar P. Srisuresh October 2008 ASCII 50306 31 network address translation

This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-tcp-08 BCP0142 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5382
RFC5383 Deployment Considerations for Lemonade-Compliant Mobile Email R. Gellens October 2008 ASCII 28290 12

This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-lemonade-deployments-09 BCP0143 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app lemonade 10.17487/RFC5383
RFC5384 The Protocol Independent Multicast (PIM) Join Attribute Format A. Boers I. Wijnands E. Rosen November 2008 ASCII 22330 10 pim-sm multicast distribution tree pim join attribute attr_type

A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. [STANDARDS-TRACK]

draft-ietf-pim-join-attributes-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5384 10.17487/RFC5384
RFC5385 Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs J. Touch February 2010 ASCII 38421 20 writing I-Ds writing RFCs authoring tools document preparation

This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285.

The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-touch-msword-template-v2.0-07 RFC3285 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5385 10.17487/RFC5385
RFC5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec N. Williams M. Richardson November 2008 ASCII 23103 11 internet protocol security ikev1 ikev2 sas esp ah pad spd btns unauthenticated ipsec

This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security). [STANDARDS-TRACK]

draft-ietf-btns-core-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5386 10.17487/RFC5386
RFC5387 Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) J. Touch D. Black Y. Wang November 2008 ASCII 71707 28 ipsec stand-alone btns sab channel-bound btns cbb

The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.

This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security" (BTNS). The extensions may be used on their own (this use is called Stand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable. This memo provides information for the Internet community.

draft-ietf-btns-prob-and-applic-07 INFORMATIONAL INFORMATIONAL IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5387 10.17487/RFC5387
RFC5388 Information Model and XML Data Model for Traceroute Measurements S. Niccolini S. Tartarelli J. Quittek T. Dietz M. Swany December 2008 ASCII 156801 75 extensible markup language DISMAN-TRACEROUTE-MIB

This document describes a standard way to store the configuration and the results of traceroute measurements. This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements). Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements. [STANDARDS-TRACK]

draft-ietf-ippm-storetraceroutes-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5388
RFC5389 Session Traversal Utilities for NAT (STUN) J. Rosenberg R. Mahy P. Matthews D. Wing October 2008 ASCII 125650 51 SIPs NAT STUN Traversal ICE firewall TURN VOIP

Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.

STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.

This document obsoletes RFC 3489. [STANDARDS-TRACK]

draft-ietf-behave-rfc3489bis-18 RFC3489 RFC7350 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5389 10.17487/RFC5389
RFC5390 Requirements for Management of Overload in the Session Initiation Protocol J. Rosenberg December 2008 ASCII 32851 14 sip overload handling 503 response

Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. This memo provides information for the Internet community.

draft-ietf-sipping-overload-reqs-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5390
RFC5391 RTP Payload Format for ITU-T Recommendation G.711.1 A. Sollaud November 2008 ASCII 26304 14 real-time transport protocol itu telecommunication standardization sector audio coded pcmu-wb pcma-wb

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included. [STANDARDS-TRACK]

draft-ietf-avt-rtp-g711wb-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5391
RFC5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering M. Chen R. Zhang X. Duan January 2009 ASCII 38690 17 multiprotocol label switching generalized mpls gmpls-te mpls-te isis-te open shortest path first ospf-te

This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation.

No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]

draft-ietf-ccamp-ospf-interas-te-extension-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5392
RFC5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies R. Sparks Editor S. Lawrence A. Hawrylyshen B. Campen December 2008 ASCII 48722 20 SIP application-layer application layer multimedia multicast unicast

This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.

This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS-TRACK]

draft-ietf-sip-fork-loop-fix-08 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5393
RFC5394 Policy-Enabled Path Computation Framework I. Bryskin D. Papadimitriou L. Berger J. Ash December 2008 ASCII 82226 36 PCE pce policy

The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. This memo provides information for the Internet community.

draft-ietf-pce-policy-enabled-path-comp-04 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5394
RFC5395 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd November 2008 ASCII 33725 17 RRTYPE RCODE AFSDB

Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsext-2929bis-07 RFC2929 RFC6195 RFC1183 RFC3597 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=5395 10.17487/RFC5395
RFC5396 Textual Representation of Autonomous System (AS) Numbers G. Huston G. Michaelson December 2008 ASCII 5373 3 decimal value

A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS number. This textual representation is to be used by all documents, systems, and user interfaces referring to AS numbers. [STANDARDS-TRACK]

draft-ietf-idr-as-representation-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5396
RFC5397 WebDAV Current Principal Extension W. Sanchez C. Daboo December 2008 ASCII 8828 5 http webdav access control acl authentication

This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. [STANDARDS-TRACK]

draft-sanchez-webdav-current-principal-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5397
RFC5398 Autonomous System (AS) Number Reservation for Documentation Use G. Huston December 2008 ASCII 5433 4 autonomous system numbers asn

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. This memo provides information for the Internet community.

draft-ietf-idr-as-documentation-reservation-00 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC5398
RFC5401 Multicast Negative-Acknowledgment (NACK) Building Blocks B. Adamson C. Bormann M. Handley J. Macker November 2008 ASCII 109312 42

This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941. [STANDARDS-TRACK]

draft-ietf-rmt-bb-norm-revised-07 RFC3941 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5401
RFC5402 Compressed Data within an Internet Electronic Data Interchange (EDI) Message T. Harding Editor February 2010 ASCII 14469 7 internet edi

This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ediint-compression-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5402
RFC5403 RPCSEC_GSS Version 2 M. Eisler February 2009 ASCII 30812 14 Kerberos ONC RPC security authentication integrity GSS GSS-API privacy confidentiality encryption MIC NFS credential verifier mechanism context

This document describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic Security Services Application Programming Interface (GSS-API). [STANDARDS-TRACK]

draft-ietf-nfsv4-rpcsec-gss-v2-06 RFC2203 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5403
RFC5404 RTP Payload Format for G.719 M. Westerlund I. Johansson January 2009 ASCII 64644 27 ITU-T g.719 full-band codec

This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. [STANDARDS-TRACK]

draft-ietf-avt-rtp-g719-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5404 10.17487/RFC5404
RFC5405 Unicast UDP Usage Guidelines for Application Designers L. Eggert G. Fairhurst November 2008 ASCII 69607 27 user datagram protocol congestion control

The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-tsvwg-udp-guidelines-11 BCP0145 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC5405
RFC5406 Guidelines for Specifying the Use of IPsec Version 2 S. Bellovin February 2009 ASCII 30393 13 internet security security considerations

The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-bellovin-useipsec-10 BCP0146 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5406
RFC5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP) M. Hasebe J. Koshiko Y. Suzuki T. Yoshikawa P. Kyzivat December 2008 ASCII 120005 60 sip user agents sip ua sip proxy servers

This document gives example call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-race-examples-06 BCP0147 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC5407
RFC5408 Identity-Based Encryption Architecture and Supporting Data Structures G. Appenzeller L. Martin M. Schertler January 2009 ASCII 62160 30 public key public-key encryption technology

This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. This memo provides information for the Internet community.

draft-ietf-smime-ibearch-09 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5408
RFC5409 Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS) L. Martin M. Schertler January 2009 ASCII 25481 13 bf bbq content-encryption keys

This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. This memo provides information for the Internet community.

draft-ietf-smime-bfibecms-10 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5409
RFC5410 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 A. Jerichow Editor L. Piron January 2009 ASCII 12444 7 MIKEY Extension IANA registration OMA BCAST draft-jerichow-msec-mikey-genext-oma-00 RFC4909 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5410 RFC5411 A Hitchhiker's Guide to the Session Initiation Protocol (SIP) J. Rosenberg February 2009 ASCII 96538 39 42 don't panic sip overview,

The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. This memo provides information for the Internet community.

draft-ietf-sip-hitchhikers-guide-06 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC5411
RFC5412 Lightweight Access Point Protocol P. Calhoun R. Suri N. Cam-Winget M. Williams S. Hares B. O'Hara S. Kelly February 2010 ASCII 262297 125 lwapp capwap

In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.

The IETF's CAPWAP (Control and Provisioning of Wireless Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. This document defines a Historic Document for the Internet community.

draft-ohara-capwap-lwapp-04 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5412
RFC5413 SLAPP: Secure Light Access Point Protocol P. Narasimhan D. Harkins S. Ponnuswamy February 2010 ASCII 147426 75 capwap

The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.

In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.

Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP). This document defines a Historic Document for the Internet community.

draft-narasimhan-ietf-slapp-01 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5413
RFC5414 Wireless LAN Control Protocol (WiCoP) S. Iino S. Govindan M. Sugiura H. Cheng February 2010 ASCII 118969 54 wlan wireless local area network twp wireless termination points capwap control and provisioning of wireless access points

The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common.

The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of Wireless Access Points (CAPWAP). This document defines a Historic Document for the Internet community.

draft-iino-capwap-wicop-02 RFC5415 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5414
RFC5415 Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification P. Calhoun Editor M. Montemurro Editor D. Stanley Editor March 2009 ASCII 345381 155 LWAPP CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. [STANDARDS-TRACK]

draft-ietf-capwap-protocol-specification-15 RFC5414 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap http://www.rfc-editor.org/errata_search.php?rfc=5415 10.17487/RFC5415
RFC5416 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 P. Calhoun Editor M. Montemurro Editor D. Stanley Editor March 2009 ASCII 175870 76 Operations and Management LWAPP CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller.

This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. [STANDARDS-TRACK]

draft-ietf-capwap-protocol-binding-ieee80211-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap http://www.rfc-editor.org/errata_search.php?rfc=5416 10.17487/RFC5416
RFC5417 Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option P. Calhoun March 2009 ASCII 11551 6 CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers to which it is to connect. This document describes the DHCP options to be used by the CAPWAP Protocol. [STANDARDS-TRACK]

draft-ietf-capwap-dhc-ac-option-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap 10.17487/RFC5417
RFC5418 Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments S. Kelly T. Clancy March 2009 ASCII 74169 34 WLAN security

Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP), which serves as a \%stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. This memo provides information for the Internet community.

draft-ietf-capwap-threat-analysis-04 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5418
RFC5419 Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6) B. Patil G. Dommety January 2009 ASCII 45178 19 authentication signaling message mn ha

Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments. This memo provides information for the Internet community.

draft-ietf-mip6-whyauthdataoption-07 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC5419
RFC5420 Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) A. Farrel Editor D. Papadimitriou JP. Vasseur A. Ayyangarps February 2009 ASCII 47668 22 multiprotocol label switching label switched paths SESSION_ATTRIBUTE

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.

This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK]

draft-ietf-ccamp-rfc4420bis-03 RFC4420 RFC3209 RFC3473 RFC6510 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5420 10.17487/RFC5420
RFC5421 Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) N. Cam-Winget H. Zhou March 2009 ASCII 22345 10 generic token card eap-gtc

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within this tunnel, a basic password exchange, based on the Generic Token Card method (EAP-GTC), may be executed to authenticate the peer. This memo provides information for the Internet community.

draft-zhou-emu-fast-gtc-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5421
RFC5422 Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) N. Cam-Winget D. McGrew J. Salowey H. Zhou March 2009 ASCII 85200 39

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP- FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. This memo provides information for the Internet community.

draft-cam-winget-eap-fast-provisioning-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5422
RFC5423 Internet Message Store Events R. Gellens C. Newman March 2009 ASCII 34800 17 imap

One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.

This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. [STANDARDS-TRACK]

draft-ietf-lemonade-msgevent-07 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5423 10.17487/RFC5423
RFC5424 The Syslog Protocol R. Gerhards March 2009 ASCII 85162 38 event notification message syslog message berkeley software distribution transmission messages

This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.

This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]

draft-ietf-syslog-protocol-23 RFC3164 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog http://www.rfc-editor.org/errata_search.php?rfc=5424 10.17487/RFC5424
RFC5425 Transport Layer Security (TLS) Transport Mapping for Syslog F. Miao Editor Y. Ma Editor J. Salowey Editor March 2009 ASCII 28159 13 syslog message syslog security

This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. [STANDARDS-TRACK]

draft-ietf-syslog-transport-tls-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog http://www.rfc-editor.org/errata_search.php?rfc=5425 10.17487/RFC5425
RFC5426 Transmission of Syslog Messages over UDP A. Okmianski March 2009 ASCII 19354 9 udp User Datagram Protocol

This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. [STANDARDS-TRACK]

draft-ietf-syslog-transport-udp-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5426
RFC5427 Textual Conventions for Syslog Management G. Keeni March 2009 ASCII 17829 8 syslog facility syslog severity MIB textual-convention

This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-syslog-tc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5427
RFC5428 Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices S. Channabasappa W. De Ketelaere E. Nechamkin April 2009 ASCII 78139 37 snmp simple network management protocol multimedia terminal adapter PKTC-IETF-EVENT-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

draft-ietf-ipcdn-pktc-eventmess-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC5428
RFC5429 Sieve Email Filtering: Reject and Extended Reject Extensions A. Stone Editor March 2009 ASCII 28822 14 sieve refuse reject ereject joe-job smtp lmtp spam

This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028.

A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs.

This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible.

The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection. [STANDARDS-TRACK]

draft-ietf-sieve-refuse-reject-09 RFC3028 RFC5228 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5429
RFC5430 Suite B Profile for Transport Layer Security (TLS) M. Salter E. Rescorla R. Housley March 2009 ASCII 27586 12 nsa suite b cryptography

The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible. This memo provides information for the Internet community.

draft-rescorla-tls-suiteb-11 RFC6460 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5430
RFC5431 Diameter ITU-T Rw Policy Enforcement Interface Application D. Sun March 2009 ASCII 10412 5 diameter command code itu-t ITU-T Rw Policy-Install-Request pir Policy-Install-Answer pia

This document describes the need for a new pair of IANA Diameter Command Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). This memo provides information for the Internet community.

draft-sun-dime-itu-t-rw-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5431
RFC5432 Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) J. Polk S. Dhesikan G. Camarillo March 2009 ASCII 17614 9 offer/answer media stream

The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. [STANDARDS-TRACK]

draft-ietf-mmusic-qos-identification-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5432
RFC5433 Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method T. Clancy H. Tschofenig February 2009 ASCII 80452 38 EAP EAP-GPSK pre-shared key

This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. [STANDARDS-TRACK]

draft-ietf-emu-eap-gpsk-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC5433
RFC5434 Considerations for Having a Successful Birds-of-a-Feather (BOF) Session T. Narten February 2009 ASCII 33887 13 ietf bof working group

This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. [STANDARDS-TRACK]

draft-narten-successful-bof-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5434
RFC5435 Sieve Email Filtering: Extension for Notifications A. Melnikov Editor B. Leiba Editor W. Segmuller T. Martin January 2009 ASCII 36181 17

Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. [STANDARDS-TRACK]

draft-ietf-sieve-notify-12 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5435
RFC5436 Sieve Notification Mechanism: mailto B. Leiba M. Haardt January 2009 ASCII 26519 12 eletctronic mail notification

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. [STANDARDS-TRACK]

draft-ietf-sieve-notify-mailto-10 RFC3834 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5436
RFC5437 Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre A. Melnikov January 2009 ASCII 28448 14 jabber

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. [STANDARDS-TRACK]

draft-ietf-sieve-notify-xmpp-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5437
RFC5438 Instant Message Disposition Notification (IMDN) E. Burger H. Khartabil February 2009 ASCII 83723 38 im instant messaging cpim common presence and instant messaging

Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications, for page-mode instant messages.

The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.

This document also describes how SIP entities behave using this extension. [STANDARDS-TRACK]

draft-ietf-simple-imdn-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5438 10.17487/RFC5438
RFC5439 An Analysis of Scaling Issues in MPLS-TE Core Networks S. Yasukawa A. Farrel O. Komolafe February 2009 ASCII 93845 45 multiprotocol label switching traffic engineered scaling concerns lsp label switch path point-to-point mpls-te lsps

Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning.

This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.

This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint MPLS-TE LSPs are for future study. This memo provides information for the Internet community.

draft-ietf-mpls-te-scaling-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5439 10.17487/RFC5439
RFC5440 Path Computation Element (PCE) Communication Protocol (PCEP) JP. Vasseur Editor JL. Le Roux Editor March 2009 ASCII 190529 87 MPLS GMPLS Traffic Engineering Label Switched Path

This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]

draft-ietf-pce-pcep-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5440 10.17487/RFC5440
RFC5441 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths JP. Vasseur Editor R. Zhang N. Bitar JL. Le Roux April 2009 ASCII 39936 18 te lsp path computation element

The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK]

draft-ietf-pce-brpc-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5441 10.17487/RFC5441
RFC5442 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail E. Burger G. Parsons March 2009 ASCII 28758 15 enhancements to internet email to supportt diverse service environments Phone

This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) working group in the IETF. This document also describes how the LEMONADE architecture meets OMA's requirements for their Mobile Email (MEM) service. This memo provides information for the Internet community.

draft-ietf-lemonade-architecture-04 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC5442
RFC5443 LDP IGP Synchronization M. Jork A. Atlas L. Fang March 2009 ASCII 15475 7 label distribution protocol interior gateway protocol

In certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-igp-sync-04 RFC6138 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5443
RFC5444 Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format T. Clausen C. Dearlove J. Dean C. Adjih February 2009 ASCII 139048 60 routing TLV address

This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. [STANDARDS-TRACK]

draft-ietf-manet-packetbb-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5444 10.17487/RFC5444
RFC5445 Basic Forward Error Correction (FEC) Schemes M. Watson March 2009 ASCII 41713 19 content stream delivery multicast internet protocol

This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT) FEC building block for the Compact No-Code FEC Scheme, the Small Block, Large Block, and Expandable FEC Scheme, the Small Block Systematic FEC Scheme, and the Compact FEC Scheme. This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-basic-schemes-revised-06 RFC3452 RFC3695 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5445 10.17487/RFC5445
RFC5446 Service Selection for Mobile IPv4 J. Korhonen U. Nilsson February 2009 ASCII 19089 9 internet protocol version 4 host name agent mobility service subscription

In some Mobile IPv4 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish among the multiple services possibly provisioned to the mobile node. The capability to specify different services in addition to the mobile node's identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a Service Selection extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for their mobility service subscriptions during the registration procedure. This memo provides information for the Internet community.

draft-korhonen-mip4-service-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5446
RFC5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction J. Korhonen Editor J. Bournelle H. Tschofenig C. Perkins K. Chowdhury February 2009 ASCII 38656 17 Diameter Mobile IPv6 Integrated Scenario

A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters be statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication, Authorization, and Accounting (AAA) infrastructures. This document describes MIPv6 bootstrapping using the Diameter Network Access Server to home AAA server interface. [STANDARDS-TRACK]

draft-ietf-dime-mip6-integrated-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5447 10.17487/RFC5447
RFC5448 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') J. Arkko V. Lehtovirta P. Eronen May 2009 ASCII 60641 29 EAP AKA AKA' 3GPP

This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.

This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.

draft-arkko-eap-aka-kdf-10 RFC4187 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5448
RFC5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks E. Baccelli P. Jacquet D. Nguyen T. Clausen February 2009 ASCII 67216 31 open shortest path first interface type mobile ad hoc

This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type". This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ospf-manet-mpr-04 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5449 10.17487/RFC5449
RFC5450 Transmission Time Offsets in RTP Streams D. Singer H. Desineni March 2009 ASCII 17073 8 real-time transport IJ inter-arrival jitter

This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. [STANDARDS-TRACK]

draft-ietf-avt-rtp-toffset-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5450
RFC5451 Message Header Field for Indicating Message Authentication Status M. Kucherawy April 2009 ASCII 97404 43 authentication-results email authentication result

This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. [STANDARDS-TRACK]

draft-kucherawy-sender-auth-header-20 RFC7001 RFC6577 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5451 10.17487/RFC5451
RFC5452 Measures for Making DNS More Resilient against Forged Answers A. Hubert R. van Mook January 2009 ASCII 37432 18 spoofing source port hardening

The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder.

Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.

By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK]

draft-ietf-dnsext-forgery-resilience-10 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5452
RFC5453 Reserved IPv6 Interface Identifiers S. Krishnan February 2009 ASCII 11754 6 unicast address

Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. [STANDARDS-TRACK]

draft-ietf-6man-reserved-iids-03 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5453
RFC5454 Dual-Stack Mobile IPv4 G. Tsirtsis V. Park H. Soliman March 2009 ASCII 38606 18 ipv6 mipv4

This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual-stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. [STANDARDS-TRACK]

draft-ietf-mip4-dsmipv4-10 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=5454 10.17487/RFC5454
RFC5455 Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol S. Sivabalan Editor J. Parker S. Boutros K. Kumaki March 2009 ASCII 16780 9 classtype ds-te diffserv-aware traffic engineering pce

This document specifies a CLASSTYPE object to support Diffserv-Aware Traffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE). [STANDARDS-TRACK]

draft-ietf-pce-dste-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5455 10.17487/RFC5455
RFC5456 IAX: Inter-Asterisk eXchange Version 2 M. Spencer B. Capouch E. Guy Editor F. Miller K. Shumard February 2010 ASCII 226083 101 asterisk private branch exchange pbx voip voice over internet protocol

This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.

IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-guy-iax-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5456
RFC5457 IANA Considerations for IAX: Inter-Asterisk eXchange Version 2 E. Guy Editor February 2010 ASCII 50952 21 asterisk private branch exchange pbx voip voice over internet protocol

This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-guy-iaxiana-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5457 10.17487/RFC5457
RFC5458 Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol H. Cruickshank P. Pillai M. Noisternig S. Iyengar March 2009 ASCII 58733 26 iso 13818-1 transport stream ts ule stream gse generic stream encapsulation

The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC 4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission.

The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project. This memo provides information for the Internet community.

draft-ietf-ipdvb-sec-req-09 INFORMATIONAL INFORMATIONAL IETF int ipdvb http://www.rfc-editor.org/errata_search.php?rfc=5458 10.17487/RFC5458
RFC5459 G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support A. Sollaud January 2009 ASCII 14671 7 real-time transport protocol rtp itu-t international telecommunication union g.729.1 audio codec

This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format. [STANDARDS-TRACK]

draft-ietf-avt-rfc4749-dtx-update-03 RFC4749 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5459
RFC5460 DHCPv6 Bulk Leasequery M. Stapp February 2009 ASCII 40629 18 dynamic hos configuration protocol ipv6 dhcpv6 bindings

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-bulk-leasequery-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=5460 10.17487/RFC5460
RFC5461 TCP's Reaction to Soft Errors F. Gont February 2009 ASCII 31749 13 icmp Internet Control Message Protocol

This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. This memo provides information for the Internet community.

draft-ietf-tcpm-tcp-soft-errors-09 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC5461
RFC5462 Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field L. Andersson R. Asati February 2009 ASCII 19372 9 exp class of service cos tc field

The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".

Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.

To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]

draft-ietf-mpls-cosfield-def-08 RFC3032 RFC3270 RFC3272 RFC3443 RFC3469 RFC3564 RFC3985 RFC4182 RFC4364 RFC4379 RFC4448 RFC4761 RFC5129 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5462 10.17487/RFC5462
RFC5463 Sieve Email Filtering: Ihave Extension N. Freed March 2009 ASCII 12481 6 SMTP ESMTP

This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. [STANDARDS-TRACK]

draft-freed-sieve-ihave-04 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5463
RFC5464 The IMAP METADATA Extension C. Daboo February 2009 ASCII 39425 20 internet message access protocol annotation metadata

The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. [STANDARDS-TRACK]

draft-daboo-imap-annotatemore-17 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5464 10.17487/RFC5464
RFC5465 The IMAP NOTIFY Extension A. Gulbrandsen C. King A. Melnikov February 2009 ASCII 46208 22 Internet Message Access Protocol

This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. [STANDARDS-TRACK]

draft-ietf-lemonade-imap-notify-07 RFC5267 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5465 10.17487/RFC5465
RFC5466 IMAP4 Extension for Named Searches (Filters) A. Melnikov C. King February 2009 ASCII 19415 9 Internet Message Access Protocol

The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. [STANDARDS-TRACK]

draft-melnikov-imapext-filters-08 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5466
RFC5467 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) L. Berger A. Takacs D. Caviglia D. Fedyk J. Meuric March 2009 ASCII 29335 14 RSVP-TE TSPEC ADSPEC

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ccamp-asymm-bw-bidir-lsps-02 RFC6387 EXPERIMENTAL EXPERIMENTAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5467 10.17487/RFC5467
RFC5468 Performance Analysis of Inter-Domain Path Computation Methodologies S. Dasgupta J. de Oliveira JP. Vasseur April 2009 ASCII 24151 10 pce path computation element brpc backward recursive path computation

This document presents a performance comparison between the per-domain path computation method and the Path Computation Element (PCE) Architecture-based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified, and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. This memo provides information for the Internet community.

draft-dasgupta-ccamp-path-comp-analysis-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5468
RFC5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS) P. Eronen Editor February 2009 ASCII 8558 4 ciphersuite data encryption standard international data encryption algorithm

Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC 5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended. This memo provides information for the Internet community.

draft-ietf-tls-des-idea-02 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC5469
RFC5470 Architecture for IP Flow Information Export G. Sadasivan N. Brownlee B. Claise J. Quittek March 2009 ASCII 65717 31 ipfix ipfix device ipfix collector

This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector. This memo provides information for the Internet community.

draft-ietf-ipfix-architecture-12 RFC6183 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5470
RFC5471 Guidelines for IP Flow Information Export (IPFIX) Testing C. Schmoll P. Aitken B. Claise March 2009 ASCII 69313 32 exporting process collecting process

This document presents a list of tests for implementers of IP Flow Information eXport (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. This memo provides information for the Internet community.

draft-ietf-ipfix-testing-05 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5471
RFC5472 IP Flow Information Export (IPFIX) Applicability T. Zseby E. Boschi N. Brownlee B. Claise March 2009 ASCII 71379 31 ie information element PSAMP measurement QoS monitoring attack detection AAA ipfix framework

In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks. This memo provides information for the Internet community.

draft-ietf-ipfix-as-12 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5472 10.17487/RFC5472
RFC5473 Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports E. Boschi L. Mark B. Claise March 2009 ASCII 64654 27

This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.

This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. This memo provides information for the Internet community.

draft-ietf-ipfix-reducing-redundancy-04 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5473 10.17487/RFC5473
RFC5474 A Framework for Packet Selection and Reporting N. Duffield Editor D. Chiou B. Claise A. Greenberg M. Grossglauser J. Rexford March 2009 ASCII 86080 38 psamp selector collector

This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of the PSAMP functions. This memo provides information for the Internet community.

draft-ietf-psamp-framework-13 INFORMATIONAL INFORMATIONAL IETF ops psamp 10.17487/RFC5474
RFC5475 Sampling and Filtering Techniques for IP Packet Selection T. Zseby M. Molina N. Duffield S. Niccolini F. Raspall March 2009 ASCII 101260 46 psamp metering process

This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK]

draft-ietf-psamp-sample-tech-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp 10.17487/RFC5475
RFC5476 Packet Sampling (PSAMP) Protocol Specifications B. Claise Editor A. Johnson J. Quittek March 2009 ASCII 101620 45 exporting process collecting process ipfix ip flow information export

This document specifies the export of packet information from a Packet SAMPling (PSAMP) Exporting Process to a PSAMP Collecting Process. For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. [STANDARDS-TRACK]

draft-ietf-psamp-protocol-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp http://www.rfc-editor.org/errata_search.php?rfc=5476 10.17487/RFC5476
RFC5477 Information Model for Packet Sampling Exports T. Dietz B. Claise P. Aitken F. Dressler G. Carle March 2009 ASCII 84673 46 psamp ipfix ip flow information export

This memo defines an information model for the Packet SAMPling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK]

draft-ietf-psamp-info-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp http://www.rfc-editor.org/errata_search.php?rfc=5477 10.17487/RFC5477
RFC5478 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces J. Polk March 2009 ASCII 12810 6 us defense information systems agency

This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. [STANDARDS-TRACK]

draft-ietf-sip-rph-new-namespaces-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5478
RFC5479 Requirements and Analysis of Media Security Management Protocols D. Wing Editor S. Fries H. Tschofenig F. Audet April 2009 ASCII 99096 45 keying Secure RTP SRTP

This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. This memo provides information for the Internet community.

draft-ietf-sip-media-security-requirements-09 INFORMATIONAL INFORMATIONAL IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5479 10.17487/RFC5479
RFC5480 Elliptic Curve Cryptography Subject Public Key Information S. Turner D. Brown K. Yiu R. Housley T. Polk March 2009 ASCII 36209 20 x.509 asn.1 subjectPubicKeyInfo

This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]

draft-ietf-pkix-ecc-subpubkeyinfo-11 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5480 10.17487/RFC5480
RFC5481 Packet Delay Variation Applicability Statement A. Morton B. Claise March 2009 ASCII 92218 39 active measurement ipdv pdv inter-packet delay variation

Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.

Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. This memo provides information for the Internet community.

draft-ietf-ippm-delay-var-as-02 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5481
RFC5482 TCP User Timeout Option L. Eggert F. Gont March 2009 ASCII 33568 14 Transmission Control Protocol

The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [STANDARDS-TRACK]

draft-ietf-tcpm-tcp-uto-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5482
RFC5483 ENUM Implementation Issues and Experiences L. Conroy K. Fujiwara March 2009 ASCII 72780 30 DNS E.164 NAPTR dynamic delegation discovery system

This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents. This memo provides information for the Internet community.

draft-ietf-enum-experiences-11 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5483
RFC5484 Associating Time-Codes with RTP Streams D. Singer March 2009 ASCII 25408 13 smpte society of motion picture and television engineers media stream

This document describes a mechanism for associating \%time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. [STANDARDS-TRACK]

draft-ietf-avt-smpte-rtp-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5484
RFC5485 Digital Signatures on Internet-Draft Documents R. Housley March 2009 ASCII 29582 14 cms cryptographic message syntax detached signature

This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. This memo provides information for the Internet community.

draft-housley-internet-draft-sig-file-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5485
RFC5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology D. Malas Editor D. Meyer Editor March 2009 ASCII 22036 10

This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). This memo provides information for the Internet community.

draft-ietf-speermint-terminology-17 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC5486
RFC5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode M. Badra March 2009 ASCII 15537 7 PSK Diffie-Hellman Key Exchange advanced encryption standard gcm digest algorithm ciphersuite

RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 in their Message Authentication Code (MAC) algorithm. This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). [STANDARDS-TRACK]

draft-ietf-tls-psk-new-mac-aes-gcm-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC5487
RFC5488 Network Mobility (NEMO) Management Information Base S. Gundavelli G. Keeni K. Koide K. Nagami April 2009 ASCII 87041 44 mib NEMO-MIB

This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. [STANDARDS-TRACK]

draft-ietf-mext-nemo-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC5488
RFC5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) M. Badra I. Hajjeh March 2009 ASCII 14194 7 pre-shared key Diffie-Hellman Key Exchange Elliptic Curve Cryptography

This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher suites provide Perfect Forward Secrecy (PFS). This memo provides information for the Internet community.

draft-ietf-tls-ecdhe-psk-05 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC5489
RFC5490 The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata A. Melnikov March 2009 ASCII 16065 8 mail filtering fileinto

This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. [STANDARDS-TRACK]

draft-melnikov-sieve-imapext-metadata-08 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5490
RFC5491 GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations J. Winterbottom M. Thomson H. Tschofenig March 2009 ASCII 51681 28 PIDF-LO civic geodetic location well-formed GeoShape

The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. [STANDARDS-TRACK]

draft-ietf-geopriv-pdif-lo-profile-14 RFC4119 RFC7459 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5491 10.17487/RFC5491
RFC5492 Capabilities Advertisement with BGP-4 J. Scudder R. Chandra February 2009 ASCII 13581 7 bgp idr border gateway protocol capabilities

This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.

This document obsoletes RFC 3392. [STANDARDS-TRACK]

draft-ietf-idr-rfc3392bis-05 RFC3392 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5492 10.17487/RFC5492
RFC5493 Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network D. Caviglia D. Bramanti D. Li D. McDysan April 2009 ASCII 21991 11 pc spc soft permanent connection data plane traffic

From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.

This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. This memo provides information for the Internet community.

draft-ietf-ccamp-pc-and-sc-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5493
RFC5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP) J. Arkko C. Pignataro April 2009 ASCII 11894 7 IANA rules Address Resolution Protocol ARP

This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces. [STANDARDS-TRACK]

draft-arkko-arp-iana-rules-06 RFC0826 RFC0951 RFC1044 RFC1329 RFC2131 RFC2132 RFC2176 RFC2225 RFC2834 RFC2835 RFC3315 RFC4338 RFC4361 RFC4701 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5494
RFC5495 Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures D. Li J. Gao A. Satyanarayana S. Bardalai March 2009 ASCII 39325 18 Hello message gmpls

The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults.

The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP).

Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors.

This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.

This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. This memo provides information for the Internet community.

draft-ietf-ccamp-gr-description-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5495
RFC5496 The Reverse Path Forwarding (RPF) Vector TLV IJ. Wijnands A. Boers E. Rosen March 2009 ASCII 16754 8 pim protocol independent multicast join attribute

This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. [STANDARDS-TRACK]

draft-ietf-pim-rpf-vector-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5496 10.17487/RFC5496
RFC5497 Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) T. Clausen C. Dearlove March 2009 ASCII 30653 14 Routing Protocol TLV Fisheye FSR Fuzzy-Sighted extension packetbb RFC5444

This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols. [STANDARDS-TRACK]

draft-ietf-manet-timetlv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5497 10.17487/RFC5497
RFC5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols I. Chakeres March 2009 ASCII 8399 5 manet protocols

This document enumerates several common IANA allocations for use by Mobile Ad hoc NETwork (MANET) protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. [STANDARDS-TRACK]

draft-ietf-manet-iana-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5498 10.17487/RFC5498
RFC5501 Requirements for Multicast Support in Virtual Private LAN Services Y. Kamite Editor Y. Wada Y. Serbest T. Morin L. Fang March 2009 ASCII 71507 31 L2 VPN VPLS Ethernet P2MP IGMP MLD PIM

This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. This memo provides information for the Internet community.

draft-ietf-l2vpn-vpls-mcast-reqts-07 INFORMATIONAL INFORMATIONAL IETF int l2vpn 10.17487/RFC5501
RFC5502 The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem J. van Elburg April 2009 ASCII 33553 14 SIP S-CSCF AS ISC

This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. This memo provides information for the Internet community.

draft-vanelburg-sipping-served-user-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5502
RFC5503 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture F. Andreasen B. McKibben B. Marshall March 2009 ASCII 80201 34 P-DCS-TRACE-PARTY-ID P-DCS-OSPS P-DCS-BILLING-INFO P-DCS-LAES P-DCS-Redirect P-DCS-INFO

In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. This memo provides information for the Internet community.

draft-andreasen-sipping-rfc3603bis-07 RFC3603 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5503
RFC5504 Downgrading Mechanism for Email Address Internationalization K. Fujiwara Editor Y. Yoneya Editor March 2009 ASCII 48894 24 EAI Email Address Internationalization Downgrade MAIL

Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-eai-downgrade-12 RFC6530 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5504
RFC5505 Principles of Internet Host Configuration B. Aboba D. Thaler L. Andersson S. Cheshire May 2009 ASCII 57340 25 internet-layer parameter higher-layer configuration

This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols. This memo provides information for the Internet community.

draft-iab-ip-config-11 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5505
RFC5506 Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences I. Johansson M. Westerlund April 2009 ASCII 41011 17 AVPF non-compound non compound compound

This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK]

draft-ietf-avt-rtcp-non-compound-09 RFC3550 RFC3711 RFC4585 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5506 10.17487/RFC5506
RFC5507 Design Choices When Expanding the DNS IAB P. Faltstrom Editor R. Austein Editor P. Koch Editor April 2009 ASCII 44045 18 domain name system resource record type

This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. This memo provides information for the Internet community.

draft-iab-dns-choices-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5507
RFC5508 NAT Behavioral Requirements for ICMP P. Srisuresh B. Ford S. Sivakumar S. Guha April 2009 ASCII 67985 29 ICMP Error payload translation hairpin translation ICMP Query ICMP Error Ping Traceroute

This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-nat-icmp-12 BCP0148 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5508
RFC5509 Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) S. Loreto April 2009 ASCII 10053 5 _sip

This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP. [STANDARDS TRACK]

draft-loreto-simple-im-srv-label-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5509
RFC5510 Reed-Solomon Forward Error Correction (FEC) Schemes J. Lacan V. Roca J. Peltotalo S. Peltotalo April 2009 ASCII 57493 28 maximum distance separable MDS

This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).

Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-rs-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5510
RFC5511 Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications A. Farrel April 2009 ASCII 27026 14 routing bnf

Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.

There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.

Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.

This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK]

draft-farrel-rtg-common-bnf-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5511
RFC5512 The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute P. Mohapatra E. Rosen April 2009 ASCII 30554 13 BGP Encapsulation Encap SAFI Tunnel Softwire 4over6 6over4

In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.

The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]

draft-ietf-softwire-encaps-safi-05 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5512
RFC5513 IANA Considerations for Three Letter Acronyms A. Farrel April 1 2009 ASCII 13931 7 tla abbreviation

Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions. While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors.

Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. This memo provides information for the Internet community.

draft-farrel-iana-tla-registry-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5513 10.17487/RFC5513
RFC5514 IPv6 over Social Networks E. Vyncke April 1 2009 ASCII 10127 6 facebook

There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks. This will immediately add millions of IPv6 hosts to the existing IPv6 Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed. This memo defines an Experimental Protocol for the Internet community.

draft-vyncke-ip-over-social-network-01 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5514 10.17487/RFC5514
RFC5515 Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions V. Mammoliti C. Pignataro P. Arberg J. Gibbons P. Howard May 2009 ASCII 60768 28 L2TP Acces Line Information DSLAM

This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality. It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment. The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. The L2TP AVPs defined in this document are applicable to both L2TPv2 and L2TPv3. This memo provides information for the Internet community.

draft-mammoliti-l2tp-accessline-avp-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5515
RFC5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS) M. Jones L. Morand April 2009 ASCII 9105 5 3GPP Release 8 Diameter command codes EPS

This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). These new Diameter applications are defined for Mobile Management Entity (MME)- and Serving GPRS (General Packet Radio Service) Support Node (SGSN)-related interfaces in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS). This memo provides information for the Internet community.

draft-jones-dime-3gpp-eps-command-codes-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5516
RFC5517 Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment S. HomChaudhuri M. Foschiano February 2010 ASCII 28405 12

This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.

Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the-home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sanjib-private-vlan-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5517
RFC5518 Vouch By Reference P. Hoffman J. Levine A. Hathcock April 2009 ASCII 23730 12 VBR DKIM SenderID DK reputation

This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. [STANDARDS-TRACK]

draft-hoffman-dac-vbr-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5518 10.17487/RFC5518
RFC5519 Multicast Group Membership Discovery MIB J. Chesterfield B. Haberman Editor April 2009 ASCII 76260 41 management information base mgmd mld multicast listener discovery MGMD-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. [STANDARDS-TRACK]

draft-ietf-magma-mgmd-mib-15 RFC2933 RFC3019 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=5519 10.17487/RFC5519
RFC5520 Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism R. Bradford Editor JP. Vasseur A. Farrel April 2009 ASCII 43125 19 confidential path segment cps pcep

Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.

This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK]

draft-ietf-pce-path-key-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5520 10.17487/RFC5520
RFC5521 Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions E. Oki T. Takeda A. Farrel April 2009 ASCII 36294 16 MPLS GMPLS Traffic Engineering Label Switched Path

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions".

The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS-TRACK]

draft-ietf-pce-pcep-xro-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5521 10.17487/RFC5521
RFC5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks W. Eddy W. Ivancic T. Davis October 2009 ASCII 79570 31 NEMO aeronautics space exploration route optimization mobility

This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.

Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. This memo provides information for the Internet community.

draft-ietf-mext-aero-reqs-04 INFORMATIONAL INFORMATIONAL IETF int mext 10.17487/RFC5522
RFC5523 OSPFv3-Based Layer 1 VPN Auto-Discovery L. Berger April 2009 ASCII 23473 12 open shortest path first layer 1 virtual private network

This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-l1vpn-ospfv3-auto-discovery-03 EXPERIMENTAL EXPERIMENTAL IETF rtg l1vpn 10.17487/RFC5523
RFC5524 Extended URLFETCH for Binary and Converted Parts D. Cridland May 2009 ASCII 15915 9 IMAP Lemonade

The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. [STANDARDS-TRACK]

draft-cridland-urlfetch-binary-03 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5524
RFC5525 Reliable Server Pooling MIB Module Definition T. Dreibholz J. Mulik April 2009 ASCII 85897 46 RSerPool Management Information Base asap aggregate server access protocol enrp endpoint handlespace redundancy protocol RSERPOOL-MIB

Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols: ASAP (Aggregate Server Access Protocol) and ENRP (Endpoint Handlespace Redundancy Protocol). This document defines an \%SMIv2- compliant (Structure of Management Information Version 2) Management Information Base (MIB) module providing access to managed objects in an RSerPool implementation. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-mib-12 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5525
RFC5526 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM J. Livingood P. Pfautz R. Stastny April 2009 ASCII 9624 5 e164.arpa

This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). This memo provides information for the Internet community.

draft-ietf-enum-infrastructure-07 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5526
RFC5527 Combined User and Infrastructure ENUM in the e164.arpa Tree M. Haberler O. Lendl R. Stastny May 2009 ASCII 20733 10 e164.arpa

This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution. This memo provides information for the Internet community.

draft-ietf-enum-combined-09 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5527
RFC5528 Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms A. Kato M. Kanda S. Kanno April 2009 ASCII 56134 22 Camellia Block Cipher Mode of operation

This document describes the algorithms and presents test vectors for the Camellia block cipher algorithm in Counter mode (CTR) and Counter with Cipher Block Chaining MAC mode (CCM). The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.

draft-kato-camellia-ctrccm-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5528
RFC5529 Modes of Operation for Camellia for Use with IPsec A. Kato M. Kanda S. Kanno April 2009 ASCII 13030 7 IPsec Camellia Block Cipher Mode of operation

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- implement Internet Key Exchange Protocol version 2 (IKEv2) and Encapsulating Security Payload (ESP) mechanisms to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]

draft-kato-ipsec-camellia-modes-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5529
RFC5530 IMAP Response Codes A. Gulbrandsen May 2009 ASCII 17169 9 machine-readable response codes

IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.

This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]

draft-gulbrandsen-imap-response-codes-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5530
RFC5531 RPC: Remote Procedure Call Protocol Specification Version 2 R. Thurlow May 2009 ASCII 161720 63 RPC ONC Open Network Computing

This document describes the Open Network Computing (ONC) Remote Procedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831. [STANDARDS-TRACK]

draft-ietf-nfsv4-rfc1831bis-13 RFC1831 DRAFT STANDARD DRAFT STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5531 10.17487/RFC5531
RFC5532 Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement T. Talpey C. Juszczak May 2009 ASCII 36746 15 RPC XDR ONC RDDP NFSv4

This document addresses enabling the use of Remote Direct Memory Access (RDMA) by the Network File System (NFS) protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead. This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general. This memo provides information for the Internet community.

draft-ietf-nfsv4-nfs-rdma-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC5532
RFC5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6 E. Nordmark M. Bagnulo June 2009 ASCII 299931 124 locator pair

This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK]

draft-ietf-shim6-proto-12 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5533
RFC5534 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming J. Arkko I. van Beijnum June 2009 ASCII 88152 36 Shim6 reachability protocol REAP

This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. [STANDARDS-TRACK]

draft-ietf-shim6-failure-detection-13 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5534
RFC5535 Hash-Based Addresses (HBA) M. Bagnulo June 2009 ASCII 63994 25 Shim6 multi-homing cryptographically generated addresses (cgas),

This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other. [STANDARDS-TRACK]

draft-ietf-shim6-hba-05 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5535
RFC5536 Netnews Article Format K. Murchison Editor C. Lindsey D. Kohn November 2009 ASCII 71817 36 Usenet Usefor

This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK]

draft-ietf-usefor-usefor-12 RFC1036 RFC1849 PROPOSED STANDARD PROPOSED STANDARD IETF app usefor http://www.rfc-editor.org/errata_search.php?rfc=5536 10.17487/RFC5536
RFC5537 Netnews Architecture and Protocols R. Allbery Editor C. Lindsey November 2009 ASCII 120366 48 usefor Usenet netnews

This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. [STANDARDS-TRACK]

draft-ietf-usefor-usepro-14 RFC1036 RFC1849 PROPOSED STANDARD PROPOSED STANDARD IETF app usefor http://www.rfc-editor.org/errata_search.php?rfc=5537 10.17487/RFC5537
RFC5538 The 'news' and 'nntp' URI Schemes F. Ellermann April 2010 ASCII 29470 14

This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track. [STANDARDS-TRACK]

draft-ellermann-news-nntp-uri-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5538
RFC5539 NETCONF over Transport Layer Security (TLS) M. Badra May 2009 ASCII 16073 7 Authentication TLS RPC

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. [STANDARDS-TRACK]

draft-ietf-netconf-tls-07 RFC7589 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC5539
RFC5540 40 Years of RFCs RFC Editor April 2009 ASCII 5579 3

This RFC marks the 40th anniversary of the RFC document series. This memo provides information for the Internet community.

draft-rfc-editor-40-anniversary-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5540
RFC5541 Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) JL. Le Roux JP. Vasseur Y. Lee June 2009 ASCII 45589 23 pcc path computation client

The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).

In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.

This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.

This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK]

draft-ietf-pce-of-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC5541
RFC5542 Definitions of Textual Conventions for Pseudowire (PW) Management T. Nadeau Editor D. Zelig Editor O. Nicklass Editor May 2009 ASCII 19948 11 Pseudowire PWE3 MIB PWE3-TC PW-TC

This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-pwe3-pw-tc-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5542
RFC5543 BGP Traffic Engineering Attribute H. Ould-Brahim D. Fedyk Y. Rekhter May 2009 ASCII 11883 6 BGP-TE BGP-TE Attribute Traffic Engineering with BGP Inter-domain Traffic Engineering L1VPN BGP-TE BGP-TE-VPN VPN BGP Traffic Engineering Attribute

This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.

The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. [STANDARDS-TRACK]

draft-ietf-softwire-bgp-te-attribute-04 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5543
RFC5544 Syntax for Binding Documents with Time-Stamps A. Santoni February 2010 ASCII 26534 13 time-stamp token,

This document describes an envelope that can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time-stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed.

The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-santoni-timestampeddata-06 RFC5955 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5544
RFC5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar) B. Desruisseaux Editor September 2009 ASCII 345537 168 calsify calsched calsch caldav calendar calendaring meeting event task to-do journal appointment agenda schedule scheduling ical icalendar itip imip text/calendar ischedule xCalendar

This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]

draft-ietf-calsify-rfc2445bis-10 RFC2445 RFC5546 RFC6868 RFC7529 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=5545 10.17487/RFC5545
RFC5546 iCalendar Transport-Independent Interoperability Protocol (iTIP) C. Daboo Editor December 2009 ASCII 318143 133 calendar scheduling

This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.

The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]

draft-ietf-calsify-2446bis-10 RFC2446 RFC5545 RFC6638 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=5546 10.17487/RFC5546
RFC5547 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer M. Garcia-Martin M. Isomaki G. Camarillo S. Loreto P. Kyzivat May 2009 ASCII 112625 50 msrp message session relay protocol

This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. [STANDARDS-TRACK]

draft-ietf-mmusic-file-transfer-mech-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5547 10.17487/RFC5547
RFC5548 Routing Requirements for Urban Low-Power and Lossy Networks M. Dohler Editor T. Watteyne Editor T. Winter Editor D. Barthel Editor May 2009 ASCII 47759 21 u-lln roll routing over low-power and loss

The application-specific routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions). The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics. This memo provides information for the Internet community.

draft-ietf-roll-urban-routing-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5548
RFC5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop F. Le Faucheur E. Rosen May 2009 ASCII 23637 10 BGP IPv6 IPv4

Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK]

draft-ietf-softwire-v4nlri-v6nh-02 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5549
RFC5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile D. Cridland Editor A. Melnikov Editor S. Maes Editor August 2009 ASCII 84862 41 IMAP Sieve SMTP Lemonade mobile email low-bandwidth efficient

This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.

The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords. [STANDARDS-TRACK]

draft-ietf-lemonade-profile-bis-12 RFC4550 RFC4469 RFC4467 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5550
RFC5551 Lemonade Notifications Architecture R. Gellens Editor August 2009 ASCII 27542 12 notification filtering

Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for "interesting". This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) Working Group.

This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications. This memo provides information for the Internet community.

draft-ietf-lemonade-notifications-10 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC5551
RFC5552 SIP Interface to VoiceXML Media Services D. Burke M. Scott May 2009 ASCII 85063 36 VoiceXML SIP MRF IVR IMS

This document describes a SIP interface to VoiceXML media services. Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. [STANDARDS-TRACK]

draft-ietf-mediactrl-vxml-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=5552 10.17487/RFC5552
RFC5553 Resource Reservation Protocol (RSVP) Extensions for Path Key Support A. Farrel Editor R. Bradford JP. Vasseur May 2009 ASCII 30020 14 pks path key subobject ero explicit route object rro record route object

The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.

To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation.

This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. [STANDARDS-TRACK]

draft-ietf-ccamp-path-key-ero-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5553
RFC5554 Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings N. Williams May 2009 ASCII 8173 4 GSS GSS-API channel binding and C-bindings

This document clarifies and generalizes the Generic Security Service Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. [STANDARDS-TRACK]

draft-ietf-kitten-gssapi-channel-bindings-07 RFC2743 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5554
RFC5555 Mobile IPv6 Support for Dual Stack Hosts and Routers H. Soliman Editor June 2009 ASCII 92387 41 nemo mipv6 ipv4

The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. [STANDARDS-TRACK]

draft-ietf-mext-nemo-v4traversal-10 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=5555 10.17487/RFC5555
RFC5556 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement J. Touch R. Perlman May 2009 ASCII 41657 17 spanning tree protocol ieee 802.1

Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities. This memo provides information for the Internet community.

draft-ietf-trill-prob-06 INFORMATIONAL INFORMATIONAL IETF int trill http://www.rfc-editor.org/errata_search.php?rfc=5556 10.17487/RFC5556
RFC5557 Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization Y. Lee JL. Le Roux D. King E. Oki July 2009 ASCII 58888 26 pcc path communication client pce gco global concurrent optimization nms network management system

The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.

This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]

draft-ietf-pce-global-concurrent-optimization-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5557 10.17487/RFC5557
RFC5558 Virtual Enterprise Traversal (VET) F. Templin Editor February 2010 ASCII 88504 36 Enterprise MANET Encapsulation Tunneling Autoconfiguration Subnetwork Provider-Independent Provider-Aggregated

Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-templin-autoconf-dhcp-38 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5558
RFC5559 Pre-Congestion Notification (PCN) Architecture P. Eardley Editor June 2009 ASCII 134827 54 Quality of Service QoS Congestion Control Differentiated Services Admission Control Termination

This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain. This memo provides information for the Internet community.

draft-ietf-pcn-architecture-11 INFORMATIONAL INFORMATIONAL IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5559 10.17487/RFC5559
RFC5560 A One-Way Packet Duplication Metric H. Uijterwaal May 2009 ASCII 25304 14 performance metrics packet duplication unidirectional

When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.

In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. [STANDARDS-TRACK]

draft-ietf-ippm-duplicate-08 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5560
RFC5561 LDP Capabilities B. Thomas K. Raza S. Aggarwal R. Aggarwal JL. Le Roux July 2009 ASCII 27901 12 MPLS LDP Capabilities

A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-capabilities-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5561
RFC5562 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets A. Kuzmanovic A. Mondal S. Floyd K. Ramakrishnan June 2009 ASCII 77110 33 ecn-capable

The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of Explicit Congestion Notification (ECN) in TCP SYN/ACK packets.

This document describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tcpm-ecnsyn-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC5562
RFC5563 WiMAX Forum / 3GPP2 Proxy Mobile IPv4 K. Leung G. Dommety P. Yegani K. Chowdhury February 2010 ASCII 92438 41 mipv4 pmipv4

Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-leung-mip4-proxy-mode-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5563
RFC5564 Linguistic Guidelines for the Use of the Arabic Language in Internet Domains A. El-Sherbiny M. Farah I. Oueichek A. Al-Zoman February 2010 ASCII 22850 11 arabic domain names

This document constitutes technical specifications for the use of Arabic in Internet domain names and provides linguistic guidelines for Arabic domain names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-farah-adntf-ling-guidelines-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5564
RFC5565 Softwire Mesh Framework J. Wu Y. Cui C. Metz E. Rosen June 2009 ASCII 75039 31

The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]

draft-ietf-softwire-mesh-framework-06 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5565
RFC5566 BGP IPsec Tunnel Encapsulation Attribute L. Berger R. White E. Rosen June 2009 ASCII 17416 8 border gateway protocol safi subsequent address family identifier

The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and IP in IP tunnel types are defined. This document defines support for IPsec tunnel types. [STANDARDS-TRACK]

draft-ietf-softwire-encaps-ipsec-03 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5566
RFC5567 An Architectural Framework for Media Server Control T. Melanchuk Editor June 2009 ASCII 63384 25

This document describes an architectural framework for Media Server control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them. This memo provides information for the Internet community.

draft-ietf-mediactrl-architecture-04 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC5567
RFC5568 Mobile IPv6 Fast Handovers R. Koodli Editor July 2009 ASCII 121373 51 mpiv6 handover latency

Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures (namely, movement detection, new Care-of Address configuration, and Binding Update) is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.

This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type. [STANDARDS-TRACK]

draft-ietf-mipshop-rfc5268bis-01 RFC5268 RFC7411 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=5568 10.17487/RFC5568
RFC5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) R. Despres January 2010 ASCII 21159 10 IPv6 IPv4 migration transition 6to4 6rd

IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-despres-6rd-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5569 10.17487/RFC5569
RFC5570 Common Architecture Label IPv6 Security Option (CALIPSO) M. StJohns R. Atkinson G. Thomas July 2009 ASCII 128032 52 sensitivity labels mls multi-level secure

This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. This memo provides information for the Internet community.

draft-stjohns-sipso-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5570 10.17487/RFC5570
RFC5571 Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) B. Storer C. Pignataro Editor M. Dos Santos B. Stevant Editor L. Toutain J. Tremblay June 2009 ASCII 91379 41 Softwire L2TP Softwire Hub and Spoke Softwire HnS 4over6 6over4 L2TP softwires L2TPv2 softwires

This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. [STANDARDS-TRACK]

draft-ietf-softwire-hs-framework-l2tpv2-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5571
RFC5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) M. Blanchet F. Parent February 2010 ASCII 60017 32 IPv6 Tunnel Transition TSP

A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model. This document defines an Experimental Protocol for the Internet community.

draft-blanchet-v6ops-tunnelbroker-tsp-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5572 10.17487/RFC5572
RFC5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) M. Thomson June 2009 ASCII 17290 8 asynchronous beep channels

The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. This memo defines an Experimental Protocol for the Internet community.

draft-thomson-beep-async-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5573
RFC5574 RTP Payload Format for the Speex Codec G. Herlein J. Valin A. Heggestad A. Moizard June 2009 ASCII 27995 14 Voip SDP audio CELLP Xiph.Org

Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avt-rtp-speex-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5574
RFC5575 Dissemination of Flow Specification Rules P. Marques N. Sheth R. Raszuk B. Greene J. Mauch D. McPherson August 2009 ASCII 46473 22 IDR Inter-domain routing BGP DDOS Denial of Service ACL Firewall Filter

This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.

Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.

The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS-TRACK]

draft-ietf-idr-flow-spec-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5575 10.17487/RFC5575
RFC5576 Source-Specific Media Attributes in the Session Description Protocol (SDP) J. Lennox J. Ott T. Schierl June 2009 ASCII 40454 18 real-time transport protocol rtp synchronization source ssrc fid flow identification fec forward error correction

The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-source-attributes-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5576
RFC5577 RTP Payload Format for ITU-T Recommendation G.722.1 P. Luthi R. Even July 2009 ASCII 21705 11 international telecommunication union wide-band audio coded

International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec. [STANDARDS-TRACK]

draft-ietf-avt-rfc3047-bis-09 RFC3047 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5577 10.17487/RFC5577
RFC5578 PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics B. Berry Editor S. Ratliff E. Paradise T. Kaiser M. Adams February 2010 ASCII 54936 24 point-to-point protocol over ethernet link quality metric

This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-bberry-rfc4938bis-00 RFC4938 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5578
RFC5579 Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces F. Templin Editor February 2010 ASCII 18998 9 ISATAP Tunnel Encapsulation Map-and-Encaps IPv4 IPv6

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-templin-isatapv4-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5579
RFC5580 Carrying Location Objects in RADIUS and Diameter H. Tschofenig Editor F. Adrangi M. Jones A. Lior B. Aboba August 2009 ASCII 119753 53 remote authentication dial-in user service location information

This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter.

The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. [STANDARDS-TRACK]

draft-ietf-geopriv-radius-lo-24 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5580
RFC5581 The Camellia Cipher in OpenPGP D. Shaw June 2009 ASCII 5129 3 PGP GPG GnuPG Encryption Symmetric

This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. This memo provides information for the Internet community.

draft-ietf-openpgp-camellia-04 RFC4880 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5581
RFC5582 Location-to-URL Mapping Architecture and Framework H. Schulzrinne September 2009 ASCII 42078 17 ECRIT Mapping LoST Emergency calling

This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. This memo provides information for the Internet community.

draft-ietf-ecrit-mapping-arch-04 INFORMATIONAL INFORMATIONAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5582 10.17487/RFC5582
RFC5583 Signaling Media Decoding Dependency in the Session Description Protocol (SDP) T. Schierl S. Wenger July 2009 ASCII 40214 18 media coding ddp decoding dependency

This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.

A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). [STANDARDS-TRACK]

draft-ietf-mmusic-decoding-dependency-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5583 10.17487/RFC5583
RFC5584 RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family M. Hatanaka J. Matsumoto July 2009 ASCII 65071 30 RTP audio fragmentation layered coding multiplexed multi-session multi-channel redundancy scalable ATRAC ATRAC3 ATRAC-X ATRAC Advanced Lossless AAL Sony Corporation

This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. [STANDARDS-TRACK]

draft-ietf-avt-rtp-atrac-family-24 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5584 10.17487/RFC5584
RFC5585 DomainKeys Identified Mail (DKIM) Service Overview T. Hansen D. Crocker P. Hallam-Baker July 2009 ASCII 54110 24 Email Electroni Mail Internet Mail Message Verification

This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This memo provides information for the Internet community.

draft-ietf-dkim-overview-12 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5585
RFC5586 MPLS Generic Associated Channel M. Bocci Editor M. Vigoureux Editor S. Bryant Editor June 2009 ASCII 41482 19 mpls-tp oam g-ach ach associated channel header gal generic associated label

This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.

draft-ietf-mpls-tp-gach-gal-06 RFC3032 RFC4385 RFC5085 RFC6423 RFC7026 RFC7214 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5586 10.17487/RFC5586
RFC5587 Extended Generic Security Service Mechanism Inquiry APIs N. Williams July 2009 ASCII 32002 16 GSS-API mechanism inquiry extension

This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.

These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes. [STANDARDS-TRACK]

draft-ietf-kitten-extended-mech-inquiry-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5587
RFC5588 Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials N. Williams July 2009 ASCII 12434 7 GSS-API credential gss_store_cred

This document defines a new function for the Generic Security Service Application Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. [STANDARDS-TRACK]

draft-ietf-kitten-gssapi-store-cred-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5588
RFC5589 Session Initiation Protocol (SIP) Call Control - Transfer R. Sparks A. Johnston Editor D. Petrie June 2009 ASCII 119434 58 REFER GRUU Attended Transfer Target-Dialog Out of Dialog REFER SIP SIP Services blind transfer SIP Features Replaces Referred-By

This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-cc-transfer-12 BCP0149 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5589 10.17487/RFC5589
RFC5590 Transport Subsystem for the Simple Network Management Protocol (SNMP) D. Harrington J. Schoenwaelder June 2009 ASCII 84513 34 Network Management Simple Network Management Protocol SNMP SNMP-TRANSPORT-MIB

This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-tmsm-18 RFC3411 RFC3412 RFC3414 RFC3417 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5590
RFC5591 Transport Security Model for the Simple Network Management Protocol (SNMP) D. Harrington W. Hardaker June 2009 ASCII 61747 28 Network Management Simple Network Management Protocol SNMP Transport Security Model Security Model

This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).

This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-transport-security-model-14 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5591
RFC5592 Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) D. Harrington J. Salowey W. Hardaker June 2009 ASCII 82822 36 Network Management Simple Network Management Protocol SNMP Secure Shell SSH

This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.

This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-secshell-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5592
RFC5593 Internet Message Access Protocol (IMAP) - URL Access Identifier Extension N. Cook June 2009 ASCII 18149 10 urlauth imap url

The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications.

This document updates RFC 5092. [STANDARDS-TRACK]

draft-ncook-urlauth-accessid-02 RFC5092 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5593
RFC5594 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008 J. Peterson A. Cooper July 2009 ASCII 61652 28 P2PI

This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. This memo provides information for the Internet community.

draft-p2pi-cooper-workshop-report-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5594
RFC5595 The Datagram Congestion Control Protocol (DCCP) Service Codes G. Fairhurst September 2009 ASCII 44803 19 DCCP-Request Ports

This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC 4340. [STANDARDS-TRACK]

draft-ietf-dccp-serv-codes-11 RFC4340 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=5595 10.17487/RFC5595
RFC5596 Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal G. Fairhurst September 2009 ASCII 57638 25 DCCP NAT traversal Middlebox Issues

This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK]

draft-ietf-dccp-simul-open-08 RFC4340 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5596
RFC5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol R. Denis-Courmont September 2009 ASCII 18933 9 dccp

This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-dccp-05 BCP0150 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5597
RFC5598 Internet Mail Architecture D. Crocker July 2009 ASCII 115741 54 PDF 342738 email e-mail service mime architecture mta mua msa mda admd user originator recipient transfer message transfer deliver delivery relay header gateway agent gateway actor gateway sieve dsn mdn tussle mhs Message handling service message transfer agent message user agent mail submission agent mail delivery agent administrative management domain

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.

draft-crocker-email-arch-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5598 10.17487/RFC5598
RFC5601 Pseudowire (PW) Management Information Base (MIB) T. Nadeau Editor D. Zelig Editor July 2009 ASCII 129328 67 pseudowire edge-to-edge services IANA-PWE3-MIB PW-STD-MIB

This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS-TRACK]

draft-ietf-pwe3-pw-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5601 10.17487/RFC5601
RFC5602 Pseudowire (PW) over MPLS PSN Management Information Base (MIB) D. Zelig Editor T. Nadeau Editor July 2009 ASCII 62005 31 pw operation PW-MPLS-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS-TRACK]

draft-ietf-pwe3-pw-mpls-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5602
RFC5603 Ethernet Pseudowire (PW) Management Information Base (MIB) D. Zelig Editor T. Nadeau Editor July 2009 ASCII 44125 23 ethernet pw PW-ENET-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS-TRACK]

draft-ietf-pwe3-enet-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5603
RFC5604 Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) O. Nicklass July 2009 ASCII 80002 41 mib management information base pseudowire encapsulation t1 e1 t3 e3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS-TRACK]

draft-ietf-pwe3-tdm-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5604
RFC5605 Managed Objects for ATM over Packet Switched Networks (PSNs) O. Nicklass T. Nadeau July 2009 ASCII 69401 36 mib management information base atm pseudowire

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS-TRACK]

draft-ietf-pwe3-pw-atm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5605
RFC5606 Implications of 'retransmission-allowed' for SIP Location Conveyance J. Peterson T. Hardie J. Morris August 2009 ASCII 27960 11 pidf-lo presence information data format for location objects

This document explores an ambiguity in the interpretation of the <retransmission-allowed> element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.

Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. This memo provides information for the Internet community.

draft-ietf-geopriv-sip-lo-retransmission-02 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5606
RFC5607 Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management D. Nelson G. Weber July 2009 ASCII 55464 25 Network Management Device Management Simple Network Management Protocol SNMP Network Configuration Protocol NETCONF Access Control

This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. [STANDARDS-TRACK]

draft-ietf-radext-management-authorization-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC5607
RFC5608 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models K. Narayan D. Nelson August 2009 ASCII 34857 14 authorization service ssh transport model secure shell transport model

This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. [STANDARDS-TRACK]

draft-ietf-isms-radius-usage-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms http://www.rfc-editor.org/errata_search.php?rfc=5608 10.17487/RFC5608
RFC5609 State Machines for the Protocol for Carrying Authentication for Network Access (PANA) V. Fajardo Editor Y. Ohba R. Marin-Lopez August 2009 ASCII 63662 30 PANA State Machine EAP

This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANA Authentication Agent (PAA) state machine. The two state machines show how PANA can interface with the Extensible Authentication Protocol (EAP) state machines. The state machines and associated models are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.

draft-ietf-pana-statemachine-12 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC5609
RFC5610 Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements E. Boschi B. Trammell L. Mark T. Zseby July 2009 ASCII 42526 20 enterprise-specific Information Element IPFIX Template type record type options template

This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK]

draft-ietf-ipfix-exporting-type-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5610 10.17487/RFC5610
RFC5611 Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires A. Vainshtein S. Galtzur August 2009 ASCII 21979 11 l2tpv3 layer tow tunneling protocol version 3 structure-agnostic structure-aware cesopsn tdmoip

This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure-aware (Circuit Emulation Service over Packet Switched Network (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires. Support of structure-aware (Time-Division Multiplexing over IP (TDMoIP) style) pseudowires over L2TPv3 is left for further study. [STANDARDS-TRACK]

draft-ietf-l2tpext-tdm-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC5611
RFC5612 Enterprise Number for Documentation Use P. Eronen D. Harrington August 2009 ASCII 6610 4 smi network management private enterprise code

This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. This memo provides information for the Internet community.

draft-eronen-enterprise-number-documentation-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5612
RFC5613 OSPF Link-Local Signaling A. Zinin A. Roy L. Nguyen B. Friedman D. Yeung August 2009 ASCII 23092 12 open shortest path first intra-domain routing

OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.

draft-ietf-ospf-lls-08 RFC4813 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5613
RFC5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding R. Ogier P. Spagnolo August 2009 ASCII 170106 71 MANET routing link-state routing CDS flooding mesh network MANET Designated Router MDR

This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ospf-manet-mdr-05 RFC7038 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC5614
RFC5615 H.248/MEGACO Registration Procedures C. Groves Y. Lin August 2009 ASCII 29069 14 Package Error Code ServiceChange Reason Profile

This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-groves-megaco-pkgereg-04 BCP0151 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5615
RFC5616 Streaming Internet Messaging Attachments N. Cook August 2009 ASCII 65579 28 IMAP SIP streaming stream email multimedia lemonade attachments video audio

This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.

The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). This memo provides information for the Internet community.

draft-ietf-lemonade-streaming-13 INFORMATIONAL INFORMATIONAL IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5616 10.17487/RFC5616
RFC5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) E. Allman J. Fenton M. Delany J. Levine August 2009 ASCII 43093 21 email e-mail rfc 5322 rfc 5322 rfc 822 rfc 822 rfc 5321 rfc 5321 rfc 821 rfc 821 rfc 4871 rfc 4871 DKIM domain keys domainkeys ADSP ADSP SSP architecture mta user delivery smtp submission email e-mail smtp Internet mailfrom mail from author return address sender signing signing practices

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. [STANDARDS-TRACK]

draft-ietf-dkim-ssp-10 HISTORIC PROPOSED STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=5617 10.17487/RFC5617
RFC5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) A. Morton K. Hedayat August 2009 ASCII 16553 8 twamp-control protocol twamp-test protocol twamp modes

This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]

draft-ietf-ippm-more-twamp-02 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5618
RFC5619 Softwire Security Analysis and Requirements S. Yamamoto C. Williams H. Yokota F. Parent August 2009 ASCII 64657 28 IPv6 Tunnel Softwire Transition

This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. [STANDARDS-TRACK]

draft-ietf-softwire-security-requirements-09 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5619
RFC5620 RFC Editor Model (Version 1) O. Kolkman Editor IAB August 2009 ASCII 40744 19 RFC Series Editor Independent Stream Editor

The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. This memo provides information for the Internet community.

draft-iab-rfc-editor-model-07 RFC6548 RFC6635 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5620
RFC5621 Message Body Handling in the Session Initiation Protocol (SIP) G. Camarillo September 2009 ASCII 43676 19 Message body MIME SIP

This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. [STANDARDS-TRACK]

draft-ietf-sip-body-handling-06 RFC3204 RFC3261 RFC3459 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5621
RFC5622 Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) S. Floyd E. Kohler August 2009 ASCII 45394 19 ccid 4 congestion control identifier 4

This document specifies a profile for Congestion Control Identifier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dccp-ccid4-05 RFC6323 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp 10.17487/RFC5622
RFC5623 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering E. Oki T. Takeda JL. Le Roux A. Farrel September 2009 ASCII 81033 34 MPLS GMPLS Traffic Engineering Label Switched Path Virtual Network Topology

A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering.

This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). This memo provides information for the Internet community.

draft-ietf-pce-inter-layer-frwk-10 INFORMATIONAL INFORMATIONAL IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5623 10.17487/RFC5623
RFC5624 Quality of Service Parameters for Usage with Diameter J. Korhonen Editor H. Tschofenig E. Davies August 2009 ASCII 23326 12 Diameter QoS Parameters

This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.

The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per-hop behavior class object. [STANDARDS-TRACK]

draft-ietf-dime-qos-parameters-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5624
RFC5625 DNS Proxy Implementation Guidelines R. Bellis August 2009 ASCII 24585 12 DNS Proxy

This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsext-dnsproxy-06 BCP0152 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC5625
RFC5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) C. Jennings Editor R. Mahy Editor F. Audet Editor October 2009 ASCII 116344 50

The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK]

draft-ietf-sip-outbound-20 RFC3261 RFC3327 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5626
RFC5627 Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) J. Rosenberg October 2009 ASCII 94790 40 SIP NAT outbound gruu registration traversal

Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. [STANDARDS-TRACK]

draft-ietf-sip-gruu-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5627 10.17487/RFC5627
RFC5628 Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs) P. Kyzivat October 2009 ASCII 31031 14 registration

RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.

However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. [STANDARDS-TRACK]

draft-ietf-sipping-gruu-reg-event-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5628 10.17487/RFC5628
RFC5629 A Framework for Application Interaction in the Session Initiation Protocol (SIP) J. Rosenberg October 2009 ASCII 92959 38 sip dtmf

This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi- Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. [STANDARDS-TRACK]

draft-ietf-sipping-app-interaction-framework-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5629
RFC5630 The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) F. Audet October 2009 ASCII 114513 56 SIPS SIP TLS

This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. [STANDARDS-TRACK]

draft-ietf-sip-sips-09 RFC3261 RFC3608 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5630
RFC5631 Session Initiation Protocol (SIP) Session Mobility R. Shacham H. Schulzrinne S. Thakolsri W. Kellerer October 2009 ASCII 89040 35 third party call control (3pcc) transfer voice over ip (voip)

Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is an informational document. This memo provides information for the Internet community.

draft-shacham-sipping-session-mobility-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5631
RFC5632 Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial C. Griffiths J. Livingood L. Popkin R. Woundy Y. Yang September 2009 ASCII 27920 12 ISP Internet Service Provider P2P Peer-to-Peer P4P Proactive Network Provider Partication for P2P DCIA Distributed Computing Industry Association

This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a Proactive Network Provider Participation for P2P (P4P) technical trial in July 2008. This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer Transport Optimization (ALTO) working group. This memo provides information for the Internet community.

draft-livingood-woundy-p4p-experiences-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5632 10.17487/RFC5632
RFC5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers S. Dawkins Editor August 2009 ASCII 11117 5 Internet Architecture Board Engineering Steering Group

This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-dawkins-nomcom-dont-wait-04 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5633
RFC5634 Quick-Start for the Datagram Congestion Control Protocol (DCCP) G. Fairhurst A. Sathiaseelan August 2009 ASCII 52726 22 ccid congestion control identifier ccid 2 ccid 3 ccid 4

This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dccp-quickstart-05 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp 10.17487/RFC5634
RFC5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) W. Kumari D. McPherson August 2009 ASCII 30232 15 rtbh

Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. This memo provides information for the Internet community.

draft-ietf-opsec-blackhole-urpf-04 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC5635
RFC5636 Traceable Anonymous Certificate S. Park H. Park Y. Won J. Lee S. Kent August 2009 ASCII 70316 31 x.509 certificate blind issuer anonymity issuer tacs end entity ee

This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pkix-tac-04 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC5636
RFC5637 Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6 G. Giaretta I. Guardini E. Demaria J. Bournelle R. Lopez September 2009 ASCII 23409 11 AAA MIPv6 Mobile IP

In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. This memo provides information for the Internet community.

draft-ietf-mext-aaa-ha-goals-01 INFORMATIONAL INFORMATIONAL IETF int mext 10.17487/RFC5637
RFC5638 Simple SIP Usage Scenario for Applications in the Endpoints H. Sinnreich Editor A. Johnston E. Shim K. Singh September 2009 ASCII 45946 19 session initiation protocol rich internet application ria

For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIAs). Significant telephony features may also be implemented in the endpoints.

This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about 11.

References for NAT traversal and for security are also provided. This memo provides information for the Internet community.

draft-sinnreich-sip-tools-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5638
RFC5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation M. Lochter J. Merkle March 2010 ASCII 50566 27

This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-lochter-pkix-brainpool-ecc-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5639 10.17487/RFC5639
RFC5640 Load-Balancing for Mesh Softwires C. Filsfils P. Mohapatra C. Pignataro August 2009 ASCII 12250 6 bgp encapsulation subsequent address family identifier safi

Payloads transported over a Softwire mesh service (as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. [STANDARDS-TRACK]

draft-ietf-softwire-lb-03 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5640
RFC5641 Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values N. McGill C. Pignataro August 2009 ASCII 23133 11 attachment circuits acs pseudowires pw active bit new bit circuit status avp

This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate finer-grained error states for Attachment Circuits (ACs) and pseudowires (PWs). It also generalizes the Active bit and deprecates the use of the New bit in the Circuit Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC 4719. [STANDARDS-TRACK]

draft-ietf-l2tpext-circuit-status-extensions-05 RFC3931 RFC4349 RFC4454 RFC4591 RFC4719 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC5641
RFC5642 Dynamic Hostname Exchange Mechanism for OSPF S. Venkata S. Harwani C. Pignataro D. McPherson August 2009 ASCII 19227 8 open shortest path first router information ri ospf dynamic hostname

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3. [STANDARDS-TRACK]

draft-ietf-ospf-dynamic-hostname-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5642
RFC5643 Management Information Base for OSPFv3 D. Joyal Editor V. Manral Editor August 2009 ASCII 192945 95 mib ipv6 open shortest path first routing protocol OSPFV3-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5643 10.17487/RFC5643
RFC5644 IP Performance Metrics (IPPM): Spatial and Multicast E. Stephan L. Liang A. Morton October 2009 ASCII 110407 57 Multiple point measurement relative performance group performance statistic per hop measurement segment performance

The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). [STANDARDS-TRACK]

draft-ietf-ippm-multimetrics-12 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5644 10.17487/RFC5644
RFC5645 Update to the Language Subtag Registry D. Ewell Editor September 2009 ASCII 27902 13 language tags language tagging ltru registry

This memo defines the procedure used to update the IANA Language Subtag Registry, in conjunction with the publication of RFC 5646, for use in forming tags for identifying languages. This memo provides information for the Internet community.

draft-ietf-ltru-4645bis-10 INFORMATIONAL INFORMATIONAL IETF app ltru 10.17487/RFC5645
RFC5646 Tags for Identifying Languages A. Phillips Editor M. Davis Editor September 2009 ASCII 208592 84 language tags private interchange

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ltru-4646bis-23 RFC4646 BCP0047 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru 10.17487/RFC5646
RFC5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol K. Igoe J. Solinas August 2009 ASCII 20990 10 ssh remote-login

Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer Protocol. This memo provides information for the Internet community.

draft-igoe-secsh-aes-gcm-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5647
RFC5648 Multiple Care-of Addresses Registration R. Wakikawa Editor V. Devarapalli G. Tsirtsis T. Ernst K. Nagami October 2009 ASCII 90112 36

According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well. [STANDARDS-TRACK]

draft-ietf-monami6-multiplecoa-14 RFC6089 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=5648 10.17487/RFC5648
RFC5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm R. Housley M. Dworkin September 2009 ASCII 22507 13

This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped. This memo provides information for the Internet community.

draft-housley-aes-key-wrap-with-pad-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5649
RFC5650 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) M. Morgenstern S. Baillie U. Bonollo September 2009 ASCII 434687 218 mib management information base adsl asymmetric digital subscriber line VDSL2-LINE-TC-MIB VDSL2-LINE-MIB

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ interfaces. [STANDARDS-TRACK]

draft-ietf-adslmib-vdsl2-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC5650
RFC5651 Layered Coding Transport (LCT) Building Block M. Luby M. Watson L. Vicisano October 2009 ASCII 85751 34 FEC reliable multicast

The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but it also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This document obsoletes RFC 3451. [STANDARDS-TRACK]

draft-ietf-rmt-bb-lct-revised-11 RFC3451 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5651 10.17487/RFC5651
RFC5652 Cryptographic Message Syntax (CMS) R. Housley September 2009 ASCII 126813 56 digital signature message content

This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]

draft-ietf-smime-rfc3852bis-00 RFC3852 STD0070 INTERNET STANDARD DRAFT STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5652 10.17487/RFC5652
RFC5653 Generic Security Service API Version 2: Java Bindings Update M. Upadhyay S. Malkani August 2009 ASCII 209903 99 gssapi application program interface gss-api GSI

The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings" (RFC 2853). This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience.

The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). [STANDARDS-TRACK]

draft-ietf-kitten-rfc2853bis-05 RFC2853 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5653
RFC5654 Requirements of an MPLS Transport Profile B. Niven-Jenkins Editor D. Brungard Editor M. Betts Editor N. Sprecher S. Ueno September 2009 ASCII 69999 31 MPLS-TP ITU ITU-T

This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).

This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.

The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]

draft-ietf-mpls-tp-requirements-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5654 10.17487/RFC5654
RFC5655 Specification of the IP Flow Information Export (IPFIX) File Format B. Trammell E. Boschi L. Mark T. Zseby A. Wagner October 2009 ASCII 154566 64 flow file flow storage ipfix storage netflow storage

This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK]

draft-ietf-ipfix-file-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5655 10.17487/RFC5655
RFC5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer D. Stebila J. Green December 2009 ASCII 44259 20 Key Agreement Cryptography

This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK]

draft-green-secsh-ecc-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5656 10.17487/RFC5656
RFC5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard L. Dusseault R. Sparks September 2009 ASCII 29327 12 rfc2026 2026 guidance interoperation implementation reports advancement draft standard

Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-dusseault-impl-reports-04 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5657 10.17487/RFC5657
RFC5658 Addressing Record-Route Issues in the Session Initiation Protocol (SIP) T. Froment C. Lebel B. Bonnaerens October 2009 ASCII 39219 18 multi-homed user agent proxy interoperability double record-routing

A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) or SIPS (secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only a Record-Route rewriting solution. [STANDARDS-TRACK]

draft-ietf-sip-record-route-fix-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5658
RFC5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge M. Bocci S. Bryant October 2009 ASCII 55614 24 psn packet switched network

This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments. Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi-segment pseudowires, defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.

draft-ietf-pwe3-ms-pw-arch-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5659 10.17487/RFC5659
RFC5660 IPsec Channels: Connection Latching N. Williams October 2009 ASCII 74209 31 IPsec connection latching channel

This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.

Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.

Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS-TRACK]

draft-ietf-btns-connection-latching-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5660 10.17487/RFC5660
RFC5661 Network File System (NFS) Version 4 Minor Version 1 Protocol S. Shepler Editor M. Eisler Editor D. Noveck Editor January 2010 ASCII 1517771 617 Access Control List ACL Communications Sessions Exactly Once Semantics File Access Protocol Global Namespace Network Authentication Network File Access Network File System Network Security NFS Parallel Storage pNFS Storage Cluster

This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. [STANDARDS-TRACK]

draft-ietf-nfsv4-minorversion1-29 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5661 10.17487/RFC5661
RFC5662 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description S. Shepler Editor M. Eisler Editor D. Noveck Editor January 2010 ASCII 126581 73 xdr nfsv4

This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. [STANDARDS-TRACK]

draft-ietf-nfsv4-minorversion1-dot-x-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5662
RFC5663 Parallel NFS (pNFS) Block/Volume Layout D. Black S. Fridella J. Glasgow January 2010 ASCII 68571 28 nfsv4 network file sharing version 4

Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. [STANDARDS-TRACK]

draft-ietf-nfsv4-pnfs-block-12 RFC6688 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5663 10.17487/RFC5663
RFC5664 Object-Based Parallel NFS (pNFS) Operations B. Halevy B. Welch J. Zelenka January 2010 ASCII 78200 35 OSD storage device

Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. [STANDARDS-TRACK]

draft-ietf-nfsv4-pnfs-obj-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5664 10.17487/RFC5664
RFC5665 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats M. Eisler January 2010 ASCII 28706 14 rpcbind portmap transport independent remote procedure call TI-RPC transport identifier protocol identifier

This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This document updates, but does not replace, RFC 1833. [STANDARDS-TRACK]

draft-ietf-nfsv4-rpc-netid-06 RFC1833 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5665 10.17487/RFC5665
RFC5666 Remote Direct Memory Access Transport for Remote Procedure Call T. Talpey B. Callaghan January 2010 ASCII 83728 34 Network File System NFS ONC RPC RDMA RDDP iWARP InfiniBand

This document describes a protocol providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC). The RDMA transport binding conveys the benefits of efficient, bulk-data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. [STANDARDS-TRACK]

draft-ietf-nfsv4-rpcrdma-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5666
RFC5667 Network File System (NFS) Direct Data Placement T. Talpey B. Callaghan January 2010 ASCII 83728 10 Network File System NFS ONC RPC RDMA RDDP iWARP InfiniBand

This document defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4, and 4.1 over such an RDMA transport. [STANDARDS-TRACK]

draft-ietf-nfsv4-nfsdirect-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5667
RFC5668 4-Octet AS Specific BGP Extended Community Y. Rekhter S. Sangli D. Tappan October 2009 ASCII 9017 5 border gateway protocol autonomous system

This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. [STANDARDS-TRACK]

draft-ietf-l3vpn-as4octet-ext-community-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC5668
RFC5669 The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) S. Yoon J. Kim H. Park H. Jeong Y. Won August 2010 ASCII 24918 13

This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]

draft-ietf-avt-seed-srtp-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5669
RFC5670 Metering and Marking Behaviour of PCN-Nodes P. Eardley Editor November 2009 ASCII 44363 20 pre-congestion notification threshold metering threshold marking pcn-threshold-rate pcn-excess-rate

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. [STANDARDS-TRACK]

draft-ietf-pcn-marking-behaviour-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5670 10.17487/RFC5670
RFC5671 Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) S. Yasukawa A. Farrel Editor October 2009 ASCII 35176 15 multiprotocol label switching generalized mpls

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs).

This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate. This memo provides information for the Internet community.

draft-ietf-pce-p2mp-app-02 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5671
RFC5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update D. Crocker Editor August 2009 ASCII 29677 14 DKIM email authentication security spam abuse errata trust Signing Domain Identifier SDID AUID Agent or User Identifier

This document updates RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module. The Update is in the style of an Errata entry, albeit a rather long one. [STANDARDS-TRACK]

draft-ietf-dkim-rfc4871-errata-07 RFC6376 RFC4871 PROPOSED STANDARD PROPOSED STANDARD IETF sec dkim 10.17487/RFC5672
RFC5673 Industrial Routing Requirements in Low-Power and Lossy Networks K. Pister Editor P. Thubert Editor S. Dwars T. Phinney October 2009 ASCII 67934 27 lln

The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices. This memo provides information for the Internet community.

draft-ietf-roll-indus-routing-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5673
RFC5674 Alarms in Syslog S. Chisholm R. Gerhards October 2009 ASCII 13837 7 SYSLOG alarm

This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. [STANDARDS-TRACK]

draft-ietf-opsawg-syslog-alarm-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5674
RFC5675 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages V. Marinov J. Schoenwaelder October 2009 ASCII 34379 15 Network Management Simple Network Management Protocol SNMP Notifications Syslog

This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. [STANDARDS-TRACK]

draft-ietf-opsawg-syslog-snmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5675
RFC5676 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications J. Schoenwaelder A. Clemm A. Karmakar October 2009 ASCII 43160 22 Network Management Simple Network Management Protocol SNMP Notifications Syslog

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. [STANDARDS-TRACK]

draft-ietf-opsawg-syslog-msg-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=5676 10.17487/RFC5676
RFC5677 IEEE 802.21 Mobility Services Framework Design (MSFD) T. Melia Editor G. Bajko S. Das N. Golmie JC. Zuniga December 2009 ASCII 57479 25 media independent handover mih mobility services mos

This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for Mobility Services (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server. Instead, it is assumed that either lower-layer (e.g., link-layer) security mechanisms or overall system-specific proprietary security solutions are used. [STANDARDS-TRACK]

draft-ietf-mipshop-mstp-solution-12 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=5677 10.17487/RFC5677
RFC5678 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery G. Bajko S. Das December 2009 ASCII 30489 14 handover preparation handover decision media independent handover services

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677). These Mobility Services are used to assist a mobile node (MN) in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]

draft-ietf-mipshop-mos-dhcp-options-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5678
RFC5679 Locating IEEE 802.21 Mobility Services Using DNS G. Bajko December 2009 ASCII 21127 9 domain name server handover preparation handover decision media independent handover services

This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-defined Mobility Services. Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21, in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]

draft-ietf-mipshop-mos-dns-discovery-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5679
RFC5680 The Nominating Committee Process: Open Disclosure of Willing Nominees S. Dawkins Editor October 2009 ASCII 14296 7

This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-dawkins-nomcom-openlist-06 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5680
RFC5681 TCP Congestion Control M. Allman V. Paxson E. Blanton September 2009 ASCII 44339 18 slow start congestion avoidance fast retransmit fast recovery

This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]

draft-ietf-tcpm-rfc2581bis-07 RFC2581 DRAFT STANDARD DRAFT STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5681 10.17487/RFC5681
RFC5682 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP P. Sarolahti M. Kojo K. Yamamoto M. Hata September 2009 ASCII 47337 19 SACK transmission control protocol loss recovery

The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138.

Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. [STANDARDS-TRACK]

draft-ietf-tcpm-rfc4138bis-04 RFC4138 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5682
RFC5683 Password-Authenticated Key (PAK) Diffie-Hellman Exchange A. Brusilovsky I. Faynberg Z. Zeltsan S. Patel February 2010 ASCII 17820 10

This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange.

The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-brusilovsky-pak-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5683
RFC5684 Unintended Consequences of NAT Deployments with Overlapping Address Space P. Srisuresh B. Ford February 2010 ASCII 63018 26 network address translator

This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks (VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ford-behave-top-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5684
RFC5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) V. Devarapalli K. Weniger November 2009 ASCII 35100 15 IKEv2 Redirect REDIRECT REDIRECTED_FROM anycast redirect home agent redirect VPN gateway direct

The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. [STANDARDS-TRACK]

draft-ietf-ipsecme-ikev2-redirect-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5685
RFC5686 RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec Y. Hiwasaki H. Ohmuro October 2009 ASCII 44924 21 RTP Payload type MIME UEMCLIP PCMU Speech Coding

This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. [STANDARDS-TRACK]

draft-ietf-avt-rtp-uemclip-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5686
RFC5687 GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements H. Tschofenig H. Schulzrinne March 2010 ASCII 40880 21 Location Information Location Information Server Location by Value Location by Reference

This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-geopriv-l7-lcp-ps-10 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5687
RFC5688 A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes J. Rosenberg January 2010 ASCII 15259 7 SIP IMS

The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities. Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability. This specification allows a UA to indicate which application subtypes the agent supports. [STANDARDS-TRACK]

draft-rosenberg-sip-app-media-tag-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5688 10.17487/RFC5688
RFC5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) C. Daboo September 2009 ASCII 19838 12 webdav HTTP

This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. [STANDARDS-TRACK]

draft-ietf-vcarddav-webdav-mkcol-06 RFC4791 RFC4918 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC5689
RFC5690 Adding Acknowledgement Congestion Control to TCP S. Floyd A. Arcia D. Ros J. Iyengar February 2010 ASCII 83437 33 ackcc

This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver. The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-floyd-tcpm-ackcc-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5690
RFC5691 RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio F. de Bont S. Doehla M. Schmidt R. Sperschneider October 2009 ASCII 26189 12 MPEG Surround RFC 3640 RTP MPEG-4 AAC

This memo describes extensions for the RTP payload format defined in RFC 3640 for the transport of MPEG Surround multi-channel audio. Additional Media Type parameters are defined to signal backwards- compatible transmission inside an MPEG-4 Audio elementary stream. In addition, a layered transmission scheme that doesn't use the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mps-03 RFC3640 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5691
RFC5692 Transmission of IP over Ethernet over IEEE 802.16 Networks H. Jeon S. Jeong M. Riegel October 2009 ASCII 44724 21 Bridge WiMAX Ethernet-CS Cellular

This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control (MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. [STANDARDS-TRACK]

draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng 10.17487/RFC5692
RFC5693 Application-Layer Traffic Optimization (ALTO) Problem Statement J. Seedorf E. Burger October 2009 ASCII 34234 14 peer-to-peer p2p

Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.

This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community.

draft-ietf-alto-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF app alto 10.17487/RFC5693
RFC5694 Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability G. Camarillo Editor IAB November 2009 ASCII 68446 26 P2P decentralized architecture

In this document, we provide a survey of P2P (Peer-to-Peer) systems. The survey includes a definition and several taxonomies of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural trade-offs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application. This memo provides information for the Internet community.

draft-iab-p2p-archs-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=5694 10.17487/RFC5694
RFC5695 MPLS Forwarding Benchmarking Methodology for IP Flows A. Akhter R. Asati C. Pignataro November 2009 ASCII 59976 27 multiprotocol label switching mpmls forwarding devices

This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. This memo provides information for the Internet community.

draft-ietf-bmwg-mpls-forwarding-meth-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=5695 10.17487/RFC5695
RFC5696 Baseline Encoding and Transport of Pre-Congestion Information T. Moncaster B. Briscoe M. Menth November 2009 ASCII 33112 15 Quality of Service QoS Differentiated Services Admission Control Codepoint Protocol

The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. [STANDARDS-TRACK]

draft-ietf-pcn-baseline-encoding-07 RFC6660 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5696 10.17487/RFC5696
RFC5697 Other Certificates Extension S. Farrell November 2009 ASCII 17949 8 template

Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pkix-other-certs-05 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC5697
RFC5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) T. Kunz S. Okunick U. Pordesch November 2009 ASCII 76313 40 long term archive security policy hash algorithm public key algorithm

Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future. [STANDARDS-TRACK]

draft-ietf-ltans-dssc-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC5698
RFC5701 IPv6 Address Specific BGP Extended Community Attribute Y. Rekhter November 2009 ASCII 9626 5 border gateway protocol

Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community. The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]

draft-ietf-l3vpn-v6-ext-communities-02 RFC7153 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC5701
RFC5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC J. Jansen October 2009 ASCII 19425 10 DNSSEC RSA SHA-256 SHA-512

This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK]

draft-ietf-dnsext-dnssec-rsasha256-14 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5702
RFC5703 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure T. Hansen C. Daboo October 2009 ASCII 34718 18 Email Electronic Mail Internet Mail Message Filtering

This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. [STANDARDS-TRACK]

draft-ietf-sieve-mime-loop-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5703
RFC5704 Uncoordinated Protocol Development Considered Harmful S. Bryant Editor M. Morrow Editor IAB November 2009 ASCII 36383 15 ITU-T MPLS-TP T-MPLS Joint working team JWT

This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.

This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.

Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.

draft-iab-mpls-tp-uncoord-harmful-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5704
RFC5705 Keying Material Exporters for Transport Layer Security (TLS) E. Rescorla March 2010 ASCII 16346 7 key establishment

A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK]

draft-ietf-tls-extractor-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5705 10.17487/RFC5705
RFC5706 Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions D. Harrington November 2009 ASCII 82165 35 management operations

New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. This memo provides information for the Internet community.

draft-ietf-opsawg-operations-and-management-09 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC5706
RFC5707 Media Server Markup Language (MSML) A. Saleem Y. Xin G. Sharratt February 2010 ASCII 376984 184

The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXMLThis document is not an Internet Standards Track specification; it is published for informational purposes.

draft-saleem-msml-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5707 10.17487/RFC5707
RFC5708 X.509 Key and Signature Encoding for the KeyNote Trust Management System A. Keromytis January 2010 ASCII 12529 6

This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.

In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-keromytis-keynote-x509-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5708 10.17487/RFC5708
RFC5709 OSPFv2 HMAC-SHA Cryptographic Authentication M. Bhatia V. Manral M. Fanto R. White M. Barnes T. Li R. Atkinson October 2009 ASCII 30221 14 open shortest path first nist secure hash standard hashed message authentication code

This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]

draft-ietf-ospf-hmac-sha-07 RFC2328 RFC7474 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5709 10.17487/RFC5709
RFC5710 PathErr Message Triggered MPLS and GMPLS LSP Reroutes L. Berger D. Papadimitriou JP. Vasseur January 2010 ASCII 27233 12 resource reservation protocol rsvp multiprotocol label switching generalized mpls rsvp-te

This document describes how Resource ReserVation Protocol (RSVP) PathErr messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values. [STANDARDS-TRACK]

draft-ietf-mpls-gmpls-lsp-reroute-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5710
RFC5711 Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages JP. Vasseur Editor G. Swallow I. Minei January 2010 ASCII 12596 7 rsvp-te

The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions. [STANDARDS-TRACK]

draft-ietf-mpls-3209-patherr-06 RFC3209 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5711
RFC5712 MPLS Traffic Engineering Soft Preemption M. Meyer Editor JP. Vasseur Editor January 2010 ASCII 27371 13 multiprotocol label switching mpls-te te lsp

This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS-TRACK]

draft-ietf-mpls-soft-preemption-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5712
RFC5713 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) H. Moustafa H. Tschofenig S. De Cnodder January 2010 ASCII 39600 18 ANCP security ANCP threats ANCP attacks

The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.

This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ancp-security-threats-08 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC5713
RFC5714 IP Fast Reroute Framework M. Shand S. Bryant January 2010 ASCII 32854 15 IP Fast Reroute MPLS Fast Reroute Routing Convergence Network Topology loop-free-convergence

This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-rtgwg-ipfrr-framework-13 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC5714
RFC5715 A Framework for Loop-Free Convergence M. Shand S. Bryant January 2010 ASCII 53223 22 IP Fast Reroute MPLS Fast Reroute Routing Convergence Network Topology PLSN not-via Incremental Cost Packet Marking ordered fib ofib

A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.

This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-rtgwg-lf-conv-frmwk-07 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC5715
RFC5716 Requirements for Federated File Systems J. Lentini C. Everhart D. Ellard R. Tewari M. Naik January 2010 ASCII 58051 26 Federated File Systems Federated FA FedFS Fed-FS Federation

This document describes and lists the functional requirements of a federated file system and defines related terms. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-nfsv4-federated-fs-reqts-06 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC5716
RFC5717 Partial Lock Remote Procedure Call (RPC) for NETCONF B. Lengyel M. Bjorklund December 2009 ASCII 42529 23 YANG Network Management

The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. [STANDARDS-TRACK]

draft-ietf-netconf-partial-lock-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=5717 10.17487/RFC5717
RFC5718 An In-Band Data Communication Network For the MPLS Transport Profile D. Beller A. Farrel January 2010 ASCII 18997 8 MPLS-TP DCN SCN MCN G-Ach GAL

The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology.

This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. [STANDARDS-TRACK]

draft-ietf-mpls-tp-gach-dcn-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5718
RFC5719 Updated IANA Considerations for Diameter Command Code Allocations D. Romascanu H. Tschofenig January 2010 ASCII 11268 5 diameter application diameter commands

The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.

This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. [STANDARDS-TRACK]

draft-ietf-dime-diameter-cmd-iana-01 RFC6733 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5719
RFC5720 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) F. Templin February 2010 ASCII 65956 26 enterprise network

RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-templin-ranger-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5720
RFC5721 POP3 Support for UTF-8 R. Gellens C. Newman February 2010 ASCII 26250 13 POP UTF8 mail email internationalization charset

This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. This document defines an Experimental Protocol for the Internet community.

draft-ietf-eai-pop-09 RFC6856 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5721
RFC5722 Handling of Overlapping IPv6 Fragments S. Krishnan December 2009 ASCII 11838 6 fragmentation overlapping fragments

The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]

draft-ietf-6man-overlap-fragment-03 RFC2460 RFC6946 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5722 10.17487/RFC5722
RFC5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption Y. Sheffer H. Tschofenig January 2010 ASCII 59201 26 IKE Internet Key Exchange session resumption failover high availability cryptographic ticket cryptographic token stateful resumption stateless resumption

The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency.

To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment.

In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.

A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. [STANDARDS-TRACK]

draft-ietf-ipsecme-ikev2-resumption-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5723
RFC5724 URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS) E. Wilde A. Vaha-Sipila January 2010 ASCII 39345 18 GSM SMS URI scheme

This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. [STANDARDS-TRACK]

draft-wilde-sms-uri-20 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5724 10.17487/RFC5724
RFC5725 Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) A. Begen D. Hsu M. Lague February 2010 ASCII 18794 9 Loss repair retransmission FEC

This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avt-post-repair-rtcp-xr-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5725 10.17487/RFC5725
RFC5726 Mobile IPv6 Location Privacy Solutions Y. Qiu F. Zhao Editor R. Koodli February 2010 ASCII 116016 48 mobopts

Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-mobopts-location-privacy-solutions-16 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5726
RFC5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area J. Peterson C. Jennings R. Sparks March 2010 ASCII 35033 14 RAI sipping

This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC 3427. This memo documents an Internet Best Current Practice.

draft-peterson-rai-rfc3427bis-04 RFC3427 RFC3265 RFC3969 BCP0067 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5727 10.17487/RFC5727
RFC5728 The SatLabs Group DVB-RCS MIB S. Combes P. Amundsen M. Lambert H-P. Lexow March 2010 ASCII 186132 95 management information base digital video broadcasting return channel DVB-RCS-MIB

This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-combes-ipdvb-mib-rcs-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5728 10.17487/RFC5728
RFC5729 Clarifications on the Routing of Diameter Requests Based on the Username and the Realm J. Korhonen Editor M. Jones L. Morand T. Tsou December 2009 ASCII 23482 11 nai network access identifier decorated multi-realm

This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. [STANDARDS-TRACK]

draft-ietf-dime-nai-routing-04 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5729
RFC5730 Extensible Provisioning Protocol (EPP) S. Hollenbeck August 2009 ASCII 134464 67 shared framework mapping

This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]

draft-hollenbeck-rfc4930bis-02 RFC4930 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5730 10.17487/RFC5730
RFC5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck August 2009 ASCII 87764 44 EPP Extensible Provisioning Protocol XML domain domain name

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK]

draft-hollenbeck-rfc4931bis-01 RFC4931 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5731 10.17487/RFC5731
RFC5732 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck August 2009 ASCII 56219 29 EPP Extensible Provisioning Protocol XML host

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK]

draft-hollenbeck-rfc4932bis-01 RFC4932 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC5732
RFC5733 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck August 2009 ASCII 80698 41 EPP Extensible Provisioning Protocol XML contact registrant

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK]

draft-hollenbeck-rfc4933bis-02 RFC4933 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC5733
RFC5734 Extensible Provisioning Protocol (EPP) Transport over TCP S. Hollenbeck August 2009 ASCII 27887 13 EPP Extensible Provisioning Protocol XML TCP TLS

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]

draft-hollenbeck-rfc4934bis-01 RFC4934 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5734 10.17487/RFC5734
RFC5735 Special Use IPv4 Addresses M. Cotton L. Vegoda January 2010 ASCII 20369 10 internet protocol space assignments

This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice.

draft-iana-rfc3330bis-11 RFC3330 RFC6890 RFC6598 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5735 10.17487/RFC5735
RFC5736 IANA IPv4 Special Purpose Address Registry G. Huston M. Cotton L. Vegoda January 2010 ASCII 10823 6

This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iana-special-ipv4-registry-02 RFC6890 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5736
RFC5737 IPv4 Address Blocks Reserved for Documentation J. Arkko M. Cotton L. Vegoda January 2010 ASCII 7036 4 example addresses IPv4

Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iana-ipv4-examples-02 RFC1166 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5737
RFC5738 IMAP Support for UTF-8 P. Resnick C. Newman March 2010 ASCII 32061 15 internet message access protocol imap4rev1

This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This document defines an Experimental Protocol for the Internet community.

draft-ietf-eai-imap-utf8-09 RFC6855 RFC3501 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5738 10.17487/RFC5738
RFC5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) P. Eronen J. Laganier C. Madson February 2010 ASCII 67691 32 remote vpn access vpn gateway virtual link

When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". This document defines an Experimental Protocol for the Internet community.

draft-ietf-ipsecme-ikev2-ipv6-config-03 EXPERIMENTAL EXPERIMENTAL IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=5739 10.17487/RFC5739
RFC5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol B. Adamson C. Bormann M. Handley J. Macker November 2009 ASCII 268831 96 multicast reliable multicast transport negative-acknowledgment forward error correction packet erasure coding group communication

This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. [STANDARDS-TRACK]

draft-ietf-rmt-pi-norm-revised-14 RFC3940 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5740
RFC5741 RFC Streams, Headers, and Boilerplates L. Daigle Editor O. Kolkman Editor IAB December 2009 ASCII 32160 16

RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-streams-headers-boilerplates-08 RFC2223 RFC4844 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=5741 10.17487/RFC5741
RFC5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions H. Alvestrand R. Housley December 2009 ASCII 21067 9

This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.

This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.

draft-housley-iesg-rfc3932bis-12 RFC3932 RFC2026 RFC3710 BCP0092 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5742
RFC5743 Definition of an Internet Research Task Force (IRTF) Document Stream A. Falk December 2009 ASCII 19885 9 irtf stream

This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-rfcs-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5743
RFC5744 Procedures for Rights Handling in the RFC Independent Submission Stream R. Braden J. Halpern December 2009 ASCII 13509 6 incoming rights outgoing rights ietf trust

This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.

draft-braden-independent-submission-02 RFC4846 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5744
RFC5745 Procedures for Rights Handling in the RFC IAB Stream A. Malis Editor IAB December 2009 ASCII 12518 6 incoming rights outgoing rights ietf trust

This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.

draft-malis-iab-stream-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5745
RFC5746 Transport Layer Security (TLS) Renegotiation Indication Extension E. Rescorla M. Ray S. Dispensa N. Oskov February 2010 ASCII 33790 15 ssl secure socket layer

Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK]

draft-ietf-tls-renegotiation-03 RFC5246 RFC4366 RFC4347 RFC4346 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC5746
RFC5747 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions J. Wu Y. Cui X. Li M. Xu C. Metz March 2010 ASCII 33768 15 IPv4/IPv6 coexistence CNGI CERNET2 Softwire mesh

The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China. This document defines an Experimental Protocol for the Internet community.

draft-wu-softwire-4over6-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC5747
RFC5748 IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY) S. Yoon J. Jeong H. Kim H. Jeong Y. Won August 2010 ASCII 8198 5

This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-seokung-msec-mikey-seed-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5748 10.17487/RFC5748
RFC5749 Distribution of EAP-Based Keys for Handover and Re-Authentication K. Hoeper Editor M. Nakhjiri Y. Ohba Editor March 2010 ASCII 27242 12 security authentication mobility EAP key management key distribution

This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]

draft-ietf-hokey-key-mgm-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5749 10.17487/RFC5749
RFC5750 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling B. Ramsdell S. Turner January 2010 ASCII 48716 21 encryption certificate multipurpose internet mail extensions secure

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. [STANDARDS-TRACK]

draft-ietf-smime-3850bis-11 RFC3850 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC5750
RFC5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification B. Ramsdell S. Turner January 2010 ASCII 98638 45 secure multipurpose internet mail extensions encryption

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK]

draft-ietf-smime-3851bis-11 RFC3851 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5751 10.17487/RFC5751
RFC5752 Multiple Signatures in Cryptographic Message Syntax (CMS) S. Turner J. Schaad January 2010 ASCII 34502 17 signeddata signerinfo downgrade attacks algorithm migration

Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK]

draft-ietf-smime-multisig-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5752 10.17487/RFC5752
RFC5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) S. Turner D. Brown January 2010 ASCII 112095 61 public key digital signatures authentication

This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-smime-3278bis-09 RFC3278 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5753
RFC5754 Using SHA2 Algorithms with Cryptographic Message Syntax S. Turner January 2010 ASCII 21543 10 secure hash algorithm message digest algorithm sha-224 sha-256 sha-384 sha-512 cms dsa digital signature algorithm rsa rivest sharmi adleman ecdsa elliptic curve dsa smimecapabilities

This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]

draft-ietf-smime-sha2-11 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5754 10.17487/RFC5754
RFC5755 An Internet Attribute Certificate Profile for Authorization S. Farrell R. Housley S. Turner January 2010 ASCII 101482 50 electronic mail email ipsec www security

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK]

draft-ietf-pkix-3281update-05 RFC3281 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5755 10.17487/RFC5755
RFC5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters S. Turner D. Brown K. Yiu R. Housley T. Polk January 2010 ASCII 12017 6 rsa encryption scheme optical asymmetric encryption padding subjectpublickeyinfo

This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK]

draft-ietf-pkix-rfc4055-update-02 RFC4055 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5756 10.17487/RFC5756
RFC5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey T. Schmidt M. Waehlisch G. Fairhurst February 2010 ASCII 92632 37 PMIPv6 FMIPv6 HMIPv6 SSM ASM MLD Mobile Multicast Routing Hybrid Multicast Wireless Multipoint

This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-mobopts-mmcastv6-ps-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5757
RFC5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Q. Dang S. Santesson K. Moriarty D. Brown T. Polk January 2010 ASCII 15834 8 digital signature algorithm elliptic curve digital signature algorithm pki

This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK]

draft-ietf-pkix-sha2-dsa-ecdsa-10 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5758 10.17487/RFC5758
RFC5759 Suite B Certificate and Certificate Revocation List (CRL) Profile J. Solinas L. Zieglar January 2010 ASCII 21429 11 x.509 v3 certificates x.509 v2 certificate revocation lists crl

This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-solinas-suiteb-cert-profile-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5759
RFC5760 RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback J. Ott J. Chesterfield E. Schooler February 2010 ASCII 160368 66 real-time transport protocol ssm

This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK]

draft-ietf-avt-rtcpssm-19 RFC6128 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5760 10.17487/RFC5760
RFC5761 Multiplexing RTP Data and Control Packets on a Single Port C. Perkins M. Westerlund April 2010 ASCII 31778 13

This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK]

draft-ietf-avt-rtp-and-rtcp-mux-07 RFC3550 RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5761 10.17487/RFC5761
RFC5762 RTP and the Datagram Congestion Control Protocol (DCCP) C. Perkins April 2010 ASCII 37537 16 real-time transport protocol

The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. [STANDARDS-TRACK]

draft-ietf-dccp-rtp-07 RFC6773 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5762
RFC5763 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) J. Fischl H. Tschofenig E. Rescorla May 2010 ASCII 81546 37 stip session initiation protocol fingerprint attribute dtls handshake

This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK]

draft-ietf-sip-dtls-srtp-framework-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5763 10.17487/RFC5763
RFC5764 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) D. McGrew E. Rescorla May 2010 ASCII 60590 26 secure rtp control protocol srtcp

This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]

draft-ietf-avt-dtls-srtp-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5764 10.17487/RFC5764
RFC5765 Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications H. Schulzrinne E. Marocco E. Ivov February 2010 ASCII 72134 28 p2p overlay rtc voip

Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2P Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-p2prg-rtc-security-05 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5765 10.17487/RFC5765
RFC5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) R. Mahy P. Matthews J. Rosenberg April 2010 ASCII 172112 67 NAT TURN STUN ICE

If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS-TRACK]

draft-ietf-behave-turn-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5766 10.17487/RFC5766
RFC5767 User-Agent-Driven Privacy Mechanism for SIP M. Munakata S. Schubert T. Ohba April 2010 ASCII 23270 11 SIP IMS privacy guidelines

This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sip-ua-privacy-08 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC5767
RFC5768 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) J. Rosenberg April 2010 ASCII 12962 6 SIP NAT

This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE. The option tag allows a UA to require support for ICE in order for a call to proceed. [STANDARDS-TRACK]

draft-ietf-sip-ice-option-tag-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5768
RFC5769 Test Vectors for Session Traversal Utilities for NAT (STUN) R. Denis-Courmont April 2010 ASCII 15407 11 STUN test vectors fingerprint

The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-behave-stun-test-vectors-04 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC5769
RFC5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators M. Komu T. Henderson H. Tschofenig J. Melen A. Keranen Editor April 2010 ASCII 79767 34 ICE HIP relay

This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-nat-traversal-09 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5770
RFC5771 IANA Guidelines for IPv4 Multicast Address Assignments M. Cotton L. Vegoda D. Meyer March 2010 ASCII 22239 11 internet assigned numbers authority protocol parameters

This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780. This memo documents an Internet Best Current Practice.

draft-ietf-mboned-rfc3171bis-08 RFC3138 RFC3171 RFC2780 BCP0051 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=5771 10.17487/RFC5771
RFC5772 A Set of Possible Requirements for a Future Routing Architecture A. Doria E. Davies F. Kastenholz February 2010 ASCII 158456 68 Routing Research Group RRG IDR FDR

The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group (RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future.

The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.

draft-irtf-routing-reqs-11 HISTORIC HISTORIC IRTF 10.17487/RFC5772
RFC5773 Analysis of Inter-Domain Routing Requirements and History E. Davies A. Doria February 2010 ASCII 127384 51 History IRTF Routing Research Group RRG Routing Requirements IDR FDR

This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" (RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.

draft-irtf-routing-history-10 HISTORIC HISTORIC IRTF http://www.rfc-editor.org/errata_search.php?rfc=5773 10.17487/RFC5773
RFC5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition K. Wolf A. Mayrhofer March 2010 ASCII 68468 33

This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria. This memo documents an Internet Best Current Practice.

draft-ietf-geopriv-civic-address-recommendations-03 RFC4776 BCP0154 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5774 10.17487/RFC5774
RFC5775 Asynchronous Layered Coding (ALC) Protocol Instantiation M. Luby M. Watson L. Vicisano April 2010 ASCII 59518 24 Forward Error Correction FEC Layered Coding Transport LCT Building Block WEBRC reliable +object delivery reliable file delivery broadcast multicast

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450. [STANDARDS-TRACK]

draft-ietf-rmt-pi-alc-revised-10 RFC3450 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5775
RFC5776 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca A. Francillon S. Faurite April 2010 ASCII 135605 58 TESLA FLUTE ALC NORM

This document details the Timed Efficient Stream \%Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. This document defines an Experimental Protocol for the Internet community.

draft-ietf-msec-tesla-for-alc-norm-10 EXPERIMENTAL EXPERIMENTAL IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=5776 10.17487/RFC5776
RFC5777 Traffic Classification and Quality of Service (QoS) Attributes for Diameter J. Korhonen H. Tschofenig M. Arumaithurai M. Jones Editor A. Lior February 2010 ASCII 91305 43 Diameter Qos Attributes Traffic classification Filtering Firewalling

This document defines a number of Diameter attribute-value pairs (AVPs) for traffic classification with actions for filtering and Quality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy. [STANDARDS-TRACK]

draft-ietf-dime-qos-attributes-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5777 10.17487/RFC5777
RFC5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction J. Korhonen Editor H. Tschofenig J. Bournelle G. Giaretta M. Nakhjiri February 2010 ASCII 75444 34

Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and a Diameter server.

This document defines the home agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document. [STANDARDS-TRACK]

draft-ietf-dime-mip6-split-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5778 10.17487/RFC5778
RFC5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server J. Korhonen Editor J. Bournelle K. Chowdhury A. Muhanna U. Meyer February 2010 ASCII 44709 20 aaa authentication authorization and accounting

This specification defines Authentication, Authorization, and Accounting (AAA) interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain. These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. [STANDARDS-TRACK]

draft-ietf-dime-pmip6-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5779
RFC5780 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) D. MacDonald B. Lowekamp May 2010 ASCII 67835 27 NAT type diagnostics

This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server. This document defines an Experimental Protocol for the Internet community.

draft-ietf-behave-nat-behavior-discovery-08 EXPERIMENTAL EXPERIMENTAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5780 10.17487/RFC5780
RFC5781 The rsync URI Scheme S. Weiler D. Ward R. Housley February 2010 ASCII 6704 4 rsyncuri

This document specifies the rsync Uniform Resource Identifier (URI) scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-weiler-rsync-uri-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5781
RFC5782 DNS Blacklists and Whitelists J. Levine February 2010 ASCII 25296 11 mail electronic mail DNS spam blacklist whitelist

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-asrg-dnsbl-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5782 10.17487/RFC5782
RFC5783 Congestion Control in the RFC Series M. Welzl W. Eddy February 2010 ASCII 68231 28

This document is an informational snapshot taken by the IRTF\'s Internet Congestion Control Research Group (ICCRG) in October 2008. It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-iccrg-cc-rfcs-07 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5783 10.17487/RFC5783
RFC5784 Sieve Email Filtering: Sieves and Display Directives in XML N. Freed S. Vedam March 2010 ASCII 57087 32 SMTP ESMTP Sieve

This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools.

The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. [STANDARDS-TRACK]

draft-freed-sieve-in-xml-07 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5784 10.17487/RFC5784
RFC5785 Defining Well-Known Uniform Resource Identifiers (URIs) M. Nottingham E. Hammer-Lahav April 2010 ASCII 13779 8 well-known locations

This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]

draft-nottingham-site-meta-05 RFC2616 RFC2818 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5785 10.17487/RFC5785
RFC5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions R. Aggarwal K. Kompella March 2010 ASCII 15541 7

OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID.

In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.

This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]

draft-ietf-ospf-te-node-addr-07 RFC3630 RFC6827 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5786 10.17487/RFC5786
RFC5787 OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing D. Papadimitriou March 2010 ASCII 67247 29 itu-t ospfv2 link state routing protocol

The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.

Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ccamp-gmpls-ason-routing-ospf-09 RFC6827 EXPERIMENTAL EXPERIMENTAL IETF rtg ccamp 10.17487/RFC5787
RFC5788 IMAP4 Keyword Registry A. Melnikov D. Cridland March 2010 ASCII 22497 11 IMAP email tag label keyword

The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. [STANDARDS TRACK]

draft-melnikov-imap-keywords-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5788
RFC5789 PATCH Method for HTTP L. Dusseault J. Snell March 2010 ASCII 21706 10 HTTP PATCH Hypertext Transfer Protocol

Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]

draft-dusseault-http-patch-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5789 10.17487/RFC5789
RFC5790 Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols H. Liu W. Cao H. Asaeda February 2010 ASCII 39394 17 IGMP MLD Lite lightweight

This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK]

draft-ietf-mboned-lightweight-igmpv3-mldv2-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC5790
RFC5791 RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete J. Reschke J. Kunze February 2010 ASCII 3658 2 DCMI Dublin Core Metadata Initiative XHTML HTML metadata

This document obsoletes RFC 2731, "Encoding Dublin Core Metadata in HTML", as further development of this specification has moved to the Dublin Core Metadata Initiative (DCMI). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-reschke-rfc2731bis-05 RFC2731 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5791 10.17487/RFC5791
RFC5792 PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) P. Sangster K. Narayan March 2010 ASCII 193345 83

This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]

draft-ietf-nea-pa-tnc-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea http://www.rfc-editor.org/errata_search.php?rfc=5792 10.17487/RFC5792
RFC5793 PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) R. Sahita S. Hanna R. Hurst K. Narayan March 2010 ASCII 169140 76 NEA Network Endpoint Assessment

This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]

draft-ietf-nea-pb-tnc-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea http://www.rfc-editor.org/errata_search.php?rfc=5793 10.17487/RFC5793
RFC5794 A Description of the ARIA Encryption Algorithm J. Lee J. Lee J. Kim D. Kwon C. Kim March 2010 ASCII 31049 18 ARIA encryption block cipher

This document describes the ARIA encryption algorithm. ARIA is a 128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of a key scheduling part and data randomizing part. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-nsri-aria-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5794 10.17487/RFC5794
RFC5795 The RObust Header Compression (ROHC) Framework K. Sandlund G. Pelletier L-E. Jonsson March 2010 ASCII 89850 41

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.

This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK]

draft-ietf-rohc-rfc4995bis-03 RFC4995 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5795 10.17487/RFC5795
RFC5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages W. Atwood S. Islam M. Siami March 2010 ASCII 45442 21 security PIM-SM routing security multicast routing link-local message Protocol Independent Multicast Sparse Mode

RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. [STANDARDS-TRACK]

draft-ietf-pim-sm-linklocal-10 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC5796
RFC5797 FTP Command and Extension Registry J. Klensin A. Hoenes March 2010 ASCII 24535 10 FTP FEAT command FTP FEAT response

Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. [STANDARDS-TRACK]

draft-klensin-ftp-registry-04 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5797 10.17487/RFC5797
RFC5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 S. Nadas Editor March 2010 ASCII 90322 40

This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]

draft-ietf-vrrp-unified-spec-05 RFC3768 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp 10.17487/RFC5798
RFC5801 Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family S. Josefsson N. Williams July 2010 ASCII 52543 26

This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS-TRACK]

draft-ietf-sasl-gs2-20 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=5801 10.17487/RFC5801
RFC5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms C. Newman A. Menon-Sen A. Melnikov N. Williams July 2010 ASCII 59049 28 simple authentication and security layer

The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.

This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK]

draft-ietf-sasl-scram-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=5802 10.17487/RFC5802
RFC5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets A. Melnikov July 2010 ASCII 8195 4 authpassword simple authentication and security layer sasl

This memo describes how the "authPassword" Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-melnikov-sasl-scram-ldap-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5803 10.17487/RFC5803
RFC5804 A Protocol for Remotely Managing Sieve Scripts A. Melnikov Editor T. Martin July 2010 ASCII 103194 49 managesieve

Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. [STANDARDS TRACK]

draft-ietf-sieve-managesieve-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5804 10.17487/RFC5804
RFC5805 Lightweight Directory Access Protocol (LDAP) Transactions K. Zeilenga March 2010 ASCII 21723 11 acid atomic consistency isolation durability

Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. This document defines an Experimental Protocol for the Internet community.

draft-zeilenga-ldap-txn-15 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC5805
RFC5806 Diversion Indication in SIP S. Levy M. Mohali Editor March 2010 ASCII 107160 53

This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs. The original Abstract follows.

This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent.

This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions. This document defines a Historic Document for the Internet community.

draft-levy-sip-diversion-11 HISTORIC HISTORIC INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5806 10.17487/RFC5806
RFC5807 Definition of Master Key between PANA Client and Enforcement Point Y. Ohba A. Yegin March 2010 ASCII 13808 7 protocol for carrying authentication for network access

This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. [STANDARDS-TRACK]

draft-ohba-pana-pemk-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5807
RFC5808 Requirements for a Location-by-Reference Mechanism R. Marshall Editor May 2010 ASCII 32475 14

This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-geopriv-lbyr-requirements-09 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5808
RFC5810 Forwarding and Control Element Separation (ForCES) Protocol Specification A. Doria Editor J. Hadi Salim Editor R. Haas Editor H. Khosravi Editor W. Wang Editor L. Dong R. Gopal J. Halpern March 2010 ASCII 239754 124 control elements forwarding elements fe ce network element ne tml transport mapping layer

This document specifies the Forwarding and Control Element Separation (ForCES) protocol. The ForCES protocol is used for communications between Control Elements (CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). [STANDARDS-TRACK]

draft-ietf-forces-protocol-22 RFC7121 RFC7391 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=5810 10.17487/RFC5810
RFC5811 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol J. Hadi Salim K. Ogawa March 2010 ASCII 61443 28 ForCES TML stream conrol transmission protocol

This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. [STANDARDS TRACK]

draft-ietf-forces-sctptml-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC5811
RFC5812 Forwarding and Control Element Separation (ForCES) Forwarding Element Model J. Halpern J. Hadi Salim March 2010 ASCII 301491 134 forwarding element control element

This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654. [STANDARDS-TRACK]

draft-ietf-forces-model-16 RFC7408 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=5812 10.17487/RFC5812
RFC5813 Forwarding and Control Element Separation (ForCES) MIB R. Haas March 2010 ASCII 31353 17 management information base network element ne forces-mib

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). [STANDARDS-TRACK]

draft-ietf-forces-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC5813
RFC5814 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks W. Sun Editor G. Zhang Editor March 2010 ASCII 93386 44 Signaling performance RSVP-TE delay measurement control plane performance

Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other.

This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. [STANDARDS-TRACK]

draft-ietf-ccamp-lsp-dppm-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5814
RFC5815 Definitions of Managed Objects for IP Flow Information Export T. Dietz Editor A. Kobayashi B. Claise G. Muenz April 2010 ASCII 131258 64 Selector Collector Exporter Sampling Filtering IPFIX IPFIX-MIB IPFIX-SELECTOR-MIB

This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. [STANDARDS-TRACK]

draft-ietf-ipfix-mib-10 RFC6615 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5815 10.17487/RFC5815
RFC5816 ESSCertIDv2 Update for RFC 3161 S. Santesson N. Pope April 2010 ASCII 10216 5 signer certificate secure hash algorithm sha-1

This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1). [STANDARDS-TRACK]

draft-ietf-pkix-rfc3161-update-09 RFC3161 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5816
RFC5817 Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks Z. Ali JP. Vasseur A. Zamfir J. Newton April 2010 ASCII 24219 11 mpls-te te

MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.

This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-mpls-graceful-shutdown-13 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5817
RFC5818 Data Channel Status Confirmation Extensions for the Link Management Protocol D. Li H. Xu S. Bardalai J. Meuric D. Caviglia April 2010 ASCII 34092 15 LMP

This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. [STANDARDS-TRACK]

draft-ietf-ccamp-confirm-data-channel-status-09 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5818
RFC5819 IMAP4 Extension for Returning STATUS Information in Extended LIST A. Melnikov T. Sirainen March 2010 ASCII 10584 6 list lsub

Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. [STANDARDS-TRACK]

draft-ietf-morg-status-in-list-01 PROPOSED STANDARD PROPOSED STANDARD IETF app morg http://www.rfc-editor.org/errata_search.php?rfc=5819 10.17487/RFC5819
RFC5820 Extensions to OSPF to Support Mobile Ad Hoc Networking A. Roy Editor M. Chandra Editor March 2010 ASCII 95603 41 open shortest path first manet ospf-or ospf-overlapping relay link-local signaling lls ospf-manet

This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. [STANDARDS-TRACK]

draft-ietf-ospf-manet-or-03 RFC7137 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC5820
RFC5824 Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN K. Kumaki Editor R. Zhang Y. Kamite April 2010 ASCII 56102 27 triple-play service

Today, customers expect to run triple-play services through BGP/MPLS IP-VPNs. Some service providers will deploy services that request Quality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.

Service providers can use both an MPLS and an MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP-VPN. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-l3vpn-e2e-rsvp-te-reqts-05 INFORMATIONAL INFORMATIONAL IETF rtg l3vpn 10.17487/RFC5824
RFC5825 Displaying Downgraded Messages for Email Address Internationalization K. Fujiwara B. Leiba April 2010 ASCII 26314 14 EAI Email Address Internationalization Downgrade MAIL

This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields. This document defines an Experimental Protocol for the Internet community.

draft-ietf-eai-downgraded-display-03 RFC6530 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5825
RFC5826 Home Automation Routing Requirements in Low-Power and Lossy Networks A. Brandt J. Buron G. Porcu April 2010 ASCII 38751 17 roll routing over low power and lossy

This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks. In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-roll-home-routing-reqs-11 INFORMATIONAL INFORMATIONAL IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=5826 10.17487/RFC5826
RFC5827 Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) M. Allman K. Avrachenkov U. Ayesta J. Blanton P. Hurtig May 2010 ASCII 35383 15 transmission control protocol fast retransmission

This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. [STANDARDS-TRACK]

draft-ietf-tcpm-early-rexmt-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC5827
RFC5828 Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework D. Fedyk L. Berger L. Andersson March 2010 ASCII 46396 20 transport networks

There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized- MPLS-based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-gmpls-ethernet-arch-09 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5828
RFC5829 Link Relation Types for Simple Version Navigation between Web Resources A. Brown G. Clemm J. Reschke Editor April 2010 ASCII 18649 12

This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-brown-versioning-link-relations-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5829
RFC5830 GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms V. Dolmatov Editor March 2010 ASCII 36234 19 russian federal standard electronic encryption decryption message authentication russian cryptographic standard

This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-dolmatov-cryptocom-gost2814789-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5830 10.17487/RFC5830
RFC5831 GOST R 34.11-94: Hash Function Algorithm V. Dolmatov Editor March 2010 ASCII 25844 17 russian federal standard russian cryptographic standard russian cryptography

This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-dolmatov-cryptocom-gost341194-07 RFC6986 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5831 10.17487/RFC5831
RFC5832 GOST R 34.10-2001: Digital Signature Algorithm V. Dolmatov Editor March 2010 ASCII 38936 22 russian federal standard digital signature russian cryptographic standard russian cryptography

This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification.

draft-dolmatov-cryptocom-gost34102001-08 RFC7091 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5832 10.17487/RFC5832
RFC5833 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB Y. Shi Editor D. Perkins Editor C. Elliott Editor Y. Zhang Editor May 2010 ASCII 143911 73 mib CAPWAP-BASE-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-capwap-base-mib-09 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5833
RFC5834 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11 Y. Shi Editor D. Perkins Editor C. Elliott Editor Y. Zhang Editor May 2010 ASCII 51144 25 mib CAPWAP-DOT11-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding. This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple Network Management Protocol (SNMP). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-capwap-802dot11-mib-06 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5834
RFC5835 Framework for Metric Composition A. Morton Editor S. Van den Berghe Editor April 2010 ASCII 38138 18

This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-framework-compagg-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5835
RFC5836 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement Y. Ohba Editor Q. Wu Editor G. Zorn Editor April 2010 ASCII 45912 20 eap early authentication

Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This document discusses the EAP early authentication problem in detail. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-hokey-preauth-ps-12 INFORMATIONAL INFORMATIONAL IETF sec hokey 10.17487/RFC5836
RFC5837 Extending ICMP for Interface and Next-Hop Identification A. Atlas Editor R. Bonica Editor C. Pignataro Editor N. Shen JR. Rivers April 2010 ASCII 38109 18 Internet Control Message Protocol

This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded.

Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. [STANDARDS-TRACK]

draft-atlas-icmp-unnumbered-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5837
RFC5838 Support of Address Families in OSPFv3 A. Lindem Editor S. Mirtorabi A. Roy M. Barnes R. Aggarwal April 2010 ASCII 26193 13 af instance id

This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS-TRACK]

draft-ietf-ospf-af-alt-10 RFC6969 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5838
RFC5839 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification A. Niemi D. Willis Editor May 2010 ASCII 52999 25 SIP events subnot-etags optimization

The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. [STANDARDS-TRACK]

draft-ietf-sipcore-subnot-etags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC5839
RFC5840 Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility K. Grewal G. Montenegro M. Bhatia April 2010 ASCII 34733 15 wesp

This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. [STANDARDS-TRACK]

draft-ietf-ipsecme-traffic-visibility-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5840
RFC5841 TCP Option to Denote Packet Mood R. Hay W. Turkal April 1 2010 ASCII 15024 9

This document proposes a new TCP option to denote packet mood. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-1april2010-tcp-option-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5841 10.17487/RFC5841
RFC5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) G. Clemm J. Crawford J. Reschke Editor J. Whitehead April 2010 ASCII 91544 45 HTTP WebDAV collections hard link

This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created. This document defines an Experimental Protocol for the Internet community.

draft-ietf-webdav-bind-27 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5842
RFC5843 Additional Hash Algorithms for HTTP Instance Digests A. Bryan April 2010 ASCII 6731 5 Hypertext Transfer Protocol HTTP Digest Algorithm Values registry update

The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" defines values for digest algorithms used by Instance Digests in HTTP. Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource. This document adds new values to the registry and updates previous values. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-bryan-http-digest-algorithm-values-update-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5843 10.17487/RFC5843
RFC5844 IPv4 Support for Proxy Mobile IPv6 R. Wakikawa S. Gundavelli May 2010 ASCII 116102 49 NAT traversal Dual Stack Mobility IPv4 Support IPv4 Support for PMIPv6

This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. [STANDARDS-TRACK]

draft-ietf-netlmm-pmip6-ipv4-support-18 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm 10.17487/RFC5844
RFC5845 Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 A. Muhanna M. Khalil S. Gundavelli K. Leung June 2010 ASCII 56198 25 PMIP6 PMIPv6 Downlink GRE Key Uplink GRE Key TLV-Header Tunneling TLV-Header Tunneling GRE Key Exchange

This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. [STANDARDS-TRACK]

draft-ietf-netlmm-grekey-option-09 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm 10.17487/RFC5845
RFC5846 Binding Revocation for IPv6 Mobility A. Muhanna M. Khalil S. Gundavelli K. Chowdhury P. Yegani June 2010 ASCII 95467 39 PMIP6 PMIPv6 Binding Revocation Indication BRI Binding Revocation Acknowledgement BRA MIP6 DSMIP6 Multiple Care-of Addresses PMIPv6 Revocation Bulk PMIPv6 Revocation

This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6. The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries. [STANDARDS-TRACK]

draft-ietf-mext-binding-revocation-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC5846
RFC5847 Heartbeat Mechanism for Proxy Mobile IPv6 V. Devarapalli Editor R. Koodli Editor H. Lim N. Kant S. Krishnan J. Laganier June 2010 ASCII 23317 11 Node Reachability Restarts Failure Detection

Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. [STANDARDS TRACK]

draft-ietf-netlmm-pmipv6-heartbeat-07 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm http://www.rfc-editor.org/errata_search.php?rfc=5847 10.17487/RFC5847
RFC5848 Signed Syslog Messages J. Kelsey J. Callas A. Clemm May 2010 ASCII 102805 40 syslog syslog-sign

This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". [STANDARDS-TRACK]

draft-ietf-syslog-sign-29 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5848
RFC5849 The OAuth 1.0 Protocol E. Hammer-Lahav Editor April 2010 ASCII 80786 38 authorization delegation

OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hammer-oauth-10 RFC6749 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5849 10.17487/RFC5849
RFC5850 A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP) R. Mahy R. Sparks J. Rosenberg D. Petrie A. Johnston Editor May 2010 ASCII 104361 44 call control multiparty features mixing refer 3pcc Refer method Replaces header field Join header field conferencing

This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol (SIP). To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-cc-framework-12 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5850 10.17487/RFC5850
RFC5851 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks S. Ooghe N. Voigt M. Platnic T. Haag S. Wadhwa May 2010 ASCII 116214 47 Access Node Control Protocol Topology Discovery Loop Configuration Remote Connectivity Test Multicast Access Node Network Access Server

The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems.

This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ancp-framework-13 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC5851
RFC5852 RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network D. Caviglia D. Ceccarelli D. Bramanti D. Li S. Bardalai April 2010 ASCII 49293 23 resource reservation protocol handover procedures

In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493.

This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. [STANDARDS-TRACK]

draft-ietf-ccamp-pc-spc-rsvpte-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5852
RFC5853 Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments J. Hautakorpi Editor G. Camarillo R. Penfield A. Hawrylyshen M. Bhatia April 2010 ASCII 60476 26

This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-sbc-funcs-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5853
RFC5854 The Metalink Download Description Format A. Bryan T. Tsujikawa N. McNab P. Poeml June 2010 ASCII 72641 39 file transfer mirrors data integrity hash xml http hypertext transfer protocol ftp file transfer protocol metadata torrent

This document specifies Metalink, an XML-based download description format. Metalink describes download locations (mirrors), cryptographic hashes, and other information. Clients can transparently use this information to reliably transfer files. [STANDARDS-TRACK]

draft-bryan-metalink-28 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5854
RFC5855 Nameservers for IPv4 and IPv6 Reverse Zones J. Abley T. Manderson May 2010 ASCII 23027 12 IN-ADDR.ARPA IP6.ARPA reverse mapping

This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain data that facilitate reverse mapping (address to name). This memo documents an Internet Best Current Practice.

draft-jabley-reverse-servers-01 BCP0155 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5855
RFC5856 Integration of Robust Header Compression over IPsec Security Associations E. Ertekin R. Jasani C. Christou C. Bormann May 2010 ASCII 34548 15 ROHC ROHCoIPsec

IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-rohc-hcoipsec-13 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC5856
RFC5857 IKEv2 Extensions to Support Robust Header Compression over IPsec E. Ertekin C. Christou R. Jasani T. Kivinen C. Bormann May 2010 ASCII 27063 13 ROHC ROHCoIPsec

In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints. Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs). [STANDARDS-TRACK]

draft-ietf-rohc-ikev2-extensions-hcoipsec-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5857 10.17487/RFC5857
RFC5858 IPsec Extensions to Support Robust Header Compression over IPsec E. Ertekin C. Christou C. Bormann May 2010 ASCII 31539 15 ROHC ROHCoIPsec

Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC with IPsec, extensions to the Security Policy Database (SPD) and Security Association Database (SAD) are required. This document describes the IPsec extensions required to support ROHCoIPsec. [STANDARDS-TRACK]

draft-ietf-rohc-ipsec-extensions-hcoipsec-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5858 10.17487/RFC5858
RFC5859 TFTP Server Address Option for DHCPv4 R. Johnson June 2010 ASCII 11656 6 voip

This memo documents existing usage for the "TFTP Server Address" option. The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic Host Configuration working group will try to officially assign those numbers to those options. The option is defined for DHCPv4 and works only with IPv4 addresses. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-raj-dhc-tftp-addr-option-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5859
RFC5860 Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks M. Vigoureux Editor D. Ward Editor M. Betts Editor May 2010 ASCII 36951 17 MPLS-TP OAM

This document lists architectural and functional requirements for the Operations, Administration, and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections. [STANDARDS-TRACK]

draft-ietf-mpls-tp-oam-requirements-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5860
RFC5861 HTTP Cache-Control Extensions for Stale Content M. Nottingham May 2010 ASCII 10359 6

This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-nottingham-http-stale-controls-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5861 10.17487/RFC5861
RFC5862 Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE S. Yasukawa A. Farrel June 2010 ASCII 24219 11 mpls gmpls

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.

Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pce-p2mp-req-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5862
RFC5863 DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations T. Hansen E. Siegel P. Hallam-Baker D. Crocker May 2010 ASCII 126915 51 Email Electronic Mail Internet Mail Message Verification

DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dkim-deployment-11 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5863
RFC5864 DNS SRV Resource Records for AFS R. Allbery April 2010 ASCII 23846 10 domain name system srv rr distributed file system afsdb rr

This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC 1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. [STANDARDS TRACK]

draft-allbery-afs-srv-records-05 RFC1183 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5864 10.17487/RFC5864
RFC5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic F. Baker J. Polk M. Dolly May 2010 ASCII 33167 14 real-time traffic

This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission. [STANDARDS-TRACK]

draft-ietf-tsvwg-admitted-realtime-dscp-07 RFC4542 RFC4594 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=5865 10.17487/RFC5865
RFC5866 Diameter Quality-of-Service Application D. Sun Editor P. McCann H. Tschofenig T. Tsou A. Doria G. Zorn Editor May 2010 ASCII 122639 51 Diameter AAA QoS Policy VoIP SIP

This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation, namely "Pull" and "Push", are defined. [STANDARDS TRACK]

draft-ietf-dime-diameter-qos-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5866
RFC5867 Building Automation Routing Requirements in Low-Power and Lossy Networks J. Martocci Editor P. De Mil N. Riou W. Vermeylen June 2010 ASCII 57123 26

The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in various markets: industrial, commercial (building), home, and urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-roll-building-routing-reqs-09 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5867
RFC5868 Problem Statement on the Cross-Realm Operation of Kerberos S. Sakane K. Kamada S. Zrelli M. Ishiyama May 2010 ASCII 30327 13

This document provides background information regarding large-scale Kerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120.

This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field. Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem of Kerberos cross-realm operations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-krb-wg-cross-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC5868
RFC5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) H. Krawczyk P. Eronen May 2010 ASCII 25854 14

This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-krawczyk-hkdf-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5869
RFC5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI) A. Mayrhofer C. Spanring June 2010 ASCII 45943 23 geography geo uri scheme

This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo\' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). [STANDARDS-TRACK]

draft-ietf-geopriv-geo-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5870
RFC5871 IANA Allocation Guidelines for the IPv6 Routing Header J. Arkko S. Bradner May 2010 ASCII 4000 3 routing type field

This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. [STANDARDS TRACK]

draft-ietf-6man-iana-routing-header-00 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5871
RFC5872 IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA) J. Arkko A. Yegin May 2010 ASCII 7999 5

This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA). [STANDARDS-TRACK]

draft-arkko-pana-iana-02 RFC5191 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5872
RFC5873 Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA) Y. Ohba A. Yegin May 2010 ASCII 17137 8

This document defines an extension to the Protocol for Carrying Authentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pana-preauth-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5873
RFC5874 An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources J. Rosenberg J. Urpalainen May 2010 ASCII 49509 24 SIP Instant Messaging

This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session Initiation Protocol (SIP) event package. [STANDARDS-TRACK]

draft-ietf-simple-xcap-diff-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5874
RFC5875 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package J. Urpalainen D. Willis Editor May 2010 ASCII 58307 27 xcap-diff xcap diff

This document describes an "xcap-diff" SIP (Session Initiation Protocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes to Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP Diff format. [STANDARDS TRACK]

draft-ietf-sip-xcapevent-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5875
RFC5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP) J. Elwell April 2010 ASCII 25860 11 SIP P-Asserted-Identity

The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of the P-Asserted-Identity and P-Preferred-Identity header fields. These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use of P-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extends RFC 3325 to cover these situations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-update-pai-09 RFC3325 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5876
RFC5877 The application/pkix-attr-cert Media Type for Attribute Certificates R. Housley May 2010 ASCII 6692 4

This document specifies a MIME media type used to carry a single attribute certificate as defined in RFC 5755. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-attr-cert-mime-type-03 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5877 10.17487/RFC5877
RFC5878 Transport Layer Security (TLS) Authorization Extensions M. Brown R. Housley May 2010 ASCII 44594 19 handshake protocol

This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message. This document defines an Experimental Protocol for the Internet community.

draft-housley-tls-authz-extns-09 RFC5246 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5878 10.17487/RFC5878
RFC5879 Heuristics for Detecting ESP-NULL Packets T. Kivinen D. McDonald May 2010 ASCII 72917 32 IPsec Wrapped ESP (WESP) deep-inspection packet inspection

This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected. Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipsecme-esp-null-heuristics-07 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC5879
RFC5880 Bidirectional Forwarding Detection (BFD) D. Katz D. Ward June 2010 ASCII 110279 49

This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]

draft-ietf-bfd-base-11 RFC7419 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5880 10.17487/RFC5880
RFC5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) D. Katz D. Ward June 2010 ASCII 14307 7

This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRACK]

draft-ietf-bfd-v4v6-1hop-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5881 10.17487/RFC5881
RFC5882 Generic Application of Bidirectional Forwarding Detection (BFD) D. Katz D. Ward June 2010 ASCII 40439 17

This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. [STANDARDS-TRACK]

draft-ietf-bfd-generic-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC5882
RFC5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths D. Katz D. Ward June 2010 ASCII 11765 6

This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]

draft-ietf-bfd-multihop-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC5883
RFC5884 Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) R. Aggarwal K. Kompella T. Nadeau G. Swallow June 2010 ASCII 27734 12 Multiprotocol Label Switching lsp ping

One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. [STANDARDS-TRACK]

draft-ietf-bfd-mpls-07 RFC1122 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC5884
RFC5885 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) T. Nadeau Editor C. Pignataro Editor June 2010 ASCII 30866 14 Pseudowire VCCV BFD VCCV-BFD PW OAM

This document describes Connectivity Verification (CV) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. [STANDARDS-TRACK]

draft-ietf-pwe3-vccv-bfd-07 RFC6478 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5885
RFC5886 A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture JP. Vasseur Editor JL. Le Roux Y. Ikejiri June 2010 ASCII 56554 26

A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".

In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. [STANDARDS-TRACK]

draft-ietf-pce-monitoring-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC5886
RFC5887 Renumbering Still Needs Work B. Carpenter R. Atkinson H. Flinck May 2010 ASCII 87131 35

This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally, there is a gap analysis identifying possible areas for future work. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-carpenter-renum-needs-work-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5887
RFC5888 The Session Description Protocol (SDP) Grouping Framework G. Camarillo H. Schulzrinne June 2010 ASCII 43924 21 SDP grouping SIP

In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. [STANDARDS-TRACK]

draft-ietf-mmusic-rfc3388bis-04 RFC3388 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5888 10.17487/RFC5888
RFC5889 IP Addressing Model in Ad Hoc Networks E. Baccelli Editor M. Townsley Editor September 2010 ASCII 14918 8 mobile network ad hoc network MANET network architecture addressing framework configuration routing IP networks

This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-autoconf-adhoc-addr-model-03 INFORMATIONAL INFORMATIONAL IETF int autoconf 10.17487/RFC5889
RFC5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework J. Klensin August 2010 ASCII 54245 23 IDNA2008 idn ascii characters

This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]

draft-ietf-idnabis-defs-13 RFC3490 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis 10.17487/RFC5890
RFC5891 Internationalized Domain Names in Applications (IDNA): Protocol J. Klensin August 2010 ASCII 38105 17 IDNA2008 idn ascii characters idna applications

This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]

draft-ietf-idnabis-protocol-18 RFC3490 RFC3491 RFC3492 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5891 10.17487/RFC5891
RFC5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) P. Faltstrom Editor August 2010 ASCII 187370 70 IDNA DNS IDN Unicode IDNA2008

This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).

It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]

draft-ietf-idnabis-tables-09 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5892 10.17487/RFC5892
RFC5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) H. Alvestrand Editor C. Karp August 2010 ASCII 38870 17 IDNA2008 idn ascii characters Bidi

The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]

draft-ietf-idnabis-bidi-07 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis 10.17487/RFC5893
RFC5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale J. Klensin August 2010 ASCII 115174 43 IDNA2008 idn ascii characters

Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-idnabis-rationale-17 INFORMATIONAL INFORMATIONAL IETF app idnabis 10.17487/RFC5894
RFC5895 Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 P. Resnick P. Hoffman September 2010 ASCII 16556 7 user input character mapping locale user interface Unicode

In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-resman-idna2008-mappings-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5895
RFC5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy L. Hornquist Astrand S. Hartman June 2010 ASCII 12846 6

Several Generic Security Service Application Program Interface (GSS-API) applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers, including CIFS (Common Internet File System) file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). [STANDARDS-TRACK]

draft-lha-gssapi-delegate-policy-05 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5896
RFC5897 Identification of Communications Services in the Session Initiation Protocol (SIP) J. Rosenberg June 2010 ASCII 60349 23 service identification

This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA). This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation. It then outlines a set of recommended practices for service identification. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-service-identification-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5897
RFC5898 Connectivity Preconditions for Session Description Protocol (SDP) Media Streams F. Andreasen G. Camarillo D. Oran D. Wing July 2010 ASCII 38969 17 SIP preconditions connection connectivity

This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. [STANDARDS-TRACK]

draft-ietf-mmusic-connectivity-precon-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5898
RFC5901 Extensions to the IODEF-Document Class for Reporting Phishing P. Cain D. Jevans July 2010 ASCII 97325 51 Incident Object Description Exchange Format

This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. [STANDARDS-TRACK]

draft-cain-post-inch-phishingextns-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5901
RFC5902 IAB Thoughts on IPv6 Network Address Translation D. Thaler L. Zhang G. Lebovitz July 2010 ASCII 37224 15 NAT IPv6 Transparency End-to-End Privacy Multihoming

There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-ipv6-nat-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5902
RFC5903 Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2 D. Fu J. Solinas June 2010 ASCII 29175 16 Elliptic Curve Cryptography ECC Internet Key Exchange elliptic curve Diffie-Hellman suite b nist curve

This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-solinas-rfc4753bis-01 RFC4753 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5903 10.17487/RFC5903
RFC5904 RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support G. Zorn June 2010 ASCII 26879 15 RADIUS AAA IEEE 802.16

This document defines a set of Remote Authentication Dial-In User Service (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zorn-radius-pkmv1-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5904
RFC5905 Network Time Protocol Version 4: Protocol and Algorithms Specification D. Mills J. Martin Editor J. Burbank W. Kasch June 2010 ASCII 241096 110 NTP SNTP Synchronization

The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]

draft-ietf-ntp-ntpv4-proto-13 RFC1305 RFC4330 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5905 10.17487/RFC5905
RFC5906 Network Time Protocol Version 4: Autokey Specification B. Haberman Editor D. Mills June 2010 ASCII 140145 58 ntp ntpv4 public key cryptography

This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.

This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ntp-autokey-08 INFORMATIONAL INFORMATIONAL IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5906 10.17487/RFC5906
RFC5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) H. Gerstung C. Elliott B. Haberman Editor June 2010 ASCII 46950 26

The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment. As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent. This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort. [STANDARDS-TRACK]

draft-ietf-ntp-ntpv4-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5907 10.17487/RFC5907
RFC5908 Network Time Protocol (NTP) Server Option for DHCPv6 R. Gayraud B. Lourdelet June 2010 ASCII 17452 9 Dynamic Host Configuration Protocol for IPv6

The NTP Server Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts. [STANDARDS-TRACK]

draft-ietf-ntp-dhcpv6-ntp-opt-06 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5908 10.17487/RFC5908
RFC5909 Securing Neighbor Discovery Proxy: Problem Statement J-M. Combes S. Krishnan G. Daley July 2010 ASCII 50433 22 send secure neighbor discovery

Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.

Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.

Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-csi-sndp-prob-04 INFORMATIONAL INFORMATIONAL IETF int csi 10.17487/RFC5909
RFC5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) J. Gould S. Hollenbeck May 2010 ASCII 72490 36 epp Extensible Provisioning Protocol xml dns security dnssec delegation signer ds

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310. [STANDARDS-TRACK]

draft-gould-rfc4310bis-07 RFC4310 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5910 10.17487/RFC5910
RFC5911 New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME P. Hoffman J. Schaad June 2010 ASCII 101576 59 S/MIME PKIX ASN.1 modules

The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-smime-new-asn1-07 RFC6268 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5911 10.17487/RFC5911
RFC5912 New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) P. Hoffman J. Schaad June 2010 ASCII 216154 117 S/MIME PKIX ASN.1 modules

The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-new-asn1-08 RFC6960 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5912 10.17487/RFC5912
RFC5913 Clearance Attribute and Authority Clearance Constraints Certificate Extension S. Turner S. Chokhani June 2010 ASCII 39650 19 x.509 certificate

This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject. [STANDARDS-TRACK]

draft-ietf-pkix-authorityclearanceconstraints-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5913
RFC5914 Trust Anchor Format R. Housley S. Ashmore C. Wallace June 2010 ASCII 28393 14 trust anchor management

This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements. [STANDARDS-TRACK]

draft-ietf-pkix-ta-format-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5914 10.17487/RFC5914
RFC5915 Elliptic Curve Private Key Structure S. Turner D. Brown June 2010 ASCII 13646 7 ec Standards for Efficient Cryptography Group SECG

This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-ecprivatekey-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5915 10.17487/RFC5915
RFC5916 Device Owner Attribute S. Turner June 2010 ASCII 8543 6

This document defines the Device Owner attribute. It indicates the entity (e.g., company, organization, department, agency) that owns the device. This attribute may be included in public key certificates and attribute certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-deviceowner-attribute-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5916
RFC5917 Clearance Sponsor Attribute S. Turner June 2010 ASCII 11618 7

This document defines the clearance sponsor attribute. It indicates the entity that sponsored (i.e., granted) the clearance. This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-clearancesponsor-attribute-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5917
RFC5918 Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) R. Asati I. Minei B. Thomas August 2010 ASCII 19414 10 Wildcard Typed Wildcard FEC Element Typed Wildcard FEC Capability

The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-typed-wildcard-07 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5918 10.17487/RFC5918
RFC5919 Signaling LDP Label Advertisement Completion R. Asati P. Mohapatra E. Chen B. Thomas August 2010 ASCII 19455 9 label distribution protocol End-of-LIB Unrecognized Notification

There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-end-of-lib-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5919 10.17487/RFC5919
RFC5920 Security Framework for MPLS and GMPLS Networks L. Fang Editor July 2010 ASCII 152830 66

This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-mpls-and-gmpls-security-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5920
RFC5921 A Framework for MPLS in Transport Networks M. Bocci Editor S. Bryant Editor D. Frost Editor L. Levrau L. Berger July 2010 ASCII 129318 56 multiprotocol label switching mpls-tp transport profile oam itu-t

This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP.

This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-framework-12 RFC6215 RFC7274 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5921
RFC5922 Domain Certificates in the Session Initiation Protocol (SIP) V. Gurbani S. Lawrence A. Jeffrey June 2010 ASCII 37667 17 PKIX Authentication Mutual Authentication X.509 TLS

This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates. [STANDARDS-TRACK]

draft-ietf-sip-domain-certs-07 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5922
RFC5923 Connection Reuse in the Session Initiation Protocol (SIP) V. Gurbani Editor R. Mahy B. Tate June 2010 ASCII 41905 19 TCP Connection SCTP Connection TLS Connection Transport Connection TLS Virtual Server Authentication

This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. [STANDARDS-TRACK]

draft-ietf-sip-connect-reuse-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5923 10.17487/RFC5923
RFC5924 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates S. Lawrence V. Gurbani June 2010 ASCII 16868 8 PKIX SIP Domain X.509 Certificate

This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. This document defines an Experimental Protocol for the Internet community.

draft-ietf-sip-eku-08 EXPERIMENTAL EXPERIMENTAL IETF rai sip 10.17487/RFC5924
RFC5925 The TCP Authentication Option J. Touch A. Mankin R. Bonica June 2010 ASCII 106174 48 transmission control protocol border gateway protocol transmission control message digest algorithm

This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]

draft-ietf-tcpm-tcp-auth-opt-11 RFC2385 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5925 10.17487/RFC5925
RFC5926 Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) G. Lebovitz E. Rescorla June 2010 ASCII 31010 15 transmission control protocol

The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]

draft-ietf-tcpm-tcp-ao-crypto-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5926
RFC5927 ICMP Attacks against TCP F. Gont July 2010 ASCII 87744 36 vulnerability blind attacks connection-reset attack performance-degrading attack throughput-reduction attack source quench PMTUD Path-MTU Discovery ICMP Destination Unreachable

This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tcpm-icmp-attacks-12 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC5927
RFC5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism M. Petit-Huguenin August 2010 ASCII 23993 11 NAT Traversal

This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. [STANDARDS-TRACK]

draft-ietf-behave-turn-uri-10 RFC7350 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC5928
RFC5929 Channel Bindings for TLS J. Altman N. Williams L. Zhu July 2010 ASCII 34061 15 TLS channel binding channel-binding tls-unique tls-server-end-point tls-unique-for-telnet

This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).

Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK]

draft-altman-tls-channel-bindings-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5929
RFC5930 Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol S. Shen Y. Mao NSS. Murthy July 2010 ASCII 12217 6 initialization vector IKE_SA_INIT

This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipsecme-aes-ctr-ikev2-07 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC5930
RFC5931 Extensible Authentication Protocol (EAP) Authentication Using Only a Password D. Harkins G. Zorn August 2010 ASCII 90275 40 Password Authenticated Key Exchange Dictionary Attack Authentication EAP

This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-harkins-emu-eap-pwd-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5931 10.17487/RFC5931
RFC5932 Camellia Cipher Suites for TLS A. Kato M. Kanda S. Kanno June 2010 ASCII 11949 6 block cipher security camellia tls cbc sha2 camellia encryption algorithm

This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family. This document obsoletes RFC 4132. [STANDARDS-TRACK]

draft-kato-tls-rfc4132bis-05 RFC4132 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5932
RFC5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC V. Dolmatov Editor A. Chuprina I. Ustinov July 2010 ASCII 17657 9 domain name system security extensions ECC

This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-gost-07 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5933
RFC5934 Trust Anchor Management Protocol (TAMP) R. Housley S. Ashmore C. Wallace August 2010 ASCII 196043 91 trust anchors TA

This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects. [STANDARDS-TRACK]

draft-ietf-pkix-tamp-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5934 10.17487/RFC5934
RFC5935 Expressing SNMP SMI Datatypes in XML Schema Definition Language M. Ellison B. Natale August 2010 ASCII 28164 14 structure of management information

This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in XML Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. [STANDARDS-TRACK]

draft-ietf-opsawg-smi-datatypes-in-xsd-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=5935 10.17487/RFC5935
RFC5936 DNS Zone Transfer Protocol (AXFR) E. Lewis A. Hoenes Editor June 2010 ASCII 66337 29 authoritative transfer AXFR mechanism

The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.

The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK]

draft-ietf-dnsext-axfr-clarify-14 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5936
RFC5937 Using Trust Anchor Constraints during Certification Path Processing S. Ashmore C. Wallace August 2010 ASCII 16900 8 TA

This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-wallace-using-ta-constraints-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5937
RFC5938 Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) A. Morton M. Chiba August 2010 ASCII 37539 17

The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. [STANDARDS-TRACK]

draft-ietf-ippm-twamp-session-cntrl-07 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5938 10.17487/RFC5938
RFC5939 Session Description Protocol (SDP) Capability Negotiation F. Andreasen September 2010 ASCII 188116 77 multimedia session session announcement session invitation

The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.

The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.

The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-capability-negotiation-13 RFC6871 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5939 10.17487/RFC5939
RFC5940 Additional Cryptographic Message Syntax (CMS) Revocation Information Choices S. Turner R. Housley August 2010 ASCII 15127 9 online certificate status protocol ocsp server-based certificate validation protocol scvp

The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses. [STANDARDS-TRACK]

draft-turner-additional-cms-ri-choices-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5940 10.17487/RFC5940
RFC5941 Sharing Transaction Fraud Data D. M'Raihi S. Boeyen M. Grandcolas S. Bajaj August 2010 ASCII 49219 27 thraud incident object description exchange format iodef

This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mraihi-inch-thraud-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5941
RFC5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes H. Singh W. Beebee E. Nordmark July 2010 ASCII 27035 11

IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861. [STANDARDS-TRACK]

draft-ietf-6man-ipv6-subnet-model-12 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5942
RFC5943 A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing B. Haberman Editor August 2010 ASCII 9016 4

The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings). [STANDARDS-TRACK]

draft-haberman-rpsl-reachable-test-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5943
RFC5944 IP Mobility Support for IPv4, Revised C. Perkins Editor November 2010 ASCII 239935 100 MOBILEIPSUPIP Internet Protocol

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]

draft-ietf-mip4-rfc3344bis-10 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=5944 10.17487/RFC5944
RFC5945 Resource Reservation Protocol (RSVP) Proxy Approaches F. Le Faucheur J. Manner D. Wing A. Guillou October 2010 ASCII 118234 50

The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tsvwg-rsvp-proxy-approaches-09 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5945
RFC5946 Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy F. Le Faucheur J. Manner A. Narayanan A. Guillou H. Malik October 2010 ASCII 81414 35

Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-proxy-proto-11 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5946
RFC5947 Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP) J. Elwell H. Kaplan September 2010 ASCII 29849 13 Trunking pbx private branch exchange

This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-martini-reqs-09 INFORMATIONAL INFORMATIONAL IETF rai martini 10.17487/RFC5947
RFC5948 Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16 S. Madanapalli S. Park S. Chakrabarti G. Montenegro August 2010 ASCII 26553 13 packet cs

IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specific Convergence Sublayers for transmitting upper-layer protocols. The Packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 Media Access Control (MAC) layer.

This document specifies the frame format, the Maximum Transmission Unit (MTU), and the address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. [STANDARDS-TRACK]

draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng 10.17487/RFC5948
RFC5949 Fast Handovers for Proxy Mobile IPv6 H. Yokota K. Chowdhury R. Koodli B. Patil F. Xia September 2010 ASCII 72722 32 PFMIPv6 handoff PMIPv6 predictive reactive

Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.

When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. [STANDARDS-TRACK]

draft-ietf-mipshop-pfmipv6-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5949
RFC5950 Network Management Framework for MPLS-based Transport Networks S. Mansfield Editor E. Gray Editor K. Lam Editor September 2010 ASCII 39502 18 mpls-tp network management framework

This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP).

This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.

The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-nm-framework-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5950
RFC5951 Network Management Requirements for MPLS-based Transport Networks K. Lam S. Mansfield E. Gray September 2010 ASCII 49993 24 MPLS Transport Profile mpls-tp

This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. [STANDARDS-TRACK]

draft-ietf-mpls-tp-nm-req-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5951 10.17487/RFC5951
RFC5952 A Recommendation for IPv6 Address Text Representation S. Kawamura M. Kawashima August 2010 ASCII 26570 14 IPv6 text representation canonical

As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK]

draft-ietf-6man-text-addr-representation-07 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5952 10.17487/RFC5952
RFC5953 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) W. Hardaker August 2010 ASCII 147393 65 dtls datagram transport layer security tls transport model tlstm SNMP-TLS-TM-MIB

This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-dtls-tm-14 RFC6353 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms http://www.rfc-editor.org/errata_search.php?rfc=5953 10.17487/RFC5953
RFC5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261 V. Gurbani Editor B. Carpenter Editor B. Tate Editor August 2010 ASCII 13764 7 SIP session initiation protocol Augmented Backus-Naur Form Uniform Resource Identifier IPv6reference IPv6address

This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. [STANDARDS-TRACK]

draft-ietf-sip-ipv6-abnf-fix-05 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5954 10.17487/RFC5954
RFC5955 The application/timestamped-data Media Type A. Santoni August 2010 ASCII 4527 3 TimeStampedData envelopes

This document defines a new media type for TimeStampedData envelopes as described in RFC 5544. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-santoni-media-type-tsd-00 RFC5544 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5955
RFC5956 Forward Error Correction Grouping Semantics in the Session Description Protocol A. Begen September 2010 ASCII 29530 14 FEC loss repair grouping sdp media lines

This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888). These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. [STANDARDS-TRACK]

draft-ietf-mmusic-rfc4756bis-10 RFC4756 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5956
RFC5957 Display-Based Address Sorting for the IMAP4 SORT Extension D. Karp July 2010 ASCII 8709 5 Internet Message Access Protocol

This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields. [STANDARDS-TRACK]

draft-ietf-morg-sortdisplay-03 RFC5256 PROPOSED STANDARD PROPOSED STANDARD IETF app morg 10.17487/RFC5957
RFC5958 Asymmetric Key Packages S. Turner August 2010 ASCII 26671 14 private key private-key information rsa laboratories private-key syntax change control

This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK]

draft-turner-asymmetrickeyformat-05 RFC5208 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5958 10.17487/RFC5958
RFC5959 Algorithms for Asymmetric Key Package Content Type S. Turner August 2010 ASCII 13983 7 EncryptedPrivateKeyInfo AsymmetricKeyPackage

This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData, EnvelopedData, EncryptedData, AuthenticatedData, and AuthEnvelopedData. [STANDARDS-TRACK]

draft-turner-asymmetrickeyformat-algs-01 RFC6162 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5959
RFC5960 MPLS Transport Profile Data Plane Architecture D. Frost Editor S. Bryant Editor M. Bocci Editor August 2010 ASCII 31764 15 mpls-tp transport profile itu-t dataplane gal gach

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network. [STANDARDS-TRACK]

draft-ietf-mpls-tp-data-plane-04 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5960 10.17487/RFC5960
RFC5961 Improving TCP's Robustness to Blind In-Window Attacks A. Ramaiah R. Stewart M. Dalal August 2010 ASCII 44717 19 RST SYN FIN attack Data Injection vulnerability blind attacks BGP spoof mitigation

TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [STANDARDS-TRACK]

draft-ietf-tcpm-tcpsecure-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5961
RFC5962 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) H. Schulzrinne V. Singh H. Tschofenig M. Thomson September 2010 ASCII 20109 11 PIDF-LO,location,dynamic,speed,velocity,orientation

The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document defines PIDF-LO extensions to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity. [STANDARDS TRACK]

draft-singh-geopriv-pidf-lo-dynamic-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5962
RFC5963 IPv6 Deployment in Internet Exchange Points (IXPs) R. Gagliano August 2010 ASCII 22786 10 IPv6 IXP deployment exchange

This document provides guidance on IPv6 deployment in Internet Exchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-v6inixp-09 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5963
RFC5964 Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries J. Winterbottom M. Thomson August 2010 ASCII 21269 11 hole polygon pidf-lo service boundary location LoST

This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to- Service Translation (LoST) server, is described. [STANDARDS-TRACK]

draft-ietf-ecrit-specifying-holes-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC5964
RFC5965 An Extensible Format for Email Feedback Reports Y. Shafranovich J. Levine M. Kucherawy August 2010 ASCII 47452 25 feedback-report

This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK]

draft-ietf-marf-base-06 RFC6650 PROPOSED STANDARD PROPOSED STANDARD IETF app marf http://www.rfc-editor.org/errata_search.php?rfc=5965 10.17487/RFC5965
RFC5966 DNS Transport over TCP - Implementation Requirements R. Bellis August 2010 ASCII 14970 7 DNS TCP/IP

This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. [STANDARDS-TRACK]

draft-ietf-dnsext-dns-tcp-requirements-03 RFC1035 RFC1123 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5966
RFC5967 The application/pkcs10 Media Type S. Turner August 2010 ASCII 10928 6

This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-application-pkcs10-media-type-05 RFC2986 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5967
RFC5968 Guidelines for Extending the RTP Control Protocol (RTCP) J. Ott C. Perkins September 2010 ASCII 42541 17 real-time transport protocol

The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-avt-rtcp-guidelines-04 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC5968
RFC5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification W. Townsley O. Troan August 2010 ASCII 45278 18 6rd Provider 6to4 IPv6 softwire IPv6 Transition 6to4

This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. [STANDARDS-TRACK]

draft-ietf-softwire-ipv6-6rd-10 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=5969 10.17487/RFC5969
RFC5970 DHCPv6 Options for Network Boot T. Huth J. Freimann V. Zimmer D. Thaler September 2010 ASCII 22660 11 boot IPv6 DHCPv6

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-opt-netboot-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5970
RFC5971 GIST: General Internet Signalling Transport H. Schulzrinne R. Hancock October 2010 ASCII 381127 154 nsis next steps in signaling

This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-ntlp-20 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5971
RFC5972 General Internet Signaling Transport (GIST) State Machine T. Tsenov H. Tschofenig X. Fu Editor C. Aoun E. Davies October 2010 ASCII 53461 27 draft-ietf-nsis-ntlp-statemachine-10 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5972 RFC5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) M. Stiemerling H. Tschofenig C. Aoun E. Davies October 2010 ASCII 219962 90 Next Steps in Signaling NSIS Path-coupled signaling Middlebox

This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-nslp-natfw-25 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5973
RFC5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling J. Manner G. Karagiannis A. McDonald October 2010 ASCII 233309 102 QoS

This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-qos-nslp-18 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5974
RFC5975 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP) G. Ash Editor A. Bader Editor C. Kappler Editor D. Oran Editor October 2010 ASCII 153418 64

The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-qspec-24 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5975
RFC5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes G. Ash A. Morton M. Dolly P. Tarapore C. Dvorak Y. El Mghazli October 2010 ASCII 42215 19 qos-nslp qos-nslp quality-of-service model qspec

This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-y1541-qosm-10 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5976
RFC5977 RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv A. Bader L. Westberg G. Karagiannis C. Kappler T. Phelan October 2010 ASCII 324264 128 next steps in signaling resource managment in diffserv

This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-rmd-20 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5977
RFC5978 Using and Extending the NSIS Protocol Family J. Manner R. Bless J. Loughney E. Davies Editor October 2010 ASCII 75732 30 Signaling NTLP NSLP GIST QoS NSLP NAT/Firewall NSLP IP resources Extensibility

This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-nsis-ext-07 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5978
RFC5979 NSIS Operation over IP Tunnels C. Shen H. Schulzrinne S. Lee J. Bang March 2011 ASCII 69850 27 nsis qos next steps in signaling

NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-tunnel-13 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5979
RFC5980 NSIS Protocol Operation in Mobile Environments T. Sanda Editor X. Fu S. Jeong J. Manner H. Tschofenig March 2011 ASCII 77323 32

Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-nsis-applicability-mobility-signaling-20 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5980
RFC5981 Authorization for NSIS Signaling Layer Protocols J. Manner M. Stiemerling H. Tschofenig R. Bless Editor February 2011 ASCII 82427 37 Next Steps in Signaling gist General Internet Signaling Transport

Signaling layer protocols specified within the Next Steps in Signaling (NSIS) framework may rely on the General Internet Signaling Transport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within the NSIS signaling layer protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-nslp-auth-07 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis http://www.rfc-editor.org/errata_search.php?rfc=5981 10.17487/RFC5981
RFC5982 IP Flow Information Export (IPFIX) Mediation: Problem Statement A. Kobayashi Editor B. Claise Editor August 2010 ASCII 56005 25 flow-based measurement

Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipfix-mediators-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5982
RFC5983 Mailing Lists and Internationalized Email Addresses R. Gellens October 2010 ASCII 24462 10

This document describes considerations for mailing lists with the introduction of internationalized email addresses.

This document makes some specific recommendations on how mailing lists should act in various situations. This document defines an Experimental Protocol for the Internet community.

draft-ietf-eai-mailinglist-07 RFC6783 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5983
RFC5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding K-M. Moller April 1 2011 ASCII 18055 9 extra sensory perception

This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. This document defines an Experimental Protocol for the Internet community.

draft-moller-esp-based-forwarding-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC5984
RFC5985 HTTP-Enabled Location Delivery (HELD) M. Barnes Editor September 2010 ASCII 86914 39 layer 7 location configuration protocol l7 lcp

This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer. [STANDARDS-TRACK]

draft-ietf-geopriv-http-location-delivery-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5985
RFC5986 Discovering the Local Location Information Server (LIS) M. Thomson J. Winterbottom September 2010 ASCII 34450 16 u-naptr uri-enabled naptr

Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. [STANDARDS-TRACK]

draft-ietf-geopriv-lis-discovery-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5986 10.17487/RFC5986
RFC5987 Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters J. Reschke August 2010 ASCII 20108 10 HTTP header field parameter internationalization

By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231. [STANDARDS-TRACK]

draft-reschke-rfc2231-in-http-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5987
RFC5988 Web Linking M. Nottingham October 2010 ASCII 46834 23 Link linking http header link relation web

This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]

draft-nottingham-http-link-header-10 RFC4287 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5988 10.17487/RFC5988
RFC5989 A SIP Event Package for Subscribing to Changes to an HTTP Resource A.B. Roach October 2010 ASCII 40571 19 Link Relations Syndication Atom

The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP Event Framework, for doing so. [STANDARDS-TRACK]

draft-roach-sip-http-subscribe-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5989
RFC5990 Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS) J. Randall B. Kaliski J. Brainard S. Turner September 2010 ASCII 52579 27 key encapsulation mechanism generic hybrid cipher

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.

draft-ietf-smime-cms-rsa-kem-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5990 10.17487/RFC5990
RFC5991 Teredo Security Updates D. Thaler S. Krishnan J. Hoagland September 2010 ASCII 20847 10 teredo ipv6 address

The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible. [STANDARDS-TRACK]

draft-krishnan-v6ops-teredo-update-10 RFC4380 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5991
RFC5992 Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic S. Sharikov D. Miloshevic J. Klensin October 2010 ASCII 54378 21 Bosnian and Serbian Bulgarian Byelorussian Belarusian Belarusan Kildin Sami Macedonian Montenegrin Russian Ukrainian

This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami, Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone. It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sharikov-idn-reg-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5992
RFC5993 RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR) X. Duan S. Wang M. Westerlund K. Hellwig I. Johansson October 2010 ASCII 37824 18 speech codec real-time transport protocol

This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. [STANDARDS-TRACK]

draft-ietf-avt-rtp-gsm-hr-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5993
RFC5994 Application of Ethernet Pseudowires to MPLS Transport Networks S. Bryant Editor M. Morrow G. Swallow R. Cherukuri T. Nadeau N. Harrison B. Niven-Jenkins October 2010 ASCII 24394 11 mpls-tp

Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.

Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T. The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.

This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pwe3-mpls-transport-04 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5994 10.17487/RFC5994
RFC5995 Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections J. Reschke September 2010 ASCII 21591 12 HTTP POST WebDAV Collections Collection Members

The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".

This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as the Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.

This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. [STANDARDS-TRACK]

draft-reschke-webdav-post-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5995
RFC5996 Internet Key Exchange Protocol Version 2 (IKEv2) C. Kaufman P. Hoffman Y. Nir P. Eronen September 2010 ASCII 346466 138 IKE IPsec

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. [STANDARDS-TRACK]

draft-ietf-ipsecme-ikev2bis-11 RFC4306 RFC4718 RFC7296 RFC5998 RFC6989 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=5996 10.17487/RFC5996
RFC5997 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol A. DeKok August 2010 ASCII 55464 24 status-server

This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-radext-status-server-09 RFC2866 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5997 10.17487/RFC5997
RFC5998 An Extension for EAP-Only Authentication in IKEv2 P. Eronen H. Tschofenig Y. Sheffer September 2010 ASCII 33477 16 mutual authentication password credentials AAA key agreement channel binding

IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.

This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. [STANDARDS-TRACK]

draft-ietf-ipsecme-eap-mutual-05 RFC5996 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5998
RFC6001 Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) D. Papadimitriou M. Vigoureux K. Shiomoto D. Brungard JL. Le Roux October 2010 ASCII 52501 24

There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).

This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-mln-extensions-12 RFC4202 RFC4203 RFC4206 RFC4874 RFC4974 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6001
RFC6002 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions L. Berger D. Fedyk October 2010 ASCII 23090 10 Generalized Multi-Protocol Label Switching

This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-dcsc-channel-ext-04 RFC3471 RFC3473 RFC3945 RFC4202 RFC4203 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6002
RFC6003 Ethernet Traffic Parameters D. Papadimitriou October 2010 ASCII 28232 14 mef Metro Ethernet Forum MEF10.1

This document describes the support of Metro Ethernet Forum (MEF) Ethernet traffic parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. [STANDARDS-TRACK]

draft-ietf-ccamp-ethernet-traffic-parameters-10 RFC3471 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=6003 10.17487/RFC6003
RFC6004 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching L. Berger D. Fedyk October 2010 ASCII 32319 15 Generalized Multi-Protocol Label Switching Metro Ethernet Forum MEF draft-ietf-ccamp-gmpls-ether-svcs-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6004 RFC6005 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) L. Berger D. Fedyk October 2010 ASCII 20301 10 mef itu International Telecommunication Union i-nni internal nni

This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. [STANDARDS- TRACK]

draft-ietf-ccamp-gmpls-mef-uni-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6005
RFC6006 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Q. Zhao Editor D. King Editor F. Verhaeghe T. Takeda Z. Ali J. Meuric September 2010 ASCII 68107 33 END-POINTS fragmentation

Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.

This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. [STANDARDS-TRACK]

draft-ietf-pce-pcep-p2mp-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=6006 10.17487/RFC6006
RFC6007 Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations I. Nishioka D. King September 2010 ASCII 39156 18

A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message.

This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pce-pcep-svec-list-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6007
RFC6008 Authentication-Results Registration for Differentiating among Cryptographic Results M. Kucherawy September 2010 ASCII 14328 7 DKIM DomainKeys SenderID SPF Authentication Reputation

This memo updates the registry of properties in Authentication- Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. [STANDARDS-TRACK]

draft-kucherawy-authres-header-b-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6008
RFC6009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions N. Freed October 2010 ASCII 28979 15 SMTP ESMTP Sieve

This document describes the "envelope-dsn", "redirect-dsn", "envelope-deliverby", and "redirect-deliverby" extensions to the Sieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) and Deliver-By SMTP extensions, respectively. The "redirect-dsn" and "redirect-deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively. [STANDARDS-TRACK]

draft-freed-sieve-notary-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=6009 10.17487/RFC6009
RFC6010 Cryptographic Message Syntax (CMS) Content Constraints Extension R. Housley S. Ashmore C. Wallace September 2010 ASCII 87495 38 authorization PKI certificate trust anchor TAMP,

This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension. This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. [STANDARDS-TRACK]

draft-housley-cms-content-constraints-extn-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6010 10.17487/RFC6010
RFC6011 Session Initiation Protocol (SIP) User Agent Configuration S. Lawrence Editor J. Elwell October 2010 ASCII 66205 29 HTTP DHCP DHCPv6

This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-lawrence-sipforum-user-agent-config-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6011 10.17487/RFC6011
RFC6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog J. Salowey T. Petch R. Gerhards H. Feng October 2010 ASCII 24475 12 TLS

This document describes the transport of syslog messages over the Datagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired. [STANDARDS-TRACK]

draft-ietf-syslog-dtls-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC6012
RFC6013 TCP Cookie Transactions (TCPCT) W. Simpson January 2011 ASCII 76505 37

TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks. This document defines an Experimental Protocol for the Internet community.

draft-simpson-tcpct-03 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6013
RFC6014 Cryptographic Algorithm Identifier Allocation for DNSSEC P. Hoffman November 2010 ASCII 11182 6 DNSSEC digital signatures algorithms

This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-alg-allocation-03 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6014
RFC6015 RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) A. Begen October 2010 ASCII 65399 31 FEC interleaving loss repair loss protection DVB AL-FEC

This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity. The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB- IPTV) Application-layer FEC specification. [STANDARDS-TRACK]

draft-ietf-fecframe-interleaved-fec-scheme-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6015
RFC6016 Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs B. Davie F. Le Faucheur A. Narayanan October 2010 ASCII 95185 38 l3vpn

RFC 4364 and RFC 4659 define an approach to building provider-provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers. This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-l3vpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6016 10.17487/RFC6016
RFC6017 Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field K. Meadors Editor September 2010 ASCII 8683 5 EDIINT-Features

With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-meadors-ediint-features-header-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6017
RFC6018 IPv4 and IPv6 Greynets F. Baker W. Harrop G. Armitage September 2010 ASCII 21541 9 darknets

This note discusses a feature to support building Greynets for IPv4 and IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-baker-v6ops-greynet-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6018
RFC6019 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 R. Housley September 2010 ASCII 11394 6 signing-time attribute cryptographic message syntax cms SignedData AuthenticatedData

This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. [STANDARDS-TRACK]

rfc4049bis RFC4049 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6019
RFC6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) M. Bjorklund Editor October 2010 ASCII 324178 173 NETCONF XML data modelling

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]

draft-ietf-netmod-yang-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6020 10.17487/RFC6020
RFC6021 Common YANG Data Types J. Schoenwaelder Editor October 2010 ASCII 52826 26 YANG NETCONF

This document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK]

draft-ietf-netmod-yang-types-09 RFC6991 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC6021
RFC6022 YANG Module for NETCONF Monitoring M. Scott M. Bjorklund October 2010 ASCII 46988 28 XML NETCONF YANG monitoring

This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF <get-schema> operation to retrieve them. [STANDARDS-TRACK]

draft-ietf-netconf-monitoring-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC6022
RFC6023 A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) Y. Nir H. Tschofenig H. Deng R. Singh October 2010 ASCII 12560 7

This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be created and authenticated without generating a Child SA. This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

draft-nir-ipsecme-childless-06 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6023
RFC6024 Trust Anchor Management Requirements R. Reddy C. Wallace October 2010 ASCII 33415 14 PKI certificates digital signatures

A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-ta-mgmt-reqs-06 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6024
RFC6025 ASN.1 Translation C. Wallace C. Gardiner October 2010 ASCII 39221 19 Basic Encoding Rules Distinguished Encoding Rules PKIX S/MIME

Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1. Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-asn1-translation-03 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6025
RFC6026 Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests R. Sparks T. Zourzouvillys September 2010 ASCII 44035 20 state machine retransmission

This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. [STANDARDS-TRACK]

draft-ietf-sipcore-invfix-01 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6026 10.17487/RFC6026
RFC6027 IPsec Cluster Problem Statement Y. Nir October 2010 ASCII 27497 12 IKE IKEv2 high-availability load-sharing failover hot-standby

This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipsecme-ipsec-ha-09 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC6027
RFC6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension G. Camarillo A. Keranen October 2010 ASCII 21571 10 source routing route recording overlay network

This document specifies two extensions to the Host Identity Protocol (HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-via-03 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6028
RFC6029 A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem I. Rimac V. Hilt M. Tomsu V. Gurbani E. Marocco October 2010 ASCII 48615 19 Peer-to-Peer topology estimation Internet coordinate system

A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-p2prg-alto-survey-05 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6029 10.17487/RFC6029
RFC6030 Portable Symmetric Key Container (PSKC) P. Hoyer M. Pei S. Machani October 2010 ASCII 123974 58 Symmetric Key provisioning AES 3DES TDES OTP Key transport format key provisioning format symmetric key protection symmetric key transport PIN transport PIN provisioning PIN Policy key usage policy

This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. [STANDARDS-TRACK]

draft-ietf-keyprov-pskc-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6030 10.17487/RFC6030
RFC6031 Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type S. Turner R. Housley December 2010 ASCII 56129 29

This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-TRACK]

draft-ietf-keyprov-symmetrickeyformat-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6031 10.17487/RFC6031
RFC6032 Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner R. Housley December 2010 ASCII 22725 11 CCC CMS content constraints

This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. [STANDARDS-TRACK]

draft-turner-encryptedkeypackagecontenttype-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6032
RFC6033 Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner December 2010 ASCII 9818 5

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]

draft-turner-encryptedkeypackagecontenttype-algs-02 RFC6161 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6033
RFC6034 Unicast-Prefix-Based IPv4 Multicast Addresses D. Thaler October 2010 ASCII 11140 5 internet protocol

This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. [STANDARDS-TRACK]

draft-ietf-mboned-ipv4-uni-based-mcast-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC6034
RFC6035 Session Initiation Protocol Event Package for Voice Quality Reporting A. Pendleton A. Clark A. Johnston H. Sinnreich November 2010 ASCII 84930 41 sip Voice over Internet Protocol voip RTP Control Protocol Extended Reports RTCP-XR

This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. Voice call quality information derived from RTP Control Protocol Extended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector. A registration for the application/ vq-rtcpxr media type is also included. [STANDARDS-TRACK]

draft-ietf-sipping-rtcp-summary-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=6035 10.17487/RFC6035
RFC6036 Emerging Service Provider Scenarios for IPv6 Deployment B. Carpenter S. Jiang October 2010 ASCII 45113 23 isp

This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-isp-scenarios-00 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6036 10.17487/RFC6036
RFC6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs E. Rosen Editor Y. Cai Editor IJ. Wijnands October 2010 ASCII 57136 25 mvpn

This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document. This document defines a Historic Document for the Internet community.

draft-rosen-vpn-mcast-15 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6037
RFC6038 Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features A. Morton L. Ciavattone October 2010 ASCII 41273 18 Testing Performance Metric

This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]

draft-ietf-ippm-twamp-reflect-octets-09 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=6038 10.17487/RFC6038
RFC6039 Issues with Existing Cryptographic Protection Methods for Routing Protocols V. Manral M. Bhatia J. Jaeggli R. White October 2010 ASCII 50788 21

Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.

The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.

This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsec-routing-protocols-crypto-issues-07 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC6039
RFC6040 Tunnelling of Explicit Congestion Notification B. Briscoe November 2010 ASCII 89412 35 Congestion Control and Management Congestion Notification Information Security Tunnelling Encapsulation Decapsulation Protocol ECN IPsec

This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]

draft-ietf-tsvwg-ecn-tunnel-10 RFC3168 RFC4301 RFC4774 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6040
RFC6041 Forwarding and Control Element Separation (ForCES) Applicability Statement A. Crouch H. Khosravi A. Doria Editor X. Wang K. Ogawa October 2010 ASCII 28098 14 Routing Control Plane Management Protocol

The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-forces-applicability-09 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6041
RFC6042 Transport Layer Security (TLS) Authorization Using KeyNote A. Keromytis October 2010 ASCII 12097 7 trust management authorization access control certificates

This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-keromytis-tls-authz-keynote-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6042
RFC6043 MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY) J. Mattsson T. Tian March 2011 ASCII 139516 58 MIKEY MIKEY-TICKET KMS SRTP IMS key management ticket

The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mattsson-mikey-ticket-05 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6043
RFC6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) M. Mohali October 2010 ASCII 54486 24

Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.

This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.

Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mohali-diversion-history-info-07 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6044 10.17487/RFC6044
RFC6045 Real-time Inter-network Defense (RID) K. Moriarty November 2010 ASCII 172817 75 Coordinated Incident Response CSIRT CIRT IODEF Incident Object Exchange Description Format

Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.

RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-moriarty-post-inch-rid-12 RFC6545 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6045 10.17487/RFC6045
RFC6046 Transport of Real-time Inter-network Defense (RID) Messages K. Moriarty B. Trammell November 2010 ASCII 14760 7 Coordinate Incident Response CSIRT CIRT IODEF Incident Object Exchange Description Format

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-moriarty-post-inch-rid-transport-03 RFC6546 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6046
RFC6047 iCalendar Message-Based Interoperability Protocol (iMIP) A. Melnikov Editor December 2010 ASCII 40697 22 IMIP] electronic mail transport itip iCalendar Transport-independent Interoperability Protocol iCalendar Object Model

This document, "iCalendar Message-Based Interoperability Protocol (iMIP)", specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]

draft-ietf-calsify-rfc2447bis-11 RFC2447 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify 10.17487/RFC6047
RFC6048 Network News Transfer Protocol (NNTP) Additions to LIST Command J. Elie November 2010 ASCII 50873 25 Usenet NetNews capabilities

This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.

This memo updates and formalizes the LIST DISTRIBUTIONS and LIST SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST COUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. [STANDARDS-TRACK]

draft-elie-nntp-list-additions-05 RFC2980 RFC3977 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6048
RFC6049 Spatial Composition of Metrics A. Morton E. Stephan January 2011 ASCII 57486 29 Performance Measurement IPPM

This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. [STANDARDS-TRACK]

draft-ietf-ippm-spatial-composition-16 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6049
RFC6050 A Session Initiation Protocol (SIP) Extension for the Identification of Services K. Drage November 2010 ASCII 41021 19 SIP trust domain service identifier

This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.

The document also defines a URN to identify both services and User Agent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-drage-sipping-service-identification-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6050
RFC6051 Rapid Synchronisation of RTP Flows C. Perkins T. Schierl November 2010 ASCII 53503 22 rtcp rtp control protocol mcu multipoint conference units ssm source-specific multicast

This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.

This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. [STANDARDS-TRACK]

draft-ietf-avt-rapid-rtp-sync-12 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6051
RFC6052 IPv6 Addressing of IPv4/IPv6 Translators C. Bao C. Huitema M. Bagnulo M. Boucadair X. Li October 2010 ASCII 41849 18 address prefix transition translation NAT NAT64 BEHAVE stateless stateful

This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK]

draft-ietf-behave-address-format-10 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6052
RFC6053 Implementation Report for Forwarding and Control Element Separation (ForCES) E. Haleplidis K. Ogawa W. Wang J. Hadi Salim November 2010 ASCII 72337 34 Stream Control Transmission Protocol-based Transport Mapping Layer SCTP TML forces Model

Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.

This document is an implementation report for the ForCES Protocol, Model, and the Stream Control Transmission Protocol-based Transport Mapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-forces-implementation-report-02 RFC6984 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6053
RFC6054 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic D. McGrew B. Weis November 2010 ASCII 22672 10

Counter modes have been defined for block ciphers such as the Advanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. [STANDARDS-TRACK]

draft-ietf-msec-ipsec-group-counter-modes-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC6054
RFC6055 IAB Thoughts on Encodings for Internationalized Domain Names D. Thaler J. Klensin S. Cheshire February 2011 ASCII 58799 24 Unicode UTF-8,

This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.

draft-iab-idn-encoding-04 RFC2130 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=6055 10.17487/RFC6055
RFC6056 Recommendations for Transport-Protocol Port Randomization M. Larsen F. Gont January 2011 ASCII 63913 29 tcp transmission control protocl blind attacks

During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice.

draft-ietf-tsvwg-port-randomization-09 BCP0156 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6056 10.17487/RFC6056
RFC6057 Comcast's Protocol-Agnostic Congestion Management System C. Bastian T. Klieber J. Livingood J. Mills R. Woundy December 2010 ASCII 74685 29 ISP Internet Service Provider Network Management

This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S. Comcast completed deployment of this congestion management system on December 31, 2008. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-livingood-woundy-congestion-mgmt-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6057
RFC6058 Transient Binding for Proxy Mobile IPv6 M. Liebsch Editor A. Muhanna O. Blume March 2011 ASCII 90201 35 PMIP handover optimization handover delay tBCE late path switch forwarding make-before-break dual radio handover single radio handover transient binding cache entry

This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mipshop-transient-bce-pmipv6-07 EXPERIMENTAL EXPERIMENTAL IETF int mipshop 10.17487/RFC6058
RFC6059 Simple Procedures for Detecting Network Attachment in IPv6 S. Krishnan G. Daley November 2010 ASCII 40655 19 DNA DNAv6 ND IPv6 neighbor discovery neighbor discovery send secure neighbor discovery DHCPv6 stateless autoconfiguration change detection movement detection DNAv4 link detection mobility

Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services. [STANDARDS-TRACK]

draft-ietf-dna-simple-17 PROPOSED STANDARD PROPOSED STANDARD IETF int dna 10.17487/RFC6059
RFC6060 Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) D. Fedyk H. Shah N. Bitar A. Takacs March 2011 ASCII 45600 20 IEEE data plane

This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-ethernet-pbb-te-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6060
RFC6061 Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA) B. Rosen January 2011 ASCII 14145 7

This document describes the Namespace Identifier (NID) "nena" for Uniform Resource Name (URN) resources published by the National Emergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA Registry System (NRS). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-rosen-urn-nena-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6061
RFC6062 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations S. Perreault Editor J. Rosenberg November 2010 ASCII 28978 13 NAT TURN STUN

This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client\'s peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server. [STANDARDS-TRACK]

draft-ietf-behave-turn-tcp-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6062 10.17487/RFC6062
RFC6063 Dynamic Symmetric Key Provisioning Protocol (DSKPP) A. Doherty M. Pei S. Machani M. Nystrom December 2010 ASCII 233675 105 Cryptographic module Cryptographic Token key initialization credentials online provisioning

The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.

Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre-generated symmetric keys to a cryptographic module. [STANDARDS-TRACK]

draft-ietf-keyprov-dskpp-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6063 10.17487/RFC6063
RFC6064 SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service M. Westerlund P. Frojdh January 2011 ASCII 44810 22 3GPP PSS MBMS SDP RTSP IANA

The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use the Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-westerlund-mmusic-3gpp-sdp-rtsp-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6064
RFC6065 Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings K. Narayan D. Nelson R. Presuhn Editor December 2010 ASCII 39695 19 Network Management Security Management Information Base MIB SMIv2 RADIUS AAA VACM

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-based Access Control Model (VACM). [STANDARDS-TRACK]

draft-ietf-isms-radius-vacm-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC6065
RFC6066 Transport Layer Security (TLS) Extensions: Extension Definitions D. Eastlake 3rd January 2011 ASCII 55079 25 server_name max_fragment_length client_certificate_url trusted_ca_keys truncated_hmac status_request

This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]

draft-ietf-tls-rfc4366-bis-12 RFC4366 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6066 10.17487/RFC6066
RFC6067 BCP 47 Extension U M. Davis A. Phillips Y. Umaoka December 2010 ASCII 17012 8 locale bcp 47

This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-davis-u-langtag-ext-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6067 10.17487/RFC6067
RFC6068 The 'mailto' URI Scheme M. Duerst L. Masinter J. Zawinski October 2010 ASCII 36683 17 mailto email address URI scheme IRI

This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]

draft-duerst-mailto-bis-10 RFC2368 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6068 10.17487/RFC6068
RFC6069 Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) A. Zimmermann A. Hannemann December 2010 ASCII 59600 23 Internet Control Message Protocol (ICMP) Retranmission Timeout (RTO)

Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.

This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. This document defines an Experimental Protocol for the Internet community.

draft-ietf-tcpm-tcp-lcd-03 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6069
RFC6070 PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors S. Josefsson January 2011 ASCII 7334 5

This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-josefsson-pbkdf2-test-vectors-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6070
RFC6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap S. Frankel S. Krishnan February 2011 ASCII 148655 63 internet protocol privacy authentication

Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.

This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap."

The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipsecme-roadmap-10 RFC2411 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC6071
RFC6072 Certificate Management Service for the Session Initiation Protocol (SIP) C. Jennings J. Fischl Editor February 2011 ASCII 69071 30 credential service aor address of record

This document defines a credential service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys. [STANDARDS-TRACK]

draft-ietf-sip-certs-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=6072 10.17487/RFC6072
RFC6073 Segmented Pseudowire L. Martini C. Metz T. Nadeau M. Bocci M. Aissaoui January 2011 ASCII 102428 43 pws psn packet switched network pw control plane domain

This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. [STANDARDS-TRACK]

draft-ietf-pwe3-segmented-pw-18 RFC6723 RFC7267 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6073
RFC6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) E. Rosen B. Davie V. Radoaca W. Luo January 2011 ASCII 76543 32

Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). [STANDARDS- TRACK]

draft-ietf-l2vpn-signaling-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC6074
RFC6075 The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry D. Cridland December 2010 ASCII 13088 7 annotate metadata

The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols. This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity. [STANDARDS-TRACK]

draft-cridland-acap-vendor-registry-02 RFC2244 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6075
RFC6076 Basic Telephony SIP End-to-End Performance Metrics D. Malas A. Morton January 2011 ASCII 61559 27 Benchmarking Lab Test Time Measurement Service Session Protocol

This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. [STANDARDS-TRACK]

draft-ietf-pmol-sip-perf-metrics-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops pmol 10.17487/RFC6076
RFC6077 Open Research Issues in Internet Congestion Control D. Papadimitriou Editor M. Welzl M. Scharf B. Briscoe February 2011 ASCII 130169 51 Signalling Performance Robustness Fairness Stability Misbehaviour Architecture

This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-iccrg-welzl-congestion-control-open-research-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6077
RFC6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) G. Camarillo J. Melen January 2011 ASCII 41482 17 HIP DATA

This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-hiccups-05 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6078
RFC6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) G. Camarillo P. Nikander J. Hautakorpi A. Keranen A. Johnston January 2011 ASCII 51013 21

This document specifies a framework to build HIP-based (Host Identity Protocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols". This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-bone-07 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6079
RFC6080 A Framework for Session Initiation Protocol User Agent Profile Delivery D. Petrie S. Channabasappa Editor March 2011 ASCII 126917 54 SIP Configuration Framework User Agent profile

This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. [STANDARDS-TRACK]

draft-ietf-sipping-config-framework-18 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC6080
RFC6081 Teredo Extensions D. Thaler January 2011 ASCII 143419 59 IPv6 NAT traversal transition translation translator

This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication. [STANDARDS-TRACK]

draft-thaler-v6ops-teredo-extensions-08 RFC4380 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6081 10.17487/RFC6081
RFC6082 Deprecating Unicode Language Tag Characters: RFC 2482 is Historic K. Whistler G. Adams M. Duerst R. Presuhn Editor J. Klensin November 2010 ASCII 6633 4 characters strings ASCII

RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-presuhn-rfc2482-historic-02 RFC2482 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6082
RFC6083 Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) M. Tuexen R. Seggelmann E. Rescorla January 2011 ASCII 16674 9

This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).

DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.

Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]

draft-ietf-tsvwg-dtls-for-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6083
RFC6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS) X. Fu C. Dickmann J. Crowcroft January 2011 ASCII 27040 12 Multihoming Signaling Partial Reliability

The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-ntlp-sctp-15 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC6084
RFC6085 Address Mapping of IPv6 Multicast Packets on Ethernet S. Gundavelli M. Townsley O. Troan W. Dec January 2011 ASCII 4968 3

When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link-layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. [STANDARDS-TRACK]

draft-gundavelli-v6ops-l2-unicast-06 RFC2464 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6085
RFC6086 Session Initiation Protocol (SIP) INFO Method and Package Framework C. Holmberg E. Burger H. Kaplan January 2011 ASCII 75949 36 Info Package Info-Package Recv-Info

This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. [STANDARDS-TRACK]

draft-ietf-sipcore-info-events-10 RFC2976 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6086 10.17487/RFC6086
RFC6087 Guidelines for Authors and Reviewers of YANG Data Model Documents A. Bierman January 2011 ASCII 49969 26 NETMOD NETCONF XML YANG

This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netmod-yang-usage-11 INFORMATIONAL INFORMATIONAL IETF ops netmod 10.17487/RFC6087
RFC6088 Traffic Selectors for Flow Bindings G. Tsirtsis G. Giarreta H. Soliman N. Montavont January 2011 ASCII 28040 13 Mobile IPv6 Binary Traffic Selectors

This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. [STANDARDS-TRACK]

draft-ietf-mext-binary-ts-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC6088
RFC6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support G. Tsirtsis H. Soliman N. Montavont G. Giaretta K. Kuladinithi January 2011 ASCII 69353 31 Flow Identification Flow Summary Binding Reference Traffic Selector Flow Binding Entry

This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. [STANDARDS- TRACK]

draft-ietf-mext-flow-binding-11 RFC5648 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC6089
RFC6090 Fundamental Elliptic Curve Cryptography Algorithms D. McGrew K. Igoe M. Salter February 2011 ASCII 75993 34 ECC

This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mcgrew-fundamental-ecc-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6090 10.17487/RFC6090
RFC6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication N. Mavrogiannopoulos D. Gillmor February 2011 ASCII 18529 9 Certificate type negotiation tls handshake protocol handshake

This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mavrogiannopoulos-rfc5081bis-09 RFC5081 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6091
RFC6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service J. Woodyatt Editor January 2011 ASCII 91729 36 cpe firewall filter

This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-cpe-simple-security-16 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6092
RFC6093 On the Implementation of the TCP Urgent Mechanism F. Gont A. Yourtchenko January 2011 ASCII 25921 12 Transmission Control Protocol

This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do). [STANDARDS-TRACK]

draft-ietf-tcpm-urgent-data-07 RFC0793 RFC1011 RFC1122 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=6093 10.17487/RFC6093
RFC6094 Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols M. Bhatia V. Manral February 2011 ASCII 24583 11 IGP security

The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS), and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently, effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.

To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.

Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.

This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsec-igp-crypto-requirements-04 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC6094
RFC6095 Extending YANG with Language Abstractions B. Linowski M. Ersue S. Kuryla March 2011 ASCII 140259 75 YANG model complex-type Complex Types Typed Instance Resource Model Inheritance class

YANG -- the Network Configuration Protocol (NETCONF) Data Modeling Language -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancing YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. This document defines an Experimental Protocol for the Internet community.

draft-linowski-netmod-yang-abstract-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6095
RFC6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration M. Tuexen R. Stewart January 2011 ASCII 15368 8

This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream Control Transmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. [STANDARDS-TRACK]

draft-ietf-tsvwg-sctp-chunk-flags-02 RFC4960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6096
RFC6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6 J. Korhonen V. Devarapalli February 2011 ASCII 21682 10 PMIPv6 3GPP DNS AAA

Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netlmm-lma-discovery-08 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC6097
RFC6098 Generic Notification Message for Mobile IPv4 H. Deng H. Levkowetz V. Devarapalli S. Gundavelli B. Haley April 2012 ASCII 76848 33 mipv4

This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a Mobile IPv4 message type designed for this purpose. [STANDARDS-TRACK]

draft-ietf-mip4-generic-notification-message-16 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6098
RFC6101 The Secure Sockets Layer (SSL) Protocol Version 3.0 A. Freier P. Karlton P. Kocher August 2011 ASCII 142297 67 Transport layer security

This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.

This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. This document defines a Historic Document for the Internet community.

draft-mavrogiannopoulos-ssl-version3-06 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC6101
RFC6104 Rogue IPv6 Router Advertisement Problem Statement T. Chown S. Venaas February 2011 ASCII 36518 16 RA rogue ra

When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-rogue-ra-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6104
RFC6105 IPv6 Router Advertisement Guard E. Levy-Abegnoli G. Van de Velde C. Popoviciu J. Mohacsi February 2011 ASCII 20817 10 SEcure Neighbor Discovery Stateless Address Autoconfiguration

Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-ra-guard-08 RFC7113 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6105
RFC6106 IPv6 Router Advertisement Options for DNS Configuration J. Jeong S. Park L. Beloeil S. Madanapalli November 2010 ASCII 45181 19 DNS Service DNS Option Recursive DNS Server Address DNS Search List Stateless Autoconfiguration

This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. [STANDARDS-TRACK]

draft-ietf-6man-dns-options-bis-08 RFC5006 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6106
RFC6107 Procedures for Dynamically Signaled Hierarchical Label Switched Paths K. Shiomoto Editor A. Farrel Editor February 2011 ASCII 65363 30 TE links Bundled links GMPLS dynamically provisioned networks

Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.

Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK]

draft-ietf-ccamp-lsp-hierarchy-bis-08 RFC3477 RFC4206 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=6107 10.17487/RFC6107
RFC6108 Comcast's Web Notification System Design C. Chung A. Kasyanov J. Livingood N. Mody B. Van Lieu February 2011 ASCII 55329 24 ISP Internet Service Provider bot remediation bot notification

The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-livingood-web-notification-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6108
RFC6109 La Posta Elettronica Certificata - Italian Certified Electronic Mail C. Petrucci F. Gennai A. Shahin A. Vinciarelli April 2011 ASCII 135569 65 PEC Registered mail Return receipt Digitally signed email Digitally signed notification MIME SMIME

Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing.

The design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National Research Council (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-gennai-smime-cnipa-pec-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6109 10.17487/RFC6109
RFC6110 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content L. Lhotka Editor February 2011 ASCII 192547 100 DSDL validation RELAX NG Schematron DSRL

This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG), Schematron, and Schematron and Document Schema Renaming Language (DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc. Procedures for schema-based validation of such documents are also discussed. [STANDARDS-TRACK]

draft-ietf-netmod-dsdl-map-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6110 10.17487/RFC6110
RFC6111 Additional Kerberos Naming Constraints L. Zhu April 2011 ASCII 14113 6 principal names realm names

This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. [STANDARDS- TRACK]

draft-ietf-krb-wg-naming-07 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6111
RFC6112 Anonymity Support for Kerberos L. Zhu P. Leach S. Hartman April 2011 ASCII 37858 16 kerberos realm

This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. [STANDARDS-TRACK]

draft-ietf-krb-wg-anon-12 RFC4120 RFC4121 RFC4556 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=6112 10.17487/RFC6112
RFC6113 A Generalized Framework for Kerberos Pre-Authentication S. Hartman L. Zhu April 2011 ASCII 121122 48

Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a facility called pre-authentication. Pre-authentication mechanisms can use this facility to extend the Kerberos protocol and prove the identity of a principal.

This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.

This document also provides common tools needed by multiple pre-authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. [STANDARDS-TRACK]

draft-ietf-krb-wg-preauth-framework-17 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6113
RFC6114 The 128-Bit Blockcipher CLEFIA M. Katagi S. Moriai March 2011 ASCII 68618 33 security lightweight cryptography encryption algorithm

This document describes the specification of the blockcipher CLEFIA. CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and 256 bits, which is compatible with the interface of the Advanced Encryption Standard (AES). The algorithm of CLEFIA was published in 2007, and its security has been scrutinized in the public community. CLEFIA is one of the new-generation lightweight blockcipher algorithms designed after AES. Among them, CLEFIA offers high performance in software and hardware as well as lightweight implementation in hardware. CLEFIA will be of benefit to the Internet, which will be connected to more distributed and constrained devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-katagi-clefia-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6114
RFC6115 Recommendation for a Routing Architecture T. Li Editor February 2011 ASCII 178526 73

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-rrg-recommendation-16 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6115
RFC6116 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) S. Bradner L. Conroy K. Fujiwara March 2011 ASCII 52840 22 DNS E.164 NAPTR dynamic delegation discovery system e164.arpa

This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. [STANDARDS-TRACK]

draft-ietf-enum-3761bis-09 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6116
RFC6117 IANA Registration of Enumservices: Guide, Template, and IANA Considerations B. Hoeneisen A. Mayrhofer J. Livingood March 2011 ASCII 83838 40 domain name system

This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. [STANDARDS-TRACK]

draft-ietf-enum-enumservices-guide-22 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6117
RFC6118 Update of Legacy IANA Registrations of Enumservices B. Hoeneisen A. Mayrhofer March 2011 ASCII 115372 68 domain name system

This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. [STANDARDS-TRACK]

draft-ietf-enum-enumservices-transition-06 RFC3762 RFC3764 RFC3953 RFC4143 RFC4002 RFC4238 RFC4355 RFC4415 RFC4769 RFC4969 RFC4979 RFC5028 RFC5278 RFC5333 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6118
RFC6119 IPv6 Traffic Engineering in IS-IS J. Harrison J. Berger M. Bartlett February 2011 ASCII 21146 10

This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]

draft-ietf-isis-ipv6-te-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6119
RFC6120 Extensible Messaging and Presence Protocol (XMPP): Core P. Saint-Andre March 2011 ASCII 451942 211 XMPP Extensible Messaging and Presence Protocol Jabber Messaging Instant Messaging Presence Extensible Markup Language XML

The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]

draft-ietf-xmpp-3920bis-22 RFC3920 RFC7590 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6120 10.17487/RFC6120
RFC6121 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence P. Saint-Andre March 2011 ASCII 244800 114 XMPP Extensible Messaging and Presence Protocol Jabber IM Instant Messaging Presence XML Extensible Markup Language

This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]

draft-ietf-xmpp-3921bis-20 RFC3921 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6121 10.17487/RFC6121
RFC6122 Extensible Messaging and Presence Protocol (XMPP): Address Format P. Saint-Andre March 2011 ASCII 50646 23 XMPP Jabber Messaging Instant Messaging Presence Extensible Markup Language XML

This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920. [STANDARDS-TRACK]

draft-ietf-xmpp-address-09 RFC3920 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6122 10.17487/RFC6122
RFC6123 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts A. Farrel February 2011 ASCII 28277 13

It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.

The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group.

Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. This document defines a Historic Document for the Internet community.

draft-ietf-pce-manageability-requirements-11 HISTORIC HISTORIC IETF rtg pce 10.17487/RFC6123
RFC6124 An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol Y. Sheffer G. Zorn H. Tschofenig S. Fluhrer February 2011 ASCII 71706 33 password-based authentication mutual authentication password-based cryptography password authenticated key exchange weak password authentication

The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sheffer-emu-eap-eke-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6124
RFC6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) P. Saint-Andre J. Hodges March 2011 ASCII 136507 57

Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]

draft-saintandre-tls-server-id-check-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6125 10.17487/RFC6125
RFC6126 The Babel Routing Protocol J. Chroboczek April 2011 ASCII 99833 45

Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document defines an Experimental Protocol for the Internet community.

draft-chroboczek-babel-routing-protocol-05 RFC7298 RFC7557 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6126 10.17487/RFC6126
RFC6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios J. Arkko M. Townsley May 2011 ASCII 48227 20 address depletion translation NAT-PT dual-stack Softwire Behave NAT NAT444

When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.

This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-arkko-townsley-coexistence-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6127
RFC6128 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions A. Begen February 2011 ASCII 11544 6

The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute. [STANDARDS-TRACK]

draft-ietf-avt-rtcp-port-for-ssm-04 RFC5760 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6128
RFC6129 The 'application/tei+xml' Media Type L. Romary S. Lundberg February 2011 ASCII 14214 8 Text Encoding Initiative xml text encoding text representation MIME type

This document defines the 'application/tei+xml' media type for markup languages defined in accordance with the Text Encoding and Interchange guidelines. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-lundberg-app-tei-xml-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6129 10.17487/RFC6129
RFC6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) T. Clausen C. Dearlove J. Dean April 2011 ASCII 190678 88 MANET OLSRv2 packetbb Routing Protocol NHDP ad hoc network bi-directional 2-hop discovery Wireless SMF

This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). [STANDARDS-TRACK]

draft-ietf-manet-nhdp-15 RFC7183 RFC7188 RFC7466 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=6130 10.17487/RFC6130
RFC6131 Sieve Vacation Extension: "Seconds" Parameter R. George B. Leiba July 2011 ASCII 9407 5 email filters auto-replies

This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter. [STANDARDS-TRACK]

draft-ietf-sieve-vacation-seconds-03 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6131
RFC6132 Sieve Notification Using Presence Information R. George B. Leiba July 2011 ASCII 17677 8 email filters context status

This is a further extension to the Sieve mail filtering language Notification extension, defining presence information that may be checked through the notify_method_capability feature. [STANDARDS-TRACK]

draft-ietf-sieve-notify-presence-04 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6132
RFC6133 Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality R. George B. Leiba A. Melnikov July 2011 ASCII 17652 9

This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sieve-autoreply-04 INFORMATIONAL INFORMATIONAL IETF app sieve 10.17487/RFC6133
RFC6134 Sieve Extension: Externally Stored Lists A. Melnikov B. Leiba July 2011 ASCII 37379 18

The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server.

This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol (LDAP), the Application Configuration Access Protocol (ACAP), vCard Extensions to WebDAV (CardDAV), or relational databases. [STANDARDS-TRACK]

draft-ietf-sieve-external-lists-10 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6134
RFC6135 An Alternative Connection Model for the Message Session Relay Protocol (MSRP) C. Holmberg S. Blau February 2011 ASCII 17262 8 comedia comedia-tls relay SBC

This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. [STANDARDS-TRACK]

draft-ietf-simple-msrp-acm-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC6135
RFC6136 Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework A. Sajassi Editor D. Mohan Editor March 2011 ASCII 92170 42

This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements for L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS). Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-l2vpn-oam-req-frmk-11 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC6136
RFC6137 The Network Trouble Ticket Data Model (NTTDM) D. Zisiadis Editor S. Kopsidas Editor M. Tsavli Editor G. Cessieux Editor February 2011 ASCII 83462 46 Grid Management EGEE

Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent, and disseminate TT information in different formats.

As a result, management of the daily workload by a central Network Operation Centre (NOC) is a challenge on its own. Normalization of TTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE (Enabling Grids for E-sciencE) project. This document defines an Experimental Protocol for the Internet community.

draft-dzis-nwg-nttdm-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6137 10.17487/RFC6137
RFC6138 LDP IGP Synchronization for Broadcast Networks S. Kini Editor W. Lu Editor February 2011 ASCII 20161 9

RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior Gateway Protocol (IGP) is operational on a link but Label Distribution Protocol (LDP) is not. If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol message changes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-ldp-igp-sync-bcast-06 RFC5443 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6138
RFC6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios S. Russert Editor E. Fleischman Editor F. Templin Editor February 2011 ASCII 101101 39 Encapsulation Tunnel Architecture Scalability Mobility MANET Security IPv6 Aerospace IRON VET SEAL ISATAP

"Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-russert-rangers-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6139
RFC6140 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) A.B. Roach March 2011 ASCII 79372 35 Bulk Registration Implicit Registration GIN PBX SSP SIP-PBX

This document defines a mechanism by which a Session Initiation Protocol (SIP) server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique. This document therefore focuses on this use case. [STANDARDS-TRACK]

draft-ietf-martini-gin-13 RFC3680 PROPOSED STANDARD PROPOSED STANDARD IETF rai martini http://www.rfc-editor.org/errata_search.php?rfc=6140 10.17487/RFC6140
RFC6141 Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) G. Camarillo Editor C. Holmberg Y. Gao March 2011 ASCII 57517 26 re-INVITE offer/answer rollback

The procedures for handling SIP re-INVITEs are described in RFC 3261. Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests. [STANDARDS-TRACK]

draft-ietf-sipcore-reinvite-08 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6141
RFC6142 ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP A. Moise J. Brodkin March 2011 ASCII 58320 26 Advanced Metering Infrastructure ami application layer message

This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages on an IP network.

This document is not an official submission on behalf of the ANSI C12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-c1222-transport-over-ip-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6142
RFC6143 The Remote Framebuffer Protocol T. Richardson J. Levine March 2011 ASCII 91737 39 vnc rfb remote framebuffer remote GUI

RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer. Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-levine-rfb-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6143 10.17487/RFC6143
RFC6144 Framework for IPv4/IPv6 Translation F. Baker X. Li C. Bao K. Yin April 2011 ASCII 67181 31 stateless translation stateful translation

This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-behave-v6v4-framework-10 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC6144
RFC6145 IP/ICMP Translation Algorithm X. Li C. Bao F. Baker April 2011 ASCII 76484 33 SIIT] internet protocol control message IPv4 IPv6 Stateless IP/ICMP Translation Algorithm,

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 2765. [STANDARDS-TRACK]

draft-ietf-behave-v6v4-xlate-23 RFC2765 RFC6791 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6145 10.17487/RFC6145
RFC6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers M. Bagnulo P. Matthews I. van Beijnum April 2011 ASCII 107954 45 NAT64 IPv6 draft-ietf-behave-v6v4-xlate-stateful-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6146 RFC6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers M. Bagnulo A. Sullivan P. Matthews I. van Beijnum April 2011 ASCII 75103 32 AAAA

DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK]

draft-ietf-behave-dns64-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6147 10.17487/RFC6147
RFC6148 DHCPv4 Lease Query by Relay Agent Remote ID P. Kurapati R. Desetti B. Joshi February 2011 ASCII 26185 13 dynamic host configuration protocol

Some relay agents extract lease information from the DHCP messages exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server when this information is lost. The existing lease query mechanism is data-driven, which means that a relay agent can initiate the lease query only when it starts receiving data to and from the clients. In certain scenarios, this model is not scalable. This document first looks at issues in the existing mechanism and then proposes a new query type, query by Remote ID, to address these issues. [STANDARDS-TRACK]

draft-ietf-dhc-leasequery-by-remote-id-09 RFC4388 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6148
RFC6149 MD2 to Historic Status S. Turner L. Chen March 2011 ASCII 14158 7 security encryption signature

This document retires MD2 and discusses the reasons for doing so. This document moves RFC 1319 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-md2-to-historic-10 RFC1319 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6149 10.17487/RFC6149
RFC6150 MD4 to Historic Status S. Turner L. Chen March 2011 ASCII 19583 10 MD4 security encryption signature

This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so. This document moves RFC 1320 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-md4-to-historic-11 RFC1320 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6150 10.17487/RFC6150
RFC6151 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms S. Turner L. Chen March 2011 ASCII 14662 7 signature eneryption ipsec Message Digest encryption

This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-md5-seccon-update-08 RFC1321 RFC2104 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6151
RFC6152 SMTP Service Extension for 8-bit MIME Transport J. Klensin N. Freed M. Rose D. Crocker Editor March 2011 ASCII 13034 7 simple mail transfer

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]

draft-ietf-yam-rfc1652bis-03 RFC1652 STD0071 INTERNET STANDARD INTERNET STANDARD IETF app yam 10.17487/RFC6152
RFC6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery S. Das G. Bajko February 2011 ASCII 13420 7 Dynamic Host Configuration Protocol

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover Access Network Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in the Third Generation Partnership Project (3GPP) and provides inter-system mobility policies and access-network-specific information to the mobile nodes (MNs). [STANDARDS-TRACK]

draft-das-mipshop-andsf-dhcp-options-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6153
RFC6154 IMAP LIST Extension for Special-Use Mailboxes B. Leiba J. Nicolson March 2011 ASCII 25544 12 IMAP email

Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. [STANDARDS-TRACK]

draft-ietf-morg-list-specialuse-06 PROPOSED STANDARD PROPOSED STANDARD IETF app morg http://www.rfc-editor.org/errata_search.php?rfc=6154 10.17487/RFC6154
RFC6155 Use of Device Identity in HTTP-Enabled Location Delivery (HELD) J. Winterbottom M. Thomson H. Tschofenig R. Barnes March 2011 ASCII 58542 27

When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.

Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.

This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. [STANDARDS-TRACK]

draft-ietf-geopriv-held-identity-extensions-06 RFC6915 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6155
RFC6156 Traversal Using Relays around NAT (TURN) Extension for IPv6 G. Camarillo O. Novo S. Perreault Editor April 2011 ASCII 27758 14 STUN TURN IPv6

This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). [STANDARDS-TRACK]

draft-ietf-behave-turn-ipv6-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6156
RFC6157 IPv6 Transition in the Session Initiation Protocol (SIP) G. Camarillo K. El Malki V. Gurbani April 2011 ASCII 32492 15

This document describes how the IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., IPv4-only and IPv4/IPv6) user agents are considered. [STANDARDS-TRACK]

draft-ietf-sipping-v6-transition-07 RFC3264 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=6157 10.17487/RFC6157
RFC6158 RADIUS Design Guidelines A. DeKok Editor G. Weber March 2011 ASCII 89319 38

This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). This memo documents an Internet Best Current Practice.

draft-ietf-radext-design-19 RFC6929 BCP0158 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops radext 10.17487/RFC6158
RFC6159 Session-Specific Explicit Diameter Request Routing T. Tsou G. Zorn T. Taylor Editor April 2011 ASCII 45051 19 Diameter routing

This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-tsou-diameter-explicit-routing-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6159
RFC6160 Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types S. Turner April 2011 ASCII 10115 5

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]

draft-turner-cms-symmetrickeypackage-algs-00 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6160
RFC6161 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner April 2011 ASCII 5504 3 ecdsa ecdh EnvelopedData and Elliptic Curve Digital Signature Algorithm

This document describes the conventions for using several Elliptic Curve cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. This document extends RFC 6033. [STANDARDS-TRACK]

draft-turner-ekpct-algs-update-03 RFC6033 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6161
RFC6162 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type S. Turner April 2011 ASCII 6155 4 ecdsa ecdh EnvelopedData and Elliptic Curve Digital Signature Algorithm

This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. This document extends RFC 5959. [STANDARDS-TRACK]

draft-turner-akf-algs-update-03 RFC5959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6162
RFC6163 Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) Y. Lee Editor G. Bernstein Editor W. Imajuku April 2011 ASCII 115511 51 Generalized Multi-Protocol Label Switching Routing and Wavelength Assignment RWA

This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of Wavelength Switched Optical Networks (WSONs). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths.

This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-rwa-wson-framework-12 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6163
RFC6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links M. Kohno B. Nitzan R. Bush Y. Matsuzaki L. Colitti T. Narten April 2011 ASCII 16057 8 addressing prefix length security

On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. [STANDARDS-TRACK]

draft-ietf-6man-prefixlen-p2p-01 RFC6547 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6164 10.17487/RFC6164
RFC6165 Extensions to IS-IS for Layer-2 Systems A. Banerjee D. Ward April 2011 ASCII 12266 7 Intermediate System to Intermediate System

This document specifies the Intermediate System to Intermediate System (IS-IS) extensions necessary to support link state routing for any protocols running directly over Layer-2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. Furthermore, the Type, Length, Value pairs (TLVs) described in this document are generic Layer-2 additions, and specific ones as needed are defined in the IS-IS technology-specific extensions. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. [STANDARDS- TRACK]

draft-ietf-isis-layer2-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6165
RFC6166 A Registry for PIM Message Types S. Venaas April 2011 ASCII 7441 4 IANA Protocol Independent Multicast

This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types. It also specifies a procedure for registering new types.

In addition to this, one message type is reserved, and may be used for a future extension of the message type space. [STANDARDS-TRACK]

draft-ietf-pim-registry-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6166
RFC6167 URI Scheme for Java(tm) Message Service 1.0 M. Phillips P. Adams D. Rokicki E. Johnson April 2011 ASCII 44285 22 SOAP JMS JNDI IRI

This document defines the format of Uniform Resource Identifiers (URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS). It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination. The syntax of this JMS URI is not compatible with previously existing, but unregistered, "jms" URI schemes. However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-merrick-jms-uri-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6167 10.17487/RFC6167
RFC6168 Requirements for Management of Name Servers for the DNS W. Hardaker May 2011 ASCII 36679 17 DNS Domain Name System Management

Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.

This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dnsop-name-server-management-reqs-05 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6168
RFC6169 Security Concerns with IP Tunneling S. Krishnan D. Thaler J. Hoagland April 2011 ASCII 45018 20

A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]

draft-ietf-v6ops-tunnel-security-concerns-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6169
RFC6170 Internet X.509 Public Key Infrastructure -- Certificate Image S. Santesson R. Housley S. Bajaj L. Rosenthol May 2011 ASCII 25240 12 otherLogos

This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. [STANDARDS-TRACK]

draft-ietf-pkix-certimage-11 RFC3709 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6170
RFC6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control K. Zeilenga March 2011 ASCII 11124 6 x.511 dontusecopy

This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. [STANDARDS-TRACK]

draft-zeilenga-ldap-dontusecopy-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6171
RFC6172 Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode D. Black D. Peterson March 2011 ASCII 11625 6 FCIP

Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified.

iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document.

This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP). [STANDARDS-TRACK]

draft-ietf-storm-ifcp-ipn133-updates-03 RFC4172 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6172
RFC6173 Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP) P. Venkatesen Editor March 2011 ASCII 63695 31 Management Information Base mib IFCP-MGMT-MIB

This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.

This document obsoletes RFC 4369. [STANDARDS-TRACK]

draft-ietf-storm-ifcpmib-07 RFC4369 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6173
RFC6174 Definition of IETF Working Group Document States E. Juskevicius March 2011 ASCII 56883 25 WG I-D States I-D Availability States

The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.

This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and their Delegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-proto-wgdocument-states-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6174
RFC6175 Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors E. Juskevicius March 2011 ASCII 55481 23 WG Document States I-D States

This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for Working Group (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs. After these requirements are implemented, WG Chairs will be able to use the Datatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-juskevicius-datatracker-wgdocstate-reqts-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6175
RFC6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0 S. Turner T. Polk March 2011 ASCII 7642 4

This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]

draft-ietf-tls-ssl2-must-not-04 RFC2246 RFC4346 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC6176
RFC6177 IPv6 Address Assignment to End Sites T. Narten G. Huston L. Roberts March 2011 ASCII 21231 9 internet architecture board engineering steering group protocol

RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.

This document obsoletes RFC 3177. [STANDARDS-TRACK]

draft-ietf-v6ops-3177bis-end-sites-01 RFC3177 BCP0157 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC6177
RFC6178 Label Edge Router Forwarding of IPv4 Option Packets D. Smith J. Mullooly W. Jaeger T. Scholl March 2011 ASCII 21645 9 FEC MPLS LER Security DoS

This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK]

draft-ietf-mpls-ip-options-07 RFC3031 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6178
RFC6179 The Internet Routing Overlay Network (IRON) F. Templin Editor March 2011 ASCII 92638 37 Encapsulation Tunnel Architecture Scalability Mobility MANET Security Recursion Addressing Routing IPv6 Aerospace Aeronautics Space IRON RANGER VET SEAL ISATAP

Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-templin-iron-17 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6179
RFC6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment J. Arkko F. Baker May 2011 ASCII 49679 20

The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-arkko-ipv6-transition-guidelines-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6180
RFC6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses M. Bagnulo March 2011 ASCII 44251 17 Multipath TCP threats security MPTCP

Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mptcp-threat-08 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC6181
RFC6182 Architectural Guidelines for Multipath TCP Development A. Ford C. Raiciu M. Handley S. Barre J. Iyengar March 2011 ASCII 68772 28 multipath tcp architecture

Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.

This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mptcp-architecture-05 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC6182
RFC6183 IP Flow Information Export (IPFIX) Mediation: Framework A. Kobayashi B. Claise G. Muenz K. Ishibashi April 2011 ASCII 67997 29

This document describes a framework for IP Flow Information Export (IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipfix-mediators-framework-09 RFC5470 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6183 10.17487/RFC6183
RFC6184 RTP Payload Format for H.264 Video Y.-K. Wang R. Even T. Kristensen R. Jesup May 2011 ASCII 250627 101 AVC H.264/AVC Advanced Video Coding

This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.

This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDARDS-TRACK]

draft-ietf-avt-rtp-rfc3984bis-12 RFC3984 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=6184 10.17487/RFC6184
RFC6185 RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video T. Kristensen P. Luthi May 2011 ASCII 55562 22 H.264 H.241 ITU-T RTP Video SDP RCDO

This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RCDO RTP payload format is based on the H.264 RTP payload format. [STANDARDS-TRACK]

draft-ietf-avt-rtp-h264-rcdo-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6185
RFC6186 Use of SRV Records for Locating Email Submission/Access Services C. Daboo March 2011 ASCII 18895 9 imap pop3 smtp dns discovery

This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]

draft-daboo-srv-email-05 RFC1939 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6186
RFC6187 X.509v3 Certificates for Secure Shell Authentication K. Igoe D. Stebila March 2011 ASCII 35208 16

X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. [STANDARDS-TRACK]

draft-igoe-secsh-x509v3-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6187
RFC6188 The Use of AES-192 and AES-256 in Secure RTP D. McGrew March 2011 ASCII 35973 16 SRTP

This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. [STANDARDS-TRACK]

draft-ietf-avt-srtp-big-aes-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6188
RFC6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP P. Zimmermann A. Johnston Editor J. Callas April 2011 ASCII 293784 115

This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zimmermann-avt-zrtp-22 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6189
RFC6190 RTP Payload Format for Scalable Video Coding S. Wenger Y.-K. Wang T. Schierl A. Eleftheriadis May 2011 ASCII 250504 100 SVC AVC H.264/AVC Advanced Video Coding Scalable Video Coding

This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]

draft-ietf-avt-rtp-svc-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload http://www.rfc-editor.org/errata_search.php?rfc=6190 10.17487/RFC6190
RFC6191 Reducing the TIME-WAIT State Using TCP Timestamps F. Gont April 2011 ASCII 22953 10

This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. This memo documents an Internet Best Current Practice.

draft-ietf-tcpm-tcp-timestamps-04 BCP0159 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpm 10.17487/RFC6191
RFC6192 Protecting the Router Control Plane D. Dugal C. Pignataro R. Dunn March 2011 ASCII 49422 25 ACL Router Control Plane Protection Filter

This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.

Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsec-protect-control-plane-06 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=6192 10.17487/RFC6192
RFC6193 Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP) M. Saito D. Wing M. Toyama April 2011 ASCII 50201 22 SIP IPsec setup VPN

This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-saito-mmusic-sdp-ike-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6193
RFC6194 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms T. Polk L. Chen S. Turner P. Hoffman March 2011 ASCII 15172 7

This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-sha0-sha1-seccon-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6194 10.17487/RFC6194
RFC6195 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd March 2011 ASCII 33790 17 RRTYPE RCODE AFSDB

This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This memo documents an Internet Best Current Practice.

draft-ietf-dnsext-5395bis-03 RFC5395 RFC6895 RFC1183 RFC3597 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC6195
RFC6196 Moving mailserver: URI Scheme to Historic A. Melnikov March 2011 ASCII 5679 3 mailserver URI

This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK]

draft-melnikov-mailserver-uri-to-historic-00 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6196 10.17487/RFC6196
RFC6197 Location-to-Service Translation (LoST) Service List Boundary Extension K. Wolf April 2011 ASCII 27562 15 listservicesbylocation

Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ecrit-lost-servicelistboundary-05 EXPERIMENTAL EXPERIMENTAL IETF rai ecrit 10.17487/RFC6197
RFC6198 Requirements for the Graceful Shutdown of BGP Sessions B. Decraene P. Francois C. Pelsser Z. Ahmad A.J. Elizondo Armengol T. Takeda April 2011 ASCII 37906 20 routing BGP graceful shutdown connectivity loss maintenance network operation make-before-break planned

The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications (e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-grow-bgp-graceful-shutdown-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6198
RFC6201 Device Reset Characterization R. Asati C. Pignataro F. Calabria C. Olvera March 2011 ASCII 34695 17 operation redundancy failover

An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.

This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-reset-06 RFC1242 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6201
RFC6202 Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP S. Loreto P. Saint-Andre S. Salsano G. Wilkins April 2011 ASCII 44724 19 Hypertext Transfer Protocol bidirectional HTTP HTTP long polling HTTP streaming

On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-loreto-http-bidirectional-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6202
RFC6203 IMAP4 Extension for Fuzzy Search T. Sirainen March 2011 ASCII 13606 7 email

This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. [STANDARDS-TRACK]

draft-ietf-morg-fuzzy-search-03 PROPOSED STANDARD PROPOSED STANDARD IETF app morg 10.17487/RFC6203
RFC6204 Basic Requirements for IPv6 Customer Edge Routers H. Singh W. Beebee C. Donley B. Stark O. Troan Editor April 2011 ASCII 37026 17 IPv6 CE requirements

This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-ipv6-cpe-router-09 RFC7084 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6204 10.17487/RFC6204
RFC6205 Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers T. Otani Editor D. Li Editor March 2011 ASCII 27749 15 DWDM CWDM Wavelength Label LSC

Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.

Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors. Global wavelength semantics are not considered.

In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-g-694-lambda-labels-11 RFC3471 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6205
RFC6206 The Trickle Algorithm P. Levis T. Clausen J. Hui O. Gnawali J. Ko March 2011 ASCII 30283 13 Consistency Eventual consistency Low-power Low power

The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. [STANDARDS-TRACK]

draft-ietf-roll-trickle-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC6206
RFC6207 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml R. Denenberg Editor April 2011 ASCII 18090 11 mods Metadata Object Description Schema MADS Metadata Authority Description Schema METS Metadata Encoding and Transmission Standard MARCXML MARC21 XML Schema SRU Search/Retrieve via URL Response Format

This document specifies media types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema. These are all XML schemas providing representations of various forms of information including metadata and search results. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-denenberg-mods-etc-media-types-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6207
RFC6208 Cloud Data Management Interface (CDMI) Media Types K. Sankar Editor A. Jones April 2011 ASCII 23187 13 snia Storage Networking Industry Association

This document describes several Internet media types defined for the Cloud Data Management Interface (CDMI) by the Storage Networking Industry Association (SNIA). The media types are:

o application/cdmi-object

o application/cdmi-container

o application/cdmi-domain

o application/cdmi-capability

o application/cdmi-queue

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cdmi-mediatypes-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6208
RFC6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) W. Kim J. Lee J. Park D. Kwon April 2011 ASCII 19501 9 aria encryption

This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-nsri-tls-aria-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6209
RFC6210 Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME J. Schaad April 2011 ASCII 28339 14 example MD5-XOR Parameterized

New hash algorithms are being developed that may include parameters. Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be. This document defines an Experimental Protocol for the Internet community.

draft-schaad-smime-hash-experiment-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6210 10.17487/RFC6210
RFC6211 Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute J. Schaad April 2011 ASCII 22646 11 example s/mime SMIME

The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]

draft-schaad-smime-algorithm-attribute-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6211
RFC6212 Authentication-Results Registration for Vouch by Reference Results M. Kucherawy April 2011 ASCII 13199 7 VBR Reputation DKIM

This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. [STANDARDS-TRACK]

draft-kucherawy-authres-vbr-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6212
RFC6213 IS-IS BFD-Enabled TLV C. Hopps L. Ginsberg April 2011 ASCII 15527 7 type-length-value Bidirectional Forwarding Detection

This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK]

draft-ietf-isis-bfd-tlv-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6213
RFC6214 Adaptation of RFC 1149 for IPv6 B. Carpenter R. Hinden April 1 2011 ASCII 15073 7 avian carrier april fool

This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-carpenter-6man-adapt-rfc1149-00 RFC1149 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6214 10.17487/RFC6214
RFC6215 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces M. Bocci L. Levrau D. Frost April 2011 ASCII 13619 6

The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-uni-nni-03 RFC5921 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6215
RFC6216 Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms C. Jennings K. Ono R. Sparks B. Hibbard Editor April 2011 ASCII 143891 67

This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipcore-sec-flows-09 INFORMATIONAL INFORMATIONAL IETF rai sipcore 10.17487/RFC6216
RFC6217 Regional Broadcast Using an Atmospheric Link Layer T. Ritter April 1 2011 ASCII 19546 9

Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ritter-regional-bcast-atmospheric-linklayer-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6217
RFC6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material G. Zorn T. Zhang J. Walker J. Salowey April 2011 ASCII 34463 18 Security

This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zorn-radius-keywrap-18 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6218
RFC6219 The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition X. Li C. Bao M. Chen H. Zhang J. Wu May 2011 ASCII 44774 22 Stateless IPv4/IPv6 translation IPv4/IPv6 Header Translation IPv4-embedded IPv6 Address IPv4/IPv6 Multicast Translation stateless NAT64

This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.

The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-xli-behave-ivi-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6219
RFC6220 Defining the Role and Function of IETF Protocol Parameter Registry Operators D. McPherson Editor O. Kolkman Editor J. Klensin Editor G. Huston Editor Internet Architecture Board April 2011 ASCII 23733 11

Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-iana-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6220
RFC6221 Lightweight DHCPv6 Relay Agent D. Miles Editor S. Ooghe W. Dec S. Krishnan A. Kavanagh May 2011 ASCII 28471 17 ipv6 dsl

This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-ldra-03 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6221 10.17487/RFC6221
RFC6222 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) A. Begen C. Perkins D. Wing April 2011 ASCII 20393 9

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. [STANDARDS-TRACK]

draft-ietf-avt-rtp-cnames-05 RFC7022 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6222
RFC6223 Indication of Support for Keep-Alive C. Holmberg April 2011 ASCII 41439 18 SIP STUN outbound NAT traversal

This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. [STANDARDS-TRACK]

draft-ietf-sipcore-keep-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6223
RFC6224 Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains T. Schmidt M. Waehlisch S. Krishnan April 2011 ASCII 46105 19 MLD proxy multicast routing mobility management transparent handover

This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-multimob-pmipv6-base-solution-07 INFORMATIONAL INFORMATIONAL IETF int multimob 10.17487/RFC6224
RFC6225 Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information J. Polk M. Linsner M. Thomson B. Aboba Editor July 2011 ASCII 77001 36

This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825. [STANDARDS-TRACK]

draft-ietf-geopriv-rfc3825bis-17 RFC3825 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=6225 10.17487/RFC6225
RFC6226 PIM Group-to-Rendezvous-Point Mapping B. Joshi A. Kessler D. McWalter May 2011 ASCII 24092 11 auto-RP BSR hash algorithm

Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintains Group-to-RP mappings that are used to identify a Rendezvous Point (RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned.

This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. [STANDARDS-TRACK]

draft-ietf-pim-group-rp-mapping-10 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6226
RFC6227 Design Goals for Scalable Internet Routing T. Li Editor May 2011 ASCII 18418 8 routing architecture addressing architecture

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi-homing, and inter-domain traffic engineering. The Routing Research Group is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-rrg-design-goals-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6227
RFC6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog C. Holmberg May 2011 ASCII 34311 14 199 Early dialog Forking Provisional response

This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. [STANDARDS-TRACK]

draft-ietf-sipcore-199-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6228
RFC6229 Test Vectors for the Stream Cipher RC4 J. Strombergson S. Josefsson May 2011 ASCII 28406 12 arcfour128 arcfour256 arcfour ARC4m Stream Cipher Test Vectors Known Answer Test arcfour ARC4 WEP WPA RFC 4345

This document contains test vectors for the stream cipher RC4. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-josefsson-rc4-test-vectors-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6229
RFC6230 Media Control Channel Framework C. Boulton T. Melanchuk S. McGlashan May 2011 ASCII 112479 49

This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.

The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope. [STANDARDS-TRACK]

draft-ietf-mediactrl-sip-control-framework-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6230
RFC6231 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework S. McGlashan T. Melanchuk C. Boulton May 2011 ASCII 286771 134

This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. [STANDARDS-TRACK]

draft-ietf-mediactrl-ivr-control-package-11 RFC6623 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=6231 10.17487/RFC6231
RFC6232 Purge Originator Identification TLV for IS-IS F. Wei Y. Qin Z. Li T. Li J. Dong May 2011 ASCII 10234 6 Purge Originator Identification IIH:n LSP:y SNP:n Purge:y

At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge. This makes it difficult to locate the source IS.

To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normal Link State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.

This document updates RFC 5301, RFC 5304, and RFC 5310. [STANDARDS-TRACK]

draft-ietf-isis-purge-tlv-05 RFC5301 RFC5304 RFC5310 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6232
RFC6233 IS-IS Registry Extension for Purges T. Li L. Ginsberg May 2011 ASCII 8435 4 Intermediate System to Intermediate System LSP security authentication IANA

IANA maintains the "IS-IS TLV Codepoints" registry. This registry documents which TLVs can appear in different types of IS-IS Protocol Data Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a. purges. This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication. This document updates RFC 3563, RFC 5304, and RFC 5310. [STANDARDS-TRACK]

draft-ietf-isis-reg-purge-01 RFC3563 RFC5304 RFC5310 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6233
RFC6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) D. Eastlake 3rd T. Hansen May 2011 ASCII 236573 127

Federal Information Processing Standard, FIPS

draft-eastlake-sha2b-07 RFC4634 RFC3174 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6234
RFC6235 IP Flow Anonymization Support E. Boschi B. Trammell May 2011 ASCII 112595 43 IPFIX flow information export address anonymization pseudonymization data protection privacy

This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ipfix-anon-06 EXPERIMENTAL EXPERIMENTAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6235 10.17487/RFC6235
RFC6236 Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) I. Johansson K. Jung May 2011 ASCII 49356 23

This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a \%low-end \%hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. [STANDARDS-TRACK]

draft-ietf-mmusic-image-attributes-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=6236 10.17487/RFC6236
RFC6237 IMAP4 Multimailbox SEARCH Extension B. Leiba A. Melnikov May 2011 ASCII 21234 10 email multiple mailboxes imapext

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466. This document defines an Experimental Protocol for the Internet community.

draft-ietf-morg-multimailbox-search-07 RFC7377 RFC4466 EXPERIMENTAL EXPERIMENTAL IETF app morg 10.17487/RFC6237
RFC6238 TOTP: Time-Based One-Time Password Algorithm D. M'Raihi S. Machani M. Pei J. Rydell May 2011 ASCII 32174 16 OTP OATH HOTP two factor authentication strong authentication

This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security.

The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mraihi-totp-timebased-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6238 10.17487/RFC6238
RFC6239 Suite B Cryptographic Suites for Secure Shell (SSH) K. Igoe May 2011 ASCII 28990 14

This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-igoe-secsh-suiteb-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6239
RFC6240 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2 D. Zelig Editor R. Cohen Editor T. Nadeau Editor May 2011 ASCII 129814 67 management information base PW-CEP-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN). [STANDARDS-TRACK]

draft-ietf-pwe3-cep-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6240
RFC6241 Network Configuration Protocol (NETCONF) R. Enns Editor M. Bjorklund Editor J. Schoenwaelder Editor A. Bierman Editor June 2011 ASCII 209465 113 XML Configuration Network Management Extensible Markup Language

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]

draft-ietf-netconf-4741bis-10 RFC4741 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6241 10.17487/RFC6241
RFC6242 Using the NETCONF Protocol over Secure Shell (SSH) M. Wasserman June 2011 ASCII 22704 11 network configuration protocol

This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]

draft-ietf-netconf-rfc4742bis-08 RFC4742 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC6242
RFC6243 With-defaults Capability for NETCONF A. Bierman B. Lengyel June 2011 ASCII 51568 26 network configuration protocol

The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK]

draft-ietf-netconf-with-defaults-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC6243
RFC6244 An Architecture for Network Management Using NETCONF and YANG P. Shafer June 2011 ASCII 63276 30 network configuration protocol

The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.

This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netmod-arch-10 INFORMATIONAL INFORMATIONAL IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6244 10.17487/RFC6244
RFC6245 Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 P. Yegani K. Leung A. Lior K. Chowdhury J. Navali May 2011 ASCII 16823 8

The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic. The new extension allows a Foreign Agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4. GRE tunneling with the Key field allows the operators to have home networks that consist of multiple Virtual Private Networks (VPNs), which may have overlapping home addresses. When the tuple <Care of Address, Home Address, and Home Agent Address> is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when using IP-in-IP tunneling. [STANDARDS-TRACK]

draft-ietf-mip4-gre-key-extension-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6245
RFC6246 Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges A. Sajassi Editor F. Brockners D. Mohan Editor Y. Serbest June 2011 ASCII 51024 20 ieee bridges

One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers.

When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-l2vpn-vpls-bridge-interop-06 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC6246
RFC6247 Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status L. Eggert May 2011 ASCII 6414 4

This document reclassifies several TCP extensions that have never seen widespread use to Historic status. The affected RFCs are RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-eggert-tcpm-historicize-02 RFC1072 RFC1106 RFC1110 RFC1145 RFC1146 RFC1379 RFC1644 RFC1693 RFC4614 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6247
RFC6248 RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete A. Morton April 2011 ASCII 10192 6

This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM) Metrics Registry", as Obsolete, and withdraws the IANA IPPM Metrics Registry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-morton-ippm-rfc4148-obsolete-03 RFC4148 RFC4737 RFC5560 RFC5644 RFC6049 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6248
RFC6249 Metalink/HTTP: Mirrors and Hashes A. Bryan N. McNab T. Tsujikawa P. Poeml H. Nordstrom June 2011 ASCII 45303 21 file transfer download link signature data integrity hypertext transfer protocol ftp file transfer protocol metadata torrent

This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements for Metalink/HTTP clients and servers are described here. [STANDARDS-TRACK]

draft-bryan-metalinkhttp-22 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6249 10.17487/RFC6249
RFC6250 Evolution of the IP Model D. Thaler May 2011 ASCII 60778 25 Internet Protocol IPv4 IPv6 service model

This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were (and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed. The discussion of these properties is organized around evaluating a set of claims, or misconceptions. Finally, this document provides some guidance to protocol designers and implementers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-ip-model-evolution-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6250
RFC6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol S. Josefsson May 2011 ASCII 17051 8 kerberos tls starttls kdc

This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-josefsson-kerberos5-starttls-09 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC6251
RFC6252 A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization A. Dutta Editor V. Fajardo Y. Ohba K. Taniuchi H. Schulzrinne June 2011 ASCII 149395 57 Mobility Optimization Proactive handoff Link-layer security Handover taxonomy Layer 2 handoff Layer 3 handoff Network discovery Handover delay Packet loss Proactive binding update Multi-interface IP address acquisition Tunnel management

This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.

This document is a product of the IP Mobility Optimizations (MOBOPTS) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-mobopts-mpa-framework-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6252
RFC6253 Host Identity Protocol Certificates T. Heer S. Varjonen May 2011 ASCII 24079 12

The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the CERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and Simple Public Key Infrastructure (SPKI) certificates.

The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.

This document updates RFC 5201. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-cert-12 RFC5201 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6253
RFC6254 Request to Move RFC 2754 to Historic Status M. McFadden May 2011 ASCII 6696 3 RPS

RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them. The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System. In practice, this was never done on the public Internet. This document requests that RFC 2754 be moved to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iana-rfc2754-to-historic-02 RFC2754 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6254
RFC6255 Delay-Tolerant Networking Bundle Protocol IANA Registries M. Blanchet May 2011 ASCII 19606 9 DTN SNDV DTNRG Space networking

The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and Licklider Transmission Protocol. The specifications of these protocols contain fields that are subject to a registry. For the purpose of its research work, the group created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official custody. This document describes the actions executed by IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-dtnrg-iana-bp-registries-02 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6255
RFC6256 Using Self-Delimiting Numeric Values in Protocols W. Eddy E. Davies May 2011 ASCII 40765 17 SDNV DTN

Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-dtnrg-sdnv-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6256
RFC6257 Bundle Security Protocol Specification S. Symington S. Farrell H. Weiss P. Lovell May 2011 ASCII 142509 60

This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.

This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-bundle-security-19 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6257 10.17487/RFC6257
RFC6258 Delay-Tolerant Networking Metadata Extension Block S. Symington May 2011 ASCII 22584 10 DTN Delay-Tolerant Networking Distruption-Tolerant Networking

This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-bundle-metadata-block-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6258
RFC6259 Delay-Tolerant Networking Previous-Hop Insertion Block S. Symington May 2011 ASCII 23278 10 DTN Delay-Tolerant Networking Distruption-Tolerant Networking

This document defines an extension block for use with the Delay- Tolerant Networking (DTN) Bundle Protocol. This Previous-Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-bundle-previous-hop-block-12 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6259
RFC6260 Compressed Bundle Header Encoding (CBHE) S. Burleigh May 2011 ASCII 25381 12 DTN delay-tolerant networking BP bundle protocol IPN

This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.

Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.

This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-cbhe-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6260
RFC6261 Encrypted Signaling Transport Modes for the Host Identity Protocol A. Keranen May 2011 ASCII 28354 13

This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-over-hip-06 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6261
RFC6262 RTP Payload Format for IP-MR Speech Codec S. Ikonin August 2011 ASCII 39511 19 ipmr vocoder multirate scalable scalability

This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors. [STANDARDS-TRACK]

draft-ietf-avt-rtp-ipmr-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6262
RFC6263 Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows X. Marjou A. Sollaud June 2011 ASCII 23345 12 AVT SDP port

This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK]

draft-ietf-avt-app-rtp-keepalive-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6263
RFC6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition S. Jiang D. Guo B. Carpenter June 2011 ASCII 31881 13

Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.

This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts and IPv4 access services for IPv4 hosts while leaving much of a legacy ISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-incremental-cgn-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6264
RFC6265 HTTP State Management Mechanism A. Barth April 2011 ASCII 79724 37 Cookie Set-Cookie Secure HttpOnly

This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]

draft-ietf-httpstate-cookie-23 RFC2965 PROPOSED STANDARD PROPOSED STANDARD IETF app httpstate http://www.rfc-editor.org/errata_search.php?rfc=6265 10.17487/RFC6265
RFC6266 Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) J. Reschke June 2011 ASCII 26080 14 filename attachment inline

RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. [STANDARDS-TRACK]

draft-ietf-httpbis-content-disp-09 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=6266 10.17487/RFC6266
RFC6267 MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) V. Cakulev G. Sundaram June 2011 ASCII 68031 30 Identity based encryption authentication key agreement

This document describes a key management protocol variant for the Multimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service. In particular, this variant utilizes Identity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework. This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cakulev-mikey-ibake-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6267
RFC6268 Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX) J. Schaad S. Turner July 2011 ASCII 55693 33 ASN.1 Certficate Extensions HMAC

The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-additional-new-asn-08 RFC5911 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6268
RFC6269 Issues with IP Address Sharing M. Ford Editor M. Boucadair A. Durand P. Levis P. Roberts June 2011 ASCII 71660 29 IPv4 address exhaustion completion shared sharing issues

The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.

Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-intarea-shared-addressing-issues-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC6269
RFC6270 The 'tn3270' URI Scheme M. Yevstifeyev June 2011 ASCII 10876 6 URI Telnet Telnet 3270 TN3270

This document is the specification of the 'tn3270' Uniform Resource Identifier (URI) scheme, which is used to designate the access to the resources available via Telnet 3270 mode (TN3270) and Telnet 3270 Enhanced mode (TN3270E). It updates RFC 1041 and RFC 2355, which specify these protocols, and RFC 1738, which firstly mentioned this URI scheme without defining its syntax and semantics. [STANDARDS-TRACK]

draft-yevstifeyev-tn3270-uri-18 RFC2355 RFC1738 RFC1041 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6270
RFC6271 Requirements for SIP-Based Session Peering J-F. Mule June 2011 ASCII 54492 23 IETF speermint guidelines requirements for session interconnects session peering SIP interconnects VoIP peering

This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-speermint-requirements-11 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6271
RFC6272 Internet Protocols for the Smart Grid F. Baker D. Meyer June 2011 ASCII 162815 66

This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-baker-ietf-core-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6272
RFC6273 The Secure Neighbor Discovery (SEND) Hash Threat Analysis A. Kukec S. Krishnan S. Jiang June 2011 ASCII 13100 7

This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-csi-hash-threat-12 INFORMATIONAL INFORMATIONAL IETF int csi 10.17487/RFC6273
RFC6274 Security Assessment of the Internet Protocol Version 4 F. Gont July 2011 ASCII 179909 75 vulnerabilities Denial of Service resiliency hardening information leakage

This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsec-ip-security-07 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC6274
RFC6275 Mobility Support in IPv6 C. Perkins Editor D. Johnson J. Arkko July 2011 ASCII 405488 169 mobility IPv6 internet protocol nodes

This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDARDS-TRACK]

draft-ietf-mext-rfc3775bis-13 RFC3775 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=6275 10.17487/RFC6275
RFC6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO) R. Droms P. Thubert F. Dupont W. Haddad C. Bernardos July 2011 ASCII 30430 14 IPv6 mobile router home agent mobile network prefix

One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network. This document specifies how DHCPv6 prefix delegation can be used for this configuration task. The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router. When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. [STANDARDS-TRACK]

draft-ietf-mext-nemo-pd-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=6276 10.17487/RFC6276
RFC6277 Online Certificate Status Protocol Algorithm Agility S. Santesson P. Hallam-Baker June 2011 ASCII 21682 11 ocsp

The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK]

draft-ietf-pkix-ocspagility-10 RFC6960 RFC2560 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6277
RFC6278 Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax J. Herzog R. Khazan June 2011 ASCII 36593 16 set-key group-key

This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-herzog-static-ecdh-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6278
RFC6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement M. Liebsch Editor S. Jeong Q. Wu June 2011 ASCII 32954 14 Local Routing Route Optimization Traffic Offload

Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netext-pmip6-lr-ps-06 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC6279
RFC6280 An Architecture for Location and Location Privacy in Internet Applications R. Barnes M. Lepinski A. Cooper J. Morris H. Tschofenig H. Schulzrinne July 2011 ASCII 99801 41 geolocation geopriv

Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. This memo documents an Internet Best Current Practice.

draft-ietf-geopriv-arch-03 RFC3693 RFC3694 BCP0160 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai geopriv 10.17487/RFC6280
RFC6281 Understanding Apple's Back to My Mac (BTMM) Service S. Cheshire Z. Zhu R. Wakikawa L. Zhang June 2011 ASCII 39314 16

This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zhu-mobileme-doc-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6281 10.17487/RFC6281
RFC6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks J. Hui Editor P. Thubert September 2011 ASCII 52588 24 LLN Low Power radio 802.15.4 powerline ISA100.11a RFC 4944

This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]

draft-ietf-6lowpan-hc-15 RFC4944 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan 10.17487/RFC6282
RFC6283 Extensible Markup Language Evidence Record Syntax (XMLERS) A. Jerman Blazic S. Saljic T. Gondrom July 2011 ASCII 99031 43 long term trust integrity long term integrity data preservation document preservation time-stamp time-stamping archive time stamp electronic archive electronic archiving trusted archiving long-term archive archive data evidence evidence record evidence record syntax hash tree ERS XML hash signature renewal algorithm cryptography

In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data. The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. [STANDARDS-TRACK]

draft-ietf-ltans-xmlers-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC6283
RFC6284 Port Mapping between Unicast and Multicast RTP Sessions A. Begen D. Wing T. Van Caenegem June 2011 ASCII 73289 30 Port mapping port translation RTP multicast NAT

This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK]

draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6284
RFC6285 Unicast-Based Rapid Acquisition of Multicast RTP Sessions B. Ver Steeg A. Begen T. Van Caenegem Z. Vax June 2011 ASCII 141497 56 SSM multicast IPTV fast channel change

When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.

In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. [STANDARDS-TRACK]

draft-ietf-avt-rapid-acquisition-for-rtp-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6285
RFC6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4 E. Chen J. Yuan June 2011 ASCII 7497 4

To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System-wide (AS-wide) uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issues. This document updates RFC 4271. [STANDARDS-TRACK]

draft-ietf-idr-bgp-identifier-14 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=6286 10.17487/RFC6286
RFC6287 OCRA: OATH Challenge-Response Algorithm D. M'Raihi J. Rydell S. Bajaj S. Machani D. Naccache June 2011 ASCII 78076 38 HOTP TOTP One-Time Password Authentication Signature

This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication (OATH). The specified mechanisms leverage the HMAC-based One-Time Password (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mraihi-mutual-oath-hotp-variants-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6287 10.17487/RFC6287
RFC6288 URN Namespace for the Defence Geospatial Information Working Group (DGIWG) C. Reed August 2011 ASCII 16218 8 Namespace Identifier nid DGIWG Registry System drs

This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) Namespace resources published by the Defence Geospatial Information Working Group (DGIWG). The DGIWG defines and manages resources that utilize this URN name model.

Management activities for these and other resource types are provided by the DGIWG Registry System (DRS). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-reed-urn-dgiwg-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6288
RFC6289 A Uniform Resource Name (URN) Namespace for CableLabs E. Cardona S. Channabasappa J-F. Mule June 2011 ASCII 12976 7 namespace identifier nid

This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs). CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cardona-cablelabs-urn-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6289
RFC6290 A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) Y. Nir Editor D. Wierbowski F. Detienne P. Sethi June 2011 ASCII 48891 22 QCD

This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token.

When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. [STANDARDS-TRACK]

draft-ietf-ipsecme-failure-detection-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=6290 10.17487/RFC6290
RFC6291 Guidelines for the Use of the "OAM" Acronym in the IETF L. Andersson H. van Helvoort R. Bonica D. Romascanu S. Mansfield June 2011 ASCII 16696 9

At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again.

This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice.

draft-ietf-opsawg-mpls-tp-oam-def-10 BCP0161 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsawg 10.17487/RFC6291
RFC6292 Requirements for a Working Group Charter Tool P. Hoffman June 2011 ASCII 23701 11

The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups. The tool will also allow the IETF community to view the status of the chartering process. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-genarea-charter-tool-09 RFC6433 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6292 10.17487/RFC6292
RFC6293 Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker P. Hoffman June 2011 ASCII 36874 17

The document gives a set of requirements for extending the IETF Datatracker to give individual IETF community members, including the IETF leadership, easy methods for tracking the progress of the Internet-Drafts and RFCs of interest to them. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-genarea-datatracker-community-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6293
RFC6294 Survey of Proposed Use Cases for the IPv6 Flow Label Q. Hu B. Carpenter June 2011 ASCII 43303 18 Quality of service QoS

The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hu-flow-label-cases-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6294
RFC6295 RTP Payload Format for MIDI J. Lazzaro J. Wawrzynek June 2011 ASCII 409730 171 asc content streaming DLS 2 General MIDI MIDI MIDI file MIDI file streaming MIDI light control MIDI rendering MIDI ringtone MIDI streaming MIDI sequencer MIDI time code MIDI timecode MIDI Manufacturers Association MMA mpeg4generic MPEG 4 MPEG 4 Structured Audio MPEG 4 Synthetic Coding MTC musical notes network musical performance recovery journal Show Control sonification ringtone rtpmidi RTP RTP MIDI SMPTE time code SMPTE timecode Standard MIDI Files XMF

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. This document obsoletes RFC 4695. [STANDARDS-TRACK]

draft-ietf-payload-rfc4695-bis-02 RFC4695 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6295
RFC6296 IPv6-to-IPv6 Network Prefix Translation M. Wasserman F. Baker June 2011 ASCII 73700 32

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer. This document defines an Experimental Protocol for the Internet community.

draft-mrw-nat66-16 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6296 10.17487/RFC6296
RFC6297 A Survey of Lower-than-Best-Effort Transport Protocols M. Welzl D. Ros June 2011 ASCII 46532 18 Less-than-Best-Effort Congestion Control LEDBAT

This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it. Such protocols could be used for delay-insensitive "background" traffic, as they provide what is sometimes called a "less than" (or "lower than") best-effort service. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ledbat-survey-07 INFORMATIONAL INFORMATIONAL IETF tsv ledbat 10.17487/RFC6297
RFC6298 Computing TCP's Retransmission Timer V. Paxson M. Allman J. Chu M. Sargent June 2011 ASCII 22454 11 RTO

This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]

draft-paxson-tcpm-rfc2988bis-02 RFC2988 RFC1122 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6298
RFC6301 A Survey of Mobility Support in the Internet Z. Zhu R. Wakikawa L. Zhang July 2011 ASCII 84861 33

Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions. We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zhu-mobility-survey-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6301
RFC6302 Logging Recommendations for Internet-Facing Servers A. Durand I. Gashinsky D. Lee S. Sheppard June 2011 ASCII 10039 5 port logging

In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address. This memo documents an Internet Best Current Practice.

draft-ietf-intarea-server-logging-recommendations-04 BCP0162 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6302
RFC6303 Locally Served DNS Zones M. Andrews July 2011 ASCII 22503 10 AS112 Reverse IN-ADDR.ARPA IP6.ARPA RFC1918

Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well-known zones with similar characteristics. This memo documents an Internet Best Current Practice.

draft-ietf-dnsop-default-local-zones-15 BCP0163 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC6303
RFC6304 AS112 Nameserver Operations J. Abley W. Maton July 2011 ASCII 34002 18 DNS RFC1918

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dnsop-as112-ops-09 RFC7534 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6304
RFC6305 I'm Being Attacked by PRISONER.IANA.ORG! J. Abley W. Maton July 2011 ASCII 15287 8

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project.

Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked.

This document provides background information and technical advice to those firewall operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dnsop-as112-under-attack-help-help-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6305
RFC6306 Hierarchical IPv4 Framework P. Frejborg July 2011 ASCII 160667 65 core address space area locators alocs edge address space endpoint locators elocs

This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique. In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.

This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing Domain Name System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers. This document defines an Experimental Protocol for the Internet community.

draft-frejborg-hipv4-14 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6306
RFC6307 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks D. Black Editor L. Dunbar Editor M. Roth R. Solomon April 2012 ASCII 49421 21

A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. [STANDARDS-TRACK]

draft-ietf-pwe3-fc-encap-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6307
RFC6308 Overview of the Internet Multicast Addressing Architecture P. Savola June 2011 ASCII 30988 14 assignment allocation SSM ASM GLOP

The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mboned-addrarch-07 RFC2908 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC6308
RFC6309 IANA Rules for MIKEY (Multimedia Internet KEYing) J. Arkko A. Keranen J. Mattsson August 2011 ASCII 10706 6 short-term key message long-term key message oma bac browser and content broadcast

This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 5410, and 6043; it obsoletes RFC 4909. [STANDARDS-TRACK]

draft-arkko-mikey-iana-01 RFC4909 RFC3830 RFC4563 RFC5410 RFC6043 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6309
RFC6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping M. Aissaoui P. Busschbach L. Martini M. Morrow T. Nadeau Y(J). Stein July 2011 ASCII 85733 40 interworking defect state defect indication pseudowire OAM

This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects. It addresses ATM, Frame Relay, Time Division Multiplexing (TDM), and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs). [STANDARDS-TRACK]

draft-ietf-pwe3-oam-msg-map-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 http://www.rfc-editor.org/errata_search.php?rfc=6310 10.17487/RFC6310
RFC6311 Protocol Support for High Availability of IKEv2/IPsec R. Singh Editor G. Kalyani Y. Nir Y. Sheffer D. Zhang July 2011 ASCII 58672 26 IPsec high availability load sharing clustering fail-over

The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However, there are many issues in IPsec HA clustering, and in particular in Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.

This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters. [STANDARDS-TRACK]

draft-ietf-ipsecme-ipsecha-protocol-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=6311 10.17487/RFC6311
RFC6312 Mobile Networks Considerations for IPv6 Deployment R. Koodli July 2011 ASCII 45988 17

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-v6-in-mobile-networks-05 RFC6342 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6312
RFC6313 Export of Structured Data in IP Flow Information Export (IPFIX) B. Claise G. Dhandapani P. Aitken S. Yates July 2011 ASCII 163360 71 ipfix information model

This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK]

draft-ietf-ipfix-structured-data-06 RFC5102 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6313 10.17487/RFC6313
RFC6314 NAT Traversal Practices for Client-Server SIP C. Boulton J. Rosenberg G. Camarillo F. Audet July 2011 ASCII 152998 60

Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-nat-scenarios-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6314
RFC6315 IANA Registration for Enumservice 'iax' E. Guy K. Darilion July 2011 ASCII 11067 6 ENUM E.164 VoIP Voice over IP

This document registers an Enumservice for the Inter-Asterisk eXchange (IAX) protocol according to the guidelines given in RFC 6117. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-enum-iax-10 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC6315
RFC6316 Sockets Application Program Interface (API) for Multihoming Shim M. Komu M. Bagnulo K. Slavov S. Sugimoto Editor July 2011 ASCII 93076 44 Shim6 HIP identifier/locator split

This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.

This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called "shim sub- layer") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and the Host Identity Protocol (HIP). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-shim6-multihome-shim-api-17 INFORMATIONAL INFORMATIONAL IETF int shim6 10.17487/RFC6316
RFC6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP) M. Komu T. Henderson July 2011 ASCII 43970 18 host identity tag cryptographic identity cryptographic namespace sockets API Shim6 opportunistic mode resolver HIP wildcard address ORCHID source address selection HIT prefix locator handling

This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags (HITs) and locators. With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-native-api-12 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6317
RFC6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) R. Housley J. Solinas June 2011 ASCII 31488 15

This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-housley-rfc5008bis-01 RFC5008 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6318
RFC6319 Issues Associated with Designating Additional Private IPv4 Address Space M. Azinger L. Vegoda July 2011 ASCII 26939 12 private network

When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of private IPv4 address space.

While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-azinger-additional-private-ipv4-space-issues-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6319
RFC6320 Protocol for Access Node Control Mechanism in Broadband Networks S. Wadhwa J. Moisand T. Haag N. Voigt T. Taylor Editor October 2011 ASCII 178446 82 ancp

This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.

ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. [STANDARDS-TRACK]

draft-ietf-ancp-protocol-17 RFC7256 PROPOSED STANDARD PROPOSED STANDARD IETF int ancp 10.17487/RFC6320
RFC6321 xCal: The XML Format for iCalendar C. Daboo M. Douglass S. Lees August 2011 ASCII 79701 54 extensible markup language

This specification defines "xCal", an XML format for iCalendar data. [STANDARDS-TRACK]

draft-daboo-et-al-icalendar-in-xml-11 RFC6868 RFC7529 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6321 10.17487/RFC6321
RFC6322 Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams P. Hoffman July 2011 ASCII 24153 11

This document describes extending the IETF Datatracker to capture and display the progression of Internet-Drafts that are intended to be published as RFCs by the IAB, IRTF, or Independent Submissions Editor. The states and annotations that are to be added to the Datatracker will be applied to Internet-Drafts as soon as any of these streams identify the Internet-Draft as a potential eventual RFC, and will continue through the lifetime of the Internet-Draft. The goal of adding this information to the Datatracker is to give the whole Internet community more information about the status of these Internet-Drafts and the streams from which they originate. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hoffman-alt-streams-tracker-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6322
RFC6323 Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP) G. Renker G. Fairhurst July 2011 ASCII 27434 13 DCCP TFRC CCID-3 CCID-4

This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol (DCCP). It updates specifications for the CCID-3 and CCID-4 Congestion Control IDs of DCCP.

The update addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.

It is integrated into the feature set of DCCP as an end-to-end negotiable extension. [STANDARDS-TRACK]

draft-ietf-dccp-tfrc-rtt-option-06 RFC4342 RFC5622 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC6323
RFC6324 Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations G. Nakibly F. Templin August 2011 ASCII 47385 19 Encapsulation ISATAP 6rd

This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-tunnel-loops-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6324
RFC6325 Routing Bridges (RBridges): Base Protocol Specification R. Perlman D. Eastlake 3rd D. Dutt S. Gai A. Ghanwani July 2011 ASCII 243158 99 TRILL

Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.

RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.

The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]

draft-ietf-trill-rbridge-protocol-16 RFC6327 RFC6439 RFC7172 RFC7177 RFC7357 RFC7179 RFC7180 RFC7455 PROPOSED STANDARD PROPOSED STANDARD IETF int trill http://www.rfc-editor.org/errata_search.php?rfc=6325 10.17487/RFC6325
RFC6326 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS D. Eastlake A. Banerjee D. Dutt R. Perlman A. Ghanwani July 2011 ASCII 51059 25 TRILL RBridge IS-IS ISIS

The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. [STANDARDS-TRACK]

draft-ietf-isis-trill-05 RFC7176 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6326 10.17487/RFC6326
RFC6327 Routing Bridges (RBridges): Adjacency D. Eastlake 3rd R. Perlman A. Ghanwani D. Dutt V. Manral July 2011 ASCII 59014 26 RBridge TRILL Adjacency

The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU (Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL. [STANDARDS-TRACK]

draft-ietf-trill-adj-07 RFC7177 RFC6325 RFC7180 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6327
RFC6328 IANA Considerations for Network Layer Protocol Identifiers D. Eastlake 3rd July 2011 ASCII 16123 9 NLPID

Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID). This document provides NLPID IANA considerations. This memo documents an Internet Best Current Practice.

draft-eastlake-nlpid-iana-considerations-04 BCP0164 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6328
RFC6329 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging D. Fedyk Editor P. Ashwood-Smith Editor D. Allan A. Bragg P. Unbehagen April 2012 ASCII 88465 37 spb

802.1aq Shortest Path Bridging (SPB) has been standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths. This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations. This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples. [STANDARDS-TRACK]

draft-ietf-isis-ieee-aq-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6329 10.17487/RFC6329
RFC6330 RaptorQ Forward Error Correction Scheme for Object Delivery M. Luby A. Shokrollahi M. Watson T. Stockhammer L. Minder August 2011 ASCII 169852 69 FEC code fountain code systematic code AL FEC code Sub-blocking FEC object delivery

This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.

RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.

The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-raptorq-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC6330
RFC6331 Moving DIGEST-MD5 to Historic A. Melnikov July 2011 ASCII 14047 6 http hypertext transfer protocol security simple layer

This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of SASL mechanisms and moves RFC 2831 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-kitten-digest-to-historic-04 RFC2831 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC6331
RFC6332 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) A. Begen E. Friedrich July 2011 ASCII 35217 16 SSM multicast IPTV RAMS rapid acquisition fast channel change

In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avtext-multicast-acq-rtcp-xr-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6332
RFC6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion A. Durand R. Droms J. Woodyatt Y. Lee August 2011 ASCII 65622 32 NAT

This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK]

draft-ietf-softwire-dual-stack-lite-11 RFC7335 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6333
RFC6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite D. Hankins T. Mrugalski August 2011 ASCII 14362 7 Softwire DS-Lite

This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). [STANDARDS-TRACK]

draft-ietf-softwire-ds-lite-tunnel-option-11 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6334
RFC6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry M. Cotton L. Eggert J. Touch M. Westerlund S. Cheshire August 2011 ASCII 79088 33 IANA transport ports port numbers allocation assignment procedures

This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.

This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.

draft-ietf-tsvwg-iana-ports-10 RFC2780 RFC2782 RFC3828 RFC4340 RFC4960 RFC5595 BCP0165 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6335 10.17487/RFC6335
RFC6336 IANA Registry for Interactive Connectivity Establishment (ICE) Options M. Westerlund C. Perkins July 2011 ASCII 8228 5

It has been identified that "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols" (RFC 5245) is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC 5245. [STANDARDS-TRACK]

draft-ietf-mmusic-ice-options-registry-02 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6336
RFC6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model S. Okumura T. Sawada P. Kyzivat August 2011 ASCII 76776 33 answer offer SDP SIP

The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-sip-offeranswer-18 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6337
RFC6338 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC) V. Giralt R. McDuff August 2011 ASCII 21688 11 TERENA tf-emc2

This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC).

The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-giralt-schac-ns-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6338
RFC6339 Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API) S. Josefsson L. Hornquist Astrand August 2011 ASCII 13285 8

This document describes three abstract Generic Security Service Application Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs. This document also specifies C bindings for the abstract interfaces. [STANDARDS-TRACK]

draft-josefsson-gss-capsulate-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6339
RFC6340 Textual Conventions for the Representation of Floating-Point Numbers R. Presuhn August 2011 ASCII 13811 7 Network Management IEEE 754 Floating-point MIB SMIv2 Textual Convention FLOAT-TC-MIB

This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. [STANDARDS-TRACK]

draft-ietf-opsawg-mib-floats-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC6340
RFC6341 Use Cases and Requirements for SIP-Based Media Recording (SIPREC) K. Rehor Editor L. Portman Editor A. Hutton R. Jain August 2011 ASCII 34155 16

Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.

Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-siprec-req-12 INFORMATIONAL INFORMATIONAL IETF rai siprec 10.17487/RFC6341
RFC6342 Mobile Networks Considerations for IPv6 Deployment R. Koodli August 2011 ASCII 46288 17

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-v6-in-mobile-networks-rfc6312bis RFC6312 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6342
RFC6343 Advisory Guidelines for 6to4 Deployment B. Carpenter August 2011 ASCII 51496 20 IPv6 relay

This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-6to4-advisory-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6343
RFC6344 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) G. Bernstein Editor D. Caviglia R. Rabbat H. van Helvoort August 2011 ASCII 44897 21

This document describes requirements for, and the use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS). LCAS can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. This document updates RFC 4606 by making modifications to the procedures for supporting virtual concatenation. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-vcat-lcas-13 RFC4606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6344
RFC6345 Protocol for Carrying Authentication for Network Access (PANA) Relay Element P. Duffy S. Chakrabarti R. Cragie Y. Ohba Editor A. Yegin August 2011 ASCII 25128 12 EAP ZigBee

This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing. [STANDARDS-TRACK]

draft-ohba-pana-relay-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6345 10.17487/RFC6345
RFC6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage R. Bush Editor August 2011 ASCII 89553 38

We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.

This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community.

draft-ymbk-aplusp-10 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6346
RFC6347 Datagram Transport Layer Security Version 1.2 E. Rescorla N. Modadugu January 2012 ASCII 73546 32 dtls dtls protocol

This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]

draft-ietf-tls-rfc4347-bis-06 RFC4347 RFC7507 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6347 10.17487/RFC6347
RFC6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol JL. Le Roux Editor T. Morin Editor September 2011 ASCII 38902 20 MPLS LDP multipoint P2MP multicast

This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure.

This work was overtaken by the protocol solution developed by the MPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work. This document defines a Historic Document for the Internet community.

draft-ietf-mpls-mp-ldp-reqs-08 HISTORIC HISTORIC IETF rtg mpls 10.17487/RFC6348
RFC6349 Framework for TCP Throughput Testing B. Constantine G. Forget R. Geib R. Schrage August 2011 ASCII 62494 27 metric TCP testing

This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network. The goal is to provide a better indication in regard to user experience. In this framework, TCP and IP parameters are specified to optimize TCP Throughput. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-tcp-throughput-tm-13 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6349
RFC6350 vCard Format Specification S. Perreault August 2011 ASCII 139895 74 vCard

This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]

draft-ietf-vcarddav-vcardrev-22 RFC2425 RFC2426 RFC4770 RFC2739 RFC6868 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6350 10.17487/RFC6350
RFC6351 xCard: vCard XML Representation S. Perreault August 2011 ASCII 34086 22 vCard

This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]

draft-ietf-vcarddav-vcardxml-11 RFC6868 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6351 10.17487/RFC6351
RFC6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) C. Daboo August 2011 ASCII 98548 48 address address book contact

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK]

draft-ietf-vcarddav-carddav-10 RFC6764 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC6352
RFC6353 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) W. Hardaker July 2011 ASCII 148571 65 dtls datagram transport layer security tls transport model tlstm SNMP-TLS-TM-MIB

This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-dtls-tm-rfc5953bis-00 RFC5953 STD0078 INTERNET STANDARD DRAFT STANDARD IETF sec isms 10.17487/RFC6353
RFC6354 Forward-Shifted RTP Redundancy Payload Support Q. Xie August 2011 ASCII 26488 13

This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). [STANDARDS-TRACK]

draft-ietf-avt-forward-shifted-red-08 RFC2198 RFC4102 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6354
RFC6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) T. Narten J. Johnson August 2011 ASCII 11453 5 universally unique identifier

This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID. DUID-UUIDs are derived from the already-standardized Universally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. [STANDARDS-TRACK]

draft-ietf-dhc-duid-uuid-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6355
RFC6356 Coupled Congestion Control for Multipath Transport Protocols C. Raiciu M. Handley D. Wischik October 2011 ASCII 27961 12 multipath tcp congestion control

Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.

New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.

This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mptcp-congestion-07 EXPERIMENTAL EXPERIMENTAL IETF tsv mptcp 10.17487/RFC6356
RFC6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control V. Hilt E. Noel C. Shen A. Abdelal August 2011 ASCII 64252 25 Session Initiation Protocol Overload Control Congestion Collapse

Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-soc-overload-design-08 INFORMATIONAL INFORMATIONAL IETF rai soc 10.17487/RFC6357
RFC6358 Additional Master Secret Inputs for TLS P. Hoffman January 2012 ASCII 9074 4 tls dtls datagram tls

This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS). This document defines an Experimental Protocol for the Internet community.

draft-hoffman-tls-master-secret-input-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6358
RFC6359 Datatracker Extensions to Include IANA and RFC Editor Processing Information S. Ginoza M. Cotton A. Morris September 2011 ASCII 38532 18 id-tracker backend extensions

This document captures the requirements for integrating IANA and RFC Editor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC. Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay. Therefore, this document also describes the requirements to make such automation possible. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-genarea-datatracker-iana-rfced-extns-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6359
RFC6360 Conclusion of FYI RFC Sub-Series R. Housley August 2011 ASCII 4729 3

This document concludes the For Your Information (FYI) sub-series of RFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision. This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iesg-rfc1150bis-01 RFC1150 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6360
RFC6361 PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol J. Carlson D. Eastlake 3rd August 2011 ASCII 17705 8 point-to-point protocol rbridges routing bridges

The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. [STANDARDS-TRACK]

draft-ietf-pppext-trill-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6361
RFC6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT) K. Meadors Editor August 2011 ASCII 15137 8 EDIINT AS2 Multiple Attachments

The Electronic Data Interchange - Internet Integration (EDIINT) AS1, AS2, and AS3 messages were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDIINT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This Informational RFC describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDIINT transport message. The attachments are stored within the MIME multipart/related structure. A minimal list of content-types to be supported as attachments is provided. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-meadors-multiple-attachments-ediint-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6362
RFC6363 Forward Error Correction (FEC) Framework M. Watson A. Begen V. Roca October 2011 ASCII 98725 42 Reliable streaming content delivery FEC schemes

This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. [STANDARDS-TRACK]

draft-ietf-fecframe-framework-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6363
RFC6364 Session Description Protocol Elements for the Forward Error Correction (FEC) Framework A. Begen October 2011 ASCII 36160 18 FEC configuration FEC topologies

This document specifies the use of the Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. [STANDARDS-TRACK]

draft-ietf-fecframe-sdp-elements-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6364
RFC6365 Terminology Used in Internationalization in the IETF P. Hoffman J. Klensin September 2011 ASCII 103155 47 i18n vocabulary terms

This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice.

draft-ietf-appsawg-rfc3536bis-06 RFC3536 BCP0166 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6365 10.17487/RFC6365
RFC6366 Requirements for an Internet Audio Codec J. Valin K. Vos August 2011 ASCII 39355 17

This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-codec-requirements-05 INFORMATIONAL INFORMATIONAL IETF rai codec 10.17487/RFC6366
RFC6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) S. Kanno M. Kanda September 2011 ASCII 17613 8 TLS GCM Eliptic Curve Encryption Block Cipher psk

This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-kanno-tls-camellia-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6367 10.17487/RFC6367
RFC6368 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) P. Marques R. Raszuk K. Patel K. Kumaki T. Yamagata September 2011 ASCII 29938 14 l3vpn iBGP loops as-override attribute set attr_set

This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK]

draft-ietf-l3vpn-ibgp-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6368 10.17487/RFC6368
RFC6369 Forwarding and Control Element Separation (ForCES) Implementation Experience E. Haleplidis O. Koufopavlou S. Denazis September 2011 ASCII 34236 18

The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-haleplidis-forces-implementation-experience-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6369
RFC6370 MPLS Transport Profile (MPLS-TP) Identifiers M. Bocci G. Swallow E. Gray September 2011 ASCII 35294 17

This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK]

draft-ietf-mpls-tp-identifiers-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6370
RFC6371 Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks I. Busi Editor D. Allan Editor September 2011 ASCII 142857 62

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures.

This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-oam-framework-11 RFC6435 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6371 10.17487/RFC6371
RFC6372 MPLS Transport Profile (MPLS-TP) Survivability Framework N. Sprecher Editor A. Farrel Editor September 2011 ASCII 142437 56 Protection Restoration Recovery

Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.

This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-survive-fwk-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6372
RFC6373 MPLS Transport Profile (MPLS-TP) Control Plane Framework L. Andersson Editor L. Berger Editor L. Fang Editor N. Bitar Editor E. Gray Editor September 2011 ASCII 144259 57

The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management-plane functions are out of scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-mpls-tp-cp-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6373
RFC6374 Packet Loss and Delay Measurement for MPLS Networks D. Frost S. Bryant September 2011 ASCII 123462 52

Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]

draft-ietf-mpls-loss-delay-04 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6374 10.17487/RFC6374
RFC6375 A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks D. Frost Editor S. Bryant Editor September 2011 ASCII 10026 5

Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374.

The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks.

This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-loss-delay-profile-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6375
RFC6376 DomainKeys Identified Mail (DKIM) Signatures D. Crocker Editor T. Hansen Editor M. Kucherawy Editor September 2011 ASCII 176999 76 email architecture abuse verification anti-abuse identity integrity responsible author sender originator email filtering anti-phishing mail signature

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.

This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]

draft-ietf-dkim-rfc4871bis-15 RFC4871 RFC5672 STD0076 INTERNET STANDARD DRAFT STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=6376 10.17487/RFC6376
RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists M. Kucherawy September 2011 ASCII 61792 26 email architecture verification anti-abuse identity integrity responsible author sender originator

DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). This memo documents an Internet Best Current Practice.

draft-ietf-dkim-mailinglists-12 BCP0167 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=6377 10.17487/RFC6377
RFC6378 MPLS Transport Profile (MPLS-TP) Linear Protection Y. Weingarten Editor S. Bryant E. Osborne N. Sprecher A. Fulignoli Editor October 2011 ASCII 99684 45 PSC Protection State Coordination Protocol,

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK]

draft-ietf-mpls-tp-linear-protection-09 RFC7214 RFC7271 RFC7324 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6378
RFC6379 Suite B Cryptographic Suites for IPsec L. Law J. Solinas October 2011 ASCII 12624 7 UI suites user interface suites elliptic curve ike

This document proposes four cryptographic user interface suites ("UI suites") for IP Security (IPsec), similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This document obsoletes RFC 4869, which presented earlier versions of these suites. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-law-rfc4869bis-01 RFC4869 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6379
RFC6380 Suite B Profile for Internet Protocol Security (IPsec) K. Burgin M. Peck October 2011 ASCII 21769 10 cryptographic algorithm policy security application suite b cryptography

The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec).

Since many of the Suite B algorithms are used in other environments, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant detail repeated to aid developers who choose to support Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-burgin-ipsec-suiteb-profile-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6380
RFC6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types R. Gellens D. Singer P. Frojdh August 2011 ASCII 39790 19 codec container audio video 3gpp 3gpp2

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered.

This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.).

Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. [STANDARDS-TRACK]

draft-gellens-mime-bucket-bis-09 RFC4281 RFC3839 RFC4393 RFC4337 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6381
RFC6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services D. McPherson R. Donnelly F. Scalzo October 2011 ASCII 25224 10 BGP SIDR RPKI security routing operations root TLD DNS DDOS peering RIR IRR MITM

This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment. This memo documents an Internet Best Current Practice.

draft-ietf-grow-unique-origin-as-01 BCP0169 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC6382
RFC6383 Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE K. Shiomoto A. Farrel September 2011 ASCII 26456 11 RSVP-TE GMPLS MPLS-TE cross-connect data plane

The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.

End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.

This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-shiomoto-ccamp-switch-programming-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6383
RFC6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation I. van Beijnum October 2011 ASCII 38126 16 FTP SIIT NAT64

The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.

FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. [STANDARDS-TRACK]

draft-ietf-behave-ftp64-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6384
RFC6385 General Area Review Team (Gen-ART) Experiences M. Barnes A. Doria H. Alvestrand B. Carpenter October 2011 ASCII 53233 23 genart

The General Area Review Team (Gen-ART) has been doing reviews of Internet-Drafts (I-Ds) since 2004. This document discusses the experience and the lessons learned over the past 7 years of this process. The review team initially reviewed the I-Ds before each of the IESG telechats. Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF Last Call is necessary for the I-D. The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-doria-genart-experience-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6385
RFC6386 VP8 Data Format and Decoding Guide J. Bankoski J. Koleszar L. Quillio J. Salonen P. Wilkins Y. Xu November 2011 ASCII 564613 304

This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-bankoski-vp8-bitstream-06 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6386 10.17487/RFC6386
RFC6387 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) A. Takacs L. Berger D. Caviglia D. Fedyk J. Meuric September 2011 ASCII 23329 11 rsvp resource reservation protocol

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The approach presented is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467. [STANDARDS-TRACK]

draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-03 RFC5467 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6387
RFC6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths IJ. Wijnands Editor I. Minei Editor K. Kompella B. Thomas November 2011 ASCII 86457 39

This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-p2mp-15 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6388
RFC6389 MPLS Upstream Label Assignment for LDP R. Aggarwal JL. Le Roux November 2011 ASCII 30935 13

This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs). [STANDARDS-TRACK]

draft-ietf-mpls-ldp-upstream-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6389
RFC6390 Guidelines for Considering New Performance Metric Development A. Clark B. Claise October 2011 ASCII 49930 23

This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. These metrics can be used to characterize traffic on live networks and services. This memo documents an Internet Best Current Practice.

draft-ietf-pmol-metrics-framework-12 BCP0170 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops pmol 10.17487/RFC6390
RFC6391 Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network S. Bryant Editor C. Filsfils U. Drafz V. Kompella J. Regan S. Amante November 2011 ASCII 43848 19

Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.

This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. [STANDARDS-TRACK]

draft-ietf-pwe3-fat-pw-07 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6391
RFC6392 A Survey of In-Network Storage Systems R. Alimi Editor A. Rahman Editor Y. Yang Editor October 2011 ASCII 90978 44 P2P DECADE DECoupled Application Data Enroute

This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-decade-survey-06 INFORMATIONAL INFORMATIONAL IETF tsv decade http://www.rfc-editor.org/errata_search.php?rfc=6392 10.17487/RFC6392
RFC6393 Moving RFC 4693 to Historic M. Yevstifeyev September 2011 ASCII 4252 3 ION historic

This document moves RFC 4693 to Historic status. It also obsoletes RFC 4693. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-yevstifeyev-ion-report-07 RFC4693 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6393
RFC6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) R. Barnes October 2011 ASCII 29477 12 TLS PKIX

Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name. Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. [STANDARDS-TRACK]

draft-ietf-dane-use-cases-05 INFORMATIONAL INFORMATIONAL IETF sec dane 10.17487/RFC6394
RFC6395 An Interface Identifier (ID) Hello Option for PIM S. Gulrajani S. Venaas October 2011 ASCII 11469 6

This document defines a new PIM Hello option to advertise an Interface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. [STANDARDS-TRACK]

draft-ietf-pim-hello-intid-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6395
RFC6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format L. Blunk M. Karir C. Labovitz October 2011 ASCII 73982 33

This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. [STANDARDS-TRACK]

draft-ietf-grow-mrt-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=6396 10.17487/RFC6396
RFC6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions T. Manderson October 2011 ASCII 16864 8 GPS Coordinates Terrestrial Coordinates BGP Speaker BGP Peer BGP Latitude BGP Longitude

This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers. [STANDARDS-TRACK]

draft-ietf-grow-geomrt-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC6397
RFC6398 IP Router Alert Considerations and Usage F. Le Faucheur Editor October 2011 ASCII 44914 19

The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines for Router Alert implementation on routers. This memo documents an Internet Best Current Practice.

draft-ietf-intarea-router-alert-considerations-10 RFC2113 RFC2711 BCP0168 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6398
RFC6401 RSVP Extensions for Admission Priority F. Le Faucheur J. Polk K. Carlberg October 2011 ASCII 72343 32

Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer.

Based on current security concerns, these extensions are intended for use in a single administrative domain. [STANDARDS-TRACK]

draft-ietf-tsvwg-emergency-rsvp-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6401
RFC6402 Certificate Management over CMS (CMC) Updates J. Schaad November 2011 ASCII 66722 37 cyrptographic message syntax

This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274.

The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK]

draft-ietf-pkix-rfc5272-bis-08 RFC5272 RFC5273 RFC5274 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6402 10.17487/RFC6402
RFC6403 Suite B Profile of Certificate Management over CMS L. Zieglar S. Turner M. Peck November 2011 ASCII 36631 16 cmc suite b x.509 public key certificates

The United States government has published guidelines for "NSA Suite\0B Cryptography", which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-suiteb-cmc-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6403
RFC6404 Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures J. Seedorf S. Niccolini E. Chen H. Scholz November 2011 ASCII 54066 22 VoIP Security Threats multimedia Threat countermeasures SIP Interconnect VoIP peering Fraud prevention Network protection SIP RTP RTCP control plane user plane

The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs). The objective of this document is to identify and enumerate SPEERMINT- specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. Security requirements for SPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements. In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of a specific SIP Service Provider. Various instances of the threats are briefly introduced inside the classification. Finally, existing security solutions for SIP and RTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats. Each SSP may have connections to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-speermint-voipthreats-09 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6404
RFC6405 Voice over IP (VoIP) SIP Peering Use Cases A. Uzelac Editor Y. Lee Editor November 2011 ASCII 51354 23 VoIP SIP Peering

This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-speermint-voip-consolidated-usecases-18 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6405
RFC6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture D. Malas Editor J. Livingood Editor November 2011 ASCII 35032 16

This document defines a peering architecture for the Session Initiation Protocol (SIP) and its functional components and interfaces. It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-speermint-architecture-19 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6406
RFC6407 The Group Domain of Interpretation B. Weis S. Rowles T. Hardjono October 2011 ASCII 147102 64

This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. [STANDARDS-TRACK]

draft-ietf-msec-gdoi-update-11 RFC3547 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=6407 10.17487/RFC6407
RFC6408 Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage M. Jones J. Korhonen L. Morand November 2011 ASCII 32490 14 Services Field Peer Discovery

The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. [STANDARDS-TRACK]

draft-ietf-dime-extended-naptr-09 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6408
RFC6409 Message Submission for Mail R. Gellens J. Klensin November 2011 ASCII 40153 20 Text Internationalization ASCII Unicode UTF-8

This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.

Message relay is unaffected, and continues to use SMTP over port 25.

When conforming to this document, message submission uses the protocol specified here, normally over port 587.

This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]

draft-ietf-yam-rfc4409bis-03 RFC4409 STD0072 INTERNET STANDARD INTERNET STANDARD IETF app yam http://www.rfc-editor.org/errata_search.php?rfc=6409 10.17487/RFC6409
RFC6410 Reducing the Standards Track to Two Maturity Levels R. Housley D. Crocker E. Burger October 2011 ASCII 12619 6

This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.

draft-housley-two-maturity-levels-09 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6410 10.17487/RFC6410
RFC6411 Applicability of Keying Methods for RSVP Security M. Behringer F. Le Faucheur B. Weis October 2011 ASCII 46072 19 RSVP authentication RSVP integrity Resource reservation protocol GDOI Group domain of interpretation

The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tsvwg-rsvp-security-groupkeying-11 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC6411
RFC6412 Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence S. Poretsky B. Imhoff K. Michielsen November 2011 ASCII 51856 29

This document describes the terminology for benchmarking link-state Interior Gateway Protocol (IGP) route convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The terminology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-igp-dataplane-conv-term-23 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6412
RFC6413 Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence S. Poretsky B. Imhoff K. Michielsen November 2011 ASCII 90935 42 Interior Gateway Protocol

This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The methodology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-igp-dataplane-conv-meth-23 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6413
RFC6414 Benchmarking Terminology for Protection Performance S. Poretsky R. Papneja J. Karthik S. Vapiwala November 2011 ASCII 55563 33

This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-protection-term-09 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6414
RFC6415 Web Host Metadata E. Hammer-Lahav Editor B. Cook October 2011 ASCII 32018 16

This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. [STANDARDS-TRACK]

draft-hammer-hostmeta-17 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6415 10.17487/RFC6415
RFC6416 RTP Payload Format for MPEG-4 Audio/Visual Streams M. Schmidt F. de Bont S. Doehla J. Kim October 2011 ASCII 77031 35 RFC3016 RTP MPEG-4 Audio Visual Video AAC HE AAC HE AAC v2 MPEG Surround

This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision of RFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio.

For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification and to enable interoperable implementations. [STANDARDS-TRACK]

draft-ietf-payload-rfc3016bis-03 RFC3016 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6416
RFC6417 How to Contribute Research Results to Internet Standardization P. Eardley L. Eggert M. Bagnulo R. Winter November 2011 ASCII 33781 14

The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.

For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-weeb-research-to-internet-stds-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6417
RFC6418 Multiple Interfaces and Provisioning Domains Problem Statement M. Blanchet P. Seite November 2011 ASCII 50537 22 multi-homing MIF DNS DHCP

This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mif-problem-statement-15 INFORMATIONAL INFORMATIONAL IETF int mif http://www.rfc-editor.org/errata_search.php?rfc=6418 10.17487/RFC6418
RFC6419 Current Practices for Multiple-Interface Hosts M. Wasserman P. Seite November 2011 ASCII 51809 21 current practices multi-homing MIF

An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mif-current-practices-12 INFORMATIONAL INFORMATIONAL IETF int mif 10.17487/RFC6419
RFC6420 PIM Multi-Topology ID (MT-ID) Join Attribute Y. Cai H. Ou November 2011 ASCII 28310 13

This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. [STANDARDS-TRACK]

draft-ietf-pim-mtid-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6420
RFC6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) D. Nelson Editor November 2011 ASCII 27028 12

This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-radext-crypto-agility-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops radext 10.17487/RFC6421
RFC6422 Relay-Supplied DHCP Options T. Lemon Q. Wu December 2011 ASCII 16056 8 DHCPv6 Relay DHCPv6 option

DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.

This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-relay-supplied-options-09 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6422
RFC6423 Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) H. Li L. Martini J. He F. Huang November 2011 ASCII 9343 5

This document describes the requirements for using the Generic Associated Channel Label (GAL) in pseudowires (PWs) in MPLS Transport Profile (MPLS-TP) networks, and provides an update to the description of GAL usage in RFC 5586 by removing the restriction that is imposed on using GAL for PWs, especially in MPLS-TP environments. [STANDARDS-TRACK]

draft-ietf-pwe3-mpls-tp-gal-in-pw-01 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6423
RFC6424 Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels N. Bahadur K. Kompella G. Swallow November 2011 ASCII 48270 23 MPLS OAM lsp ping LSP-Ping

This document describes methods for performing LSP ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS Label Switched Paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a new TLV that, along with other procedures outlined in this document, can be used to trace such LSPs. [STANDARDS-TRACK]

draft-ietf-mpls-lsp-ping-enhanced-dsmap-11 RFC4379 RFC7537 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6424
RFC6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping S. Saxena Editor G. Swallow Z. Ali A. Farrel S. Yasukawa T. Nadeau November 2011 ASCII 68437 28 p2mp

Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs.

The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".

The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.

This document updates RFC 4379. [STANDARDS-TRACK]

draft-ietf-mpls-p2mp-lsp-ping-18 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6425 10.17487/RFC6425
RFC6426 MPLS On-Demand Connectivity Verification and Route Tracing E. Gray N. Bahadur S. Boutros R. Aggarwal November 2011 ASCII 46539 22 lsp ping mpls tp mpls-tp

Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLS Transport Profile (MPLS-TP) LSPs and pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions in MPLS-TP networks. Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry. [STANDARDS-TRACK]

draft-ietf-mpls-tp-on-demand-cv-07 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6426 10.17487/RFC6426
RFC6427 MPLS Fault Management Operations, Administration, and Maintenance (OAM) G. Swallow Editor A. Fulignoli Editor M. Vigoureux Editor S. Boutros D. Ward November 2011 ASCII 34069 17 mpls-oam

This document specifies Operations, Administration, and Maintenance (OAM) messages to indicate service disruptive conditions for MPLS-based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. [STANDARDS-TRACK]

draft-ietf-mpls-tp-fault-07 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6427
RFC6428 Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile D. Allan Editor G. Swallow Ed. J. Drake Ed. November 2011 ASCII 44293 21 mpls-tp oam Operations Administration and Maintenance bfd bidirectional forwarding dectection

Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM).

Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section.

This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. [STANDARDS-TRACK]

draft-ietf-mpls-tp-cc-cv-rdi-06 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6428 10.17487/RFC6428
RFC6429 TCP Sender Clarification for Persist Condition M. Bashyam M. Jethanandani A. Ramaiah December 2011 ASCII 14280 7 zero window probe denial of service (DoS) security vulnerability

This document clarifies the Zero Window Probes (ZWPs) described in RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tcpm-persist-07 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6429
RFC6430 Email Feedback Report Type Value: not-spam K. Li B. Leiba November 2011 ASCII 12678 7 arf abuse reporting format

This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an email message that was mistakenly marked as spam. [STANDARDS-TRACK]

draft-ietf-marf-not-spam-feedback-03 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6430
RFC6431 Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP) M. Boucadair P. Levis G. Bajko T. Savolainen T. Tsou November 2011 ASCII 33981 16 IPv4 Address Exhaustion IPv4 service continuity IPv6 A+P

This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-boucadair-pppext-portrange-option-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6431
RFC6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses R. Jesske L. Liess November 2011 ASCII 7487 4 cause code

Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code. Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems. This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses. [STANDARDS-TRACK]

draft-jesske-dispatch-update3326-reason-responses-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6432
RFC6433 Requirements for a Working Group Milestones Tool P. Hoffman November 2011 ASCII 15423 7 working group charter charter

The IETF intends to provide a new tool to Working Group chairs and Area Directors for the creation and updating of milestones for Working Group charters. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document updates RFC 6292. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-genarea-milestones-tool-06 RFC6292 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6433
RFC6434 IPv6 Node Requirements E. Jankiewicz J. Loughney T. Narten December 2011 ASCII 64407 30 Internet Protocol Version 6 Internet Protocol IP

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6man-node-req-bis-11 RFC4294 INFORMATIONAL INFORMATIONAL IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6434 10.17487/RFC6434
RFC6435 MPLS Transport Profile Lock Instruct and Loopback Functions S. Boutros Editor S. Sivabalan Editor R. Aggarwal Editor M. Vigoureux Editor X. Dai Editor November 2011 ASCII 23862 12 oam operations administration and maintenance

Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.

This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.

This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. [STANDARDS-TRACK]

draft-ietf-mpls-tp-li-lb-08 RFC6371 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6435 10.17487/RFC6435
RFC6436 Rationale for Update to the IPv6 Flow Label Specification S. Amante B. Carpenter S. Jiang November 2011 ASCII 28062 13 ECMP LAG

Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6man-flow-update-07 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC6436
RFC6437 IPv6 Flow Label Specification S. Amante B. Carpenter S. Jiang J. Rajahalme November 2011 ASCII 35269 15

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.

The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]

draft-ietf-6man-flow-3697bis-07 RFC3697 RFC2205 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6437
RFC6438 Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels B. Carpenter S. Amante November 2011 ASCII 20999 9 ECMP LAG

The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. [STANDARDS-TRACK]

draft-ietf-6man-flow-ecmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6438
RFC6439 Routing Bridges (RBridges): Appointed Forwarders R. Perlman D. Eastlake Y. Li A. Banerjee F. Hu November 2011 ASCII 36978 15 trill TRansparent Interconnection of Lots of Links

The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called "Appointed Forwarders", with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. [STANDARDS-TRACK]

draft-ietf-trill-rbridge-af-05 RFC6325 RFC7180 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6439
RFC6440 The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option G. Zorn Q. Wu Y. Wang December 2011 ASCII 10158 6 re-authentication handover LDN Discovery

In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached.

This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. [STANDARDS-TRACK]

draft-ietf-hokey-ldn-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6440
RFC6441 Time to Remove Filters for Previously Unallocated IPv4 /8s L. Vegoda November 2011 ASCII 8646 5 bogons IPv4 martians filters

It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile, and expensive. Network administrators are advised to remove filters based on the registration status of the address space.

This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. This memo documents an Internet Best Current Practice.

draft-ietf-grow-no-more-unallocated-slash8s-04 BCP0171 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC6441
RFC6442 Location Conveyance for the Session Initiation Protocol J. Polk B. Rosen J. Peterson December 2011 ASCII 80795 35 sip geographic location location target

This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK]

draft-ietf-sipcore-location-conveyance-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6442 10.17487/RFC6442
RFC6443 Framework for Emergency Calling Using Internet Multimedia B. Rosen H. Schulzrinne J. Polk A. Newton December 2011 ASCII 98096 38

The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ecrit-framework-13 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC6443
RFC6444 Location Hiding: Problem Statement and Requirements H. Schulzrinne L. Liess H. Tschofenig B. Stark A. Kuett January 2012 ASCII 18495 9 emergency call privacy PSAP Location by Reference

The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned.

This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ecrit-location-hiding-req-04 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC6444
RFC6445 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute T. Nadeau Editor A. Koushik Editor R. Cetin Editor November 2011 ASCII 101627 53 mib frr MPLS-FRR-GENERAL-STD-MIB MPLS-FRR-ONE2ONE-STD-MIB MPLS-FRR-FACILITY-STD-MIB

This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE). The two methods are the one-to-one backup method and the facility backup method. [STANDARDS-TRACK]

draft-ietf-mpls-fastreroute-mib-21 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6445
RFC6446 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control A. Niemi K. Kiss S. Loreto January 2012 ASCII 57971 25 SIP events rate control

This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. [STANDARDS-TRACK]

draft-ietf-sipcore-event-rate-control-09 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6446
RFC6447 Filtering Location Notifications in the Session Initiation Protocol (SIP) R. Mahy B. Rosen H. Tschofenig January 2012 ASCII 36577 19 geopriv location

This document describes filters that limit asynchronous location notifications to compelling events. These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). [STANDARDS-TRACK]

draft-ietf-geopriv-loc-filters-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6447
RFC6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message R. Yount November 2011 ASCII 8369 4 credential

The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications. When used with a secure transport, the unencrypted form of the KRB-CRED message may be desirable. This document describes the unencrypted form of the KRB-CRED message. [STANDARDS-TRACK]

draft-ietf-krb-wg-clear-text-cred-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6448
RFC6449 Complaint Feedback Loop Operational Recommendations J. Falk Editor November 2011 ASCII 75139 31 MAAWG ARF MARF feedback loop spam reporting

Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.

This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-jdfalk-maawg-cfblbcp-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6449
RFC6450 Multicast Ping Protocol S. Venaas December 2011 ASCII 59420 24 ssm asm ssmping asmping

The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping". [STANDARDS-TRACK]

draft-ietf-mboned-ssmping-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC6450
RFC6451 Location-to-Service Translation (LoST) Protocol Extensions A. Forte H. Schulzrinne December 2011 ASCII 45682 23 location-based services location GPS point of interest

An important class of location-based services answers the question, "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by". This document defines an Experimental Protocol for the Internet community.

draft-forte-lost-extensions-08 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6451
RFC6452 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 P. Faltstrom Editor P. Hoffman Editor November 2011 ASCII 6817 4 DNS IDN

This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. [STANDARDS-TRACK]

draft-faltstrom-5892bis-05 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6452
RFC6453 A URN Namespace for the Open Grid Forum (OGF) F. Dijkstra R. Hughes-Jones December 2011 ASCII 16678 9 identifier

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-dijkstra-urn-ogf-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6453
RFC6454 The Web Origin Concept A. Barth December 2011 ASCII 41363 20 same-origin policy security cross-origin

This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]

draft-ietf-websec-origin-06 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=6454 10.17487/RFC6454
RFC6455 The WebSocket Protocol I. Fette A. Melnikov December 2011 ASCII 162067 71 HyBi Working Group HYBI websocket

The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK]

draft-ietf-hybi-thewebsocketprotocol-17 PROPOSED STANDARD PROPOSED STANDARD IETF app hybi http://www.rfc-editor.org/errata_search.php?rfc=6455 10.17487/RFC6455
RFC6456 Multi-Segment Pseudowires in Passive Optical Networks H. Li R. Zheng A. Farrel November 2011 ASCII 27499 12 MPLS PSN PON G-PON XG-PON OMCI

This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising a Passive Optical Network (PON) and an MPLS Packet Switched Network (PSN).

PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) Terminating Provider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager.

This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or 10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network Termination Management and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration.

This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-li-pwe3-ms-pw-pon-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6456
RFC6457 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering T. Takeda Editor A. Farrel December 2011 ASCII 29107 12 PCEP inter-layer traffic engineering MPLS GMPLS VNT

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS).

MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements.

Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element (PCE) Discovery".

This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pce-inter-layer-req-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6457
RFC6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) R. Stewart M. Tuexen K. Poon P. Lei V. Yasevich December 2011 ASCII 237112 115

This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tsvwg-sctpsocket-32 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC6458
RFC6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) J. Korhonen Editor J. Soininen B. Patil T. Savolainen G. Bajko K. Iisakkila January 2012 ASCII 84769 36 Transition Migration

The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-3gpp-eps-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6459
RFC6460 Suite B Profile for Transport Layer Security (TLS) M. Salter R. Housley January 2012 ASCII 31428 14 cryptographic algorithm policy

The United States government has published guidelines for "NSA Suite B Cryptography" that define cryptographic algorithm policy for national security applications. This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully compliant with Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-salter-rfc5430bis-01 RFC5430 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6460 10.17487/RFC6460
RFC6461 Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements S. Channabasappa Editor January 2012 ASCII 36435 15 registry registry provisioning registrar destination group route group

This document captures the use cases and associated requirements for interfaces that provision session establishment data into Session Initiation Protocol (SIP) Service Provider components to assist with session routing. Specifically, this document focuses on the provisioning of one such element termed the "registry". This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-drinks-usecases-requirements-06 INFORMATIONAL INFORMATIONAL IETF rai drinks 10.17487/RFC6461
RFC6462 Report from the Internet Privacy Workshop A. Cooper January 2012 ASCII 55638 23

On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society (ISOC), and MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protective Internet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps. For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-privacy-workshop-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6462
RFC6463 Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 J. Korhonen Editor S. Gundavelli H. Yokota X. Cui February 2012 ASCII 50702 22

This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6. The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes. [STANDARDS-TRACK]

draft-ietf-netext-redirect-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6463
RFC6464 A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication J. Lennox Editor E. Ivov E. Marocco December 2011 ASCII 18809 9 ssrc-audio-level ssrc speech sound energy conference bridge

This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. [STANDARDS-TRACK]

draft-ietf-avtext-client-to-mixer-audio-level-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6464
RFC6465 A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication E. Ivov Editor E. Marocco Editor J. Lennox December 2011 ASCII 30154 15 csrc-audio-level csrc speech sound energy conference bridge

This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. [STANDARDS-TRACK]

draft-ietf-avtext-mixer-to-client-audio-level-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6465
RFC6466 IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) G. Salgueiro December 2011 ASCII 11660 6 t.38 media

This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the Session Description Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams. [STANDARDS-TRACK]

draft-salgueiro-mmusic-image-iana-registration-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6466
RFC6467 Secure Password Framework for Internet Key Exchange Version 2 (IKEv2) T. Kivinen December 2011 ASCII 21987 10 IPsec IKE mutual authentication credentials VPN gateway

This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods.

draft-kivinen-ipsecme-secure-password-framework-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6467
RFC6468 Sieve Notification Mechanism: SIP MESSAGE A. Melnikov B. Leiba K. Li February 2012 ASCII 21331 10 Sieve SIP notification

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. [STANDARDS-TRACK]

draft-ietf-sieve-notify-sip-message-08 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6468
RFC6469 RTP Payload Format for DV (IEC 61834) Video K. Kobayashi K. Mishima S. Casner C. Bormann December 2011 ASCII 38041 18 DV/RTP real-time transport protocol

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. [STANDARDS-TRACK]

draft-ietf-payload-rfc3189bis-03 RFC3189 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6469
RFC6470 Network Configuration Protocol (NETCONF) Base Notifications A. Bierman February 2012 ASCII 26361 15 XML

The Network Configuration Protocol (NETCONF) provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events, such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. [STANDARDS-TRACK]

draft-ietf-netconf-system-notifications-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6470 10.17487/RFC6470
RFC6471 Overview of Best Email DNS-Based List (DNSBL) Operational Practices C. Lewis M. Sergeant January 2012 ASCII 49264 21 DNSBL policy

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering. This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-asrg-bcp-blacklists-10 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6471
RFC6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP W. Kumari K. Sriram December 2011 ASCII 10673 5 BGPv4 Operator RPKI Aggregation Route Origin

This document recommends against the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. This memo documents an Internet Best Current Practice.

draft-ietf-idr-deprecate-as-sets-06 BCP0172 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC6472
RFC6473 vCard KIND:application P. Saint-Andre December 2011 ASCII 9776 5 vCard

This document defines a value of "application" for the vCard KIND property so that vCards can be used to represent software applications. [STANDARDS-TRACK]

draft-ietf-vcarddav-kind-app-00 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC6473
RFC6474 vCard Format Extensions: Place of Birth, Place and Date of Death K. Li B. Leiba December 2011 ASCII 8884 6 contacts address-book personal-information

The base vCard 4.0 specification defines a large number of properties, including date of birth. This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death. [STANDARDS-TRACK]

draft-ietf-vcarddav-birth-death-extensions-02 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC6474
RFC6475 Proxy Mobile IPv6 Management Information Base G. Keeni K. Koide S. Gundavelli R. Wakikawa May 2012 ASCII 132402 63

This memo defines a portion of the Proxy Mobile IPv6 Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, the Proxy Mobile IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. [STANDARDS-TRACK]

draft-ietf-netlmm-pmipv6-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6475 10.17487/RFC6475
RFC6476 Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS) P. Gutmann January 2012 ASCII 33186 15 authenticated data

This document specifies the conventions for using Message Authentication Code (MAC) encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security (SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community. [STANDARDS-TRACK]

draft-gutmann-cms-hmac-enc-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6476 10.17487/RFC6476
RFC6477 Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail A. Melnikov G. Lunt January 2012 ASCII 43492 21

A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 and ACP 123. This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-melnikov-mmhs-header-fields-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6477
RFC6478 Pseudowire Status for Static Pseudowires L. Martini G. Swallow G. Heron M. Bocci May 2012 ASCII 28285 13

This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE. The mechanism allows PW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs. This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection (BFD) is used to convey PW status-signaling information. [STANDARDS-TRACK]

draft-ietf-pwe3-static-pw-status-10 RFC5885 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6478
RFC6479 IPsec Anti-Replay Algorithm without Bit Shifting X. Zhang T. Tsou January 2012 ASCII 16619 9

This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zhang-ipsecme-anti-replay-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6479
RFC6480 An Infrastructure to Support Secure Internet Routing M. Lepinski S. Kent February 2012 ASCII 62127 24 RPKI BGP ROA

This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sidr-arch-13 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6480
RFC6481 A Profile for Resource Certificate Repository Structure G. Huston R. Loomans G. Michaelson February 2012 ASCII 36117 15 rpki Resource Public Key Infrastructure

This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]

draft-ietf-sidr-repos-struct-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6481
RFC6482 A Profile for Route Origin Authorizations (ROAs) M. Lepinski S. Kent D. Kong February 2012 ASCII 15745 9 RPKI BGP

This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK]

draft-ietf-sidr-roa-format-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6482 10.17487/RFC6482
RFC6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) G. Huston G. Michaelson February 2012 ASCII 19811 8 rpki bgp Resource Public Key Infrastructure

This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sidr-roa-validation-10 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6483
RFC6484 Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) S. Kent D. Kong K. Seo R. Watro February 2012 ASCII 77855 35 Certification Practice Statement CPS

This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet Number Resource (INR) holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources. This memo documents an Internet Best Current Practice.

draft-ietf-sidr-cp-17 BCP0173 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC6484
RFC6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) G. Huston February 2012 ASCII 11377 6

This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. [STANDARDS-TRACK]

draft-ietf-sidr-rpki-algs-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6485 10.17487/RFC6485
RFC6486 Manifests for the Resource Public Key Infrastructure (RPKI) R. Austein G. Huston S. Kent M. Lepinski February 2012 ASCII 42913 19

This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. [STANDARDS-TRACK]

draft-ietf-sidr-rpki-manifests-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6486
RFC6487 A Profile for X.509 PKIX Resource Certificates G. Huston G. Michaelson R. Loomans February 2012 ASCII 69150 32 rpki Resource Public Key Infrastructure Internet Number Resources INR

This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]

draft-ietf-sidr-res-certs-22 RFC7318 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6487 10.17487/RFC6487
RFC6488 Signed Object Template for the Resource Public Key Infrastructure (RPKI) M. Lepinski A. Chi S. Kent February 2012 ASCII 25130 13 ROA manifest GhostBusters

This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]

draft-ietf-sidr-signed-object-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6488 10.17487/RFC6488
RFC6489 Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) G. Huston G. Michaelson S. Kent February 2012 ASCII 23060 10 RPKI

This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. This memo documents an Internet Best Current Practice.

draft-ietf-sidr-keyroll-08 BCP0174 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6489 10.17487/RFC6489
RFC6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent February 2012 ASCII 15004 7 tal

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). [STANDARDS-TRACK]

draft-ietf-sidr-ta-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6490
RFC6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA T. Manderson L. Vegoda S. Kent February 2012 ASCII 23662 12 sidr rpki iana as0 as 0 roa

This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. [STANDARDS-TRACK]

draft-ietf-sidr-iana-objects-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6491
RFC6492 A Protocol for Provisioning Resource Certificates G. Huston R. Loomans B. Ellacott R. Austein February 2012 ASCII 65896 32 RPKI

This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. [STANDARDS-TRACK]

draft-ietf-sidr-rescerts-provisioning-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6492
RFC6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record R. Bush February 2012 ASCII 15491 8 RPKI Resource Certificate Human Contact vCard

In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK]

draft-ietf-sidr-ghostbusters-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6493 10.17487/RFC6493
RFC6494 Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) R. Gagliano S. Krishnan A. Kukec February 2012 ASCII 26425 12 RPKI ND

SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND. [STANDARDS-TRACK]

draft-ietf-csi-send-cert-10 RFC3971 PROPOSED STANDARD PROPOSED STANDARD IETF int csi http://www.rfc-editor.org/errata_search.php?rfc=6494 10.17487/RFC6494
RFC6495 Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields R. Gagliano S. Krishnan A. Kukec February 2012 ASCII 10575 5

SEcure Neighbor Discovery (SEND) defines the Name Type field in the ICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs). [STANDARDS-TRACK]

draft-ietf-csi-send-name-type-registry-06 RFC3971 PROPOSED STANDARD PROPOSED STANDARD IETF int csi 10.17487/RFC6495
RFC6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) S. Krishnan J. Laganier M. Bonola A. Garcia-Martinez February 2012 ASCII 57746 24 SPND CGA Mobile IPv6 MIPv6 Proxy Mobile IPv6 PMIPv6

SEcure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation. This document defines an Experimental Protocol for the Internet community.

draft-ietf-csi-proxy-send-05 EXPERIMENTAL EXPERIMENTAL IETF int csi 10.17487/RFC6496
RFC6497 BCP 47 Extension T - Transformed Content M. Davis A. Phillips Y. Umaoka C. Falk February 2012 ASCII 32915 15 locale

This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It also provides for additional information used for identification. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-davis-t-langtag-ext-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6497 10.17487/RFC6497
RFC6498 Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package J. Stone R. Kumar F. Andreasen February 2012 ASCII 92301 47

This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to defining these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy, and FEC. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-stone-mgcp-vbd-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6498
RFC6501 Conference Information Data Model for Centralized Conferencing (XCON) O. Novo G. Camarillo D. Morgan J. Urpalainen March 2012 ASCII 180210 94

RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an XML- based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) event package for conference State. [STANDARDS-TRACK]

draft-ietf-xcon-common-data-model-32 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC6501
RFC6502 Conference Event Package Data Format Extension for Centralized Conferencing (XCON) G. Camarillo S. Srinivasan R. Even J. Urpalainen March 2012 ASCII 26245 14

This document specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. [STANDARDS-TRACK]

draft-ietf-xcon-event-package-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC6502
RFC6503 Centralized Conferencing Manipulation Protocol M. Barnes C. Boulton S. Romano H. Schulzrinne March 2012 ASCII 257058 119 conference user ad hoc conference sidebar conference scheduled conference

The Centralized Conferencing Manipulation Protocol (CCMP) allows a Centralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference. CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. [STANDARDS-TRACK]

draft-ietf-xcon-ccmp-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon http://www.rfc-editor.org/errata_search.php?rfc=6503 10.17487/RFC6503
RFC6504 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples M. Barnes L. Miniero R. Presta S P. Romano March 2012 ASCII 186366 78

This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503). The objective is to provide detailed examples for reference by both protocol researchers and developers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-xcon-examples-10 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC6504
RFC6505 A Mixer Control Package for the Media Control Channel Framework S. McGlashan T. Melanchuk C. Boulton March 2012 ASCII 187038 89 conference mixer

This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers [STANDARDS-TRACK]

draft-ietf-mediactrl-mixer-control-package-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=6505 10.17487/RFC6505
RFC6506 Supporting Authentication Trailer for OSPFv3 M. Bhatia V. Manral A. Lindem February 2012 ASCII 41992 20 Routing security

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. [STANDARDS-TRACK]

draft-ietf-ospf-auth-trailer-ospfv3-11 RFC7166 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6506 10.17487/RFC6506
RFC6507 Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) M. Groves February 2012 ASCII 36233 17

Many signature schemes currently in use rely on certificates for authentication of identity. In Identity-based cryptography, this adds unnecessary overhead and administration. The Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) signature scheme described in this document is certificateless. This scheme has the additional advantages of low bandwidth and low computational requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-groves-eccsi-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6507
RFC6508 Sakai-Kasahara Key Encryption (SAKKE) M. Groves February 2012 ASCII 42700 21

In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described. This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-groves-sakke-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6508
RFC6509 MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY) M. Groves February 2012 ASCII 47389 21

This document describes the Multimedia Internet KEYing-Sakai-Kasahara Key Encryption (MIKEY-SAKKE), a method of key exchange that uses Identity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication. MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-groves-mikey-sakke-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6509
RFC6510 Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects L. Berger G. Swallow February 2012 ASCII 16650 8

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP-specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420. [STANDARDS-TRACK]

draft-ietf-ccamp-attribute-bnf-02 RFC4875 RFC5420 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6510
RFC6511 Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths Z. Ali G. Swallow R. Aggarwal February 2012 ASCII 21767 10

There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6511
RFC6512 Using Multipoint LDP When the Backbone Has No Route to the Root IJ. Wijnands E. Rosen M. Napierala N. Leymann February 2012 ASCII 24352 12

The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of a BGP-free core. This document specifies procedures that enable an MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. [STANDARDS-TRACK]

draft-ietf-mpls-mldp-recurs-fec-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6512
RFC6513 Multicast in MPLS/BGP IP VPNs E. Rosen Editor R. Aggarwal Editor February 2012 ASCII 213780 88

In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]

draft-ietf-l3vpn-2547bis-mcast-10 RFC7582 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6513 10.17487/RFC6513
RFC6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs R. Aggarwal E. Rosen T. Morin Y. Rekhter February 2012 ASCII 145112 59

This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]

draft-ietf-l3vpn-2547bis-mcast-bgp-08 RFC6515 RFC6625 RFC7385 RFC7441 RFC7582 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6514 10.17487/RFC6514
RFC6515 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN R. Aggarwal E. Rosen February 2012 ASCII 17550 8 mvpn mcast-vpn multicast-vpn

To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN-specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates RFC 6514. [STANDARDS-TRACK]

draft-ietf-l3vpn-mvpn-infra-addrs-05 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6515
RFC6516 IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages Y. Cai E. Rosen Editor I. Wijnands February 2012 ASCII 11992 6

The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as Selective Provider Multicast Service Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows. [STANDARDS-TRACK]

draft-ietf-l3vpn-mvpn-spmsi-joins-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6516
RFC6517 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution T. Morin Editor B. Niven-Jenkins Editor Y. Kamite R. Zhang N. Leymann N. Bitar February 2012 ASCII 102395 41 mpls vpn multicast l3vpn bgp pim p2mp ldp rsvp-te

More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.

To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-l3vpn-mvpn-considerations-06 INFORMATIONAL INFORMATIONAL IETF rtg l3vpn 10.17487/RFC6517
RFC6518 Keying and Authentication for Routing Protocols (KARP) Design Guidelines G. Lebovitz M. Bhatia February 2012 ASCII 76782 30 MAC hash security securing secure authorization protection harden hardening infrastructure router crypto cryptography cryptographic roadmap guide guideline message framework key keys management protocol KMP key management protocol,

This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-karp-design-guide-10 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6518
RFC6519 RADIUS Extensions for Dual-Stack Lite R. Maglione A. Durand February 2012 ASCII 22574 11 IPv6 tunnel attribute

Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. [STANDARDS-TRACK]

draft-ietf-softwire-dslite-radius-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6519 10.17487/RFC6519
RFC6520 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension R. Seggelmann M. Tuexen M. Williams February 2012 ASCII 16858 9 tls/dtls

This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK]

draft-ietf-tls-dtls-heartbeat-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC6520
RFC6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks A. Makela J. Korhonen February 2012 ASCII 123256 53 mobile router mobile network prefix correspondent router

This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mip4-nemo-haaro-07 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC6521
RFC6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages M. Kucherawy Editor January 2012 ASCII 15715 9 MIME Multipurpose Internet Mail Extensions

The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.

This memo obsoletes "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". [STANDARDS-TRACK]

draft-ietf-appsawg-rfc3462bis-04 RFC3462 RFC6533 STD0073 INTERNET STANDARD INTERNET STANDARD IETF app appsawg 10.17487/RFC6522
RFC6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration R. Stewart M. Tuexen P. Lei February 2012 ASCII 72734 34

Many applications that use the Stream Control Transmission Protocol (SCTP) want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers. [STANDARDS-TRACK]

draft-ietf-tsvwg-sctp-strrst-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6525
RFC6526 IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream B. Claise P. Aitken A. Johnson G. Muenz March 2012 ASCII 51285 23

This document specifies an extension to the specifications in RFC 5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol).

When implemented at both the Exporting Process and Collecting Process, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits. [STANDARDS-TRACK]

draft-ietf-ipfix-export-per-sctp-stream-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6526
RFC6527 Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3) K. Tata March 2012 ASCII 62639 31 management information base

This specification defines a portion of the Management Information Base (MIB) for use with network management based on the Simple Network Management Protocol (SNMP). In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC 2787. [STANDARDS-TRACK]

draft-ietf-vrrp-unified-mib-10 RFC2787 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6527 10.17487/RFC6527
RFC6528 Defending against Sequence Number Attacks F. Gont S. Bellovin February 2012 ASCII 26917 12 TCP security TCP Sequence Numbers Sequence Number Randomization obfuscation TCP vulnerabilities

This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK]

draft-ietf-tcpm-rfc1948bis-02 RFC1948 RFC0793 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6528
RFC6529 Host/Host Protocol for the ARPA Network A. McKenzie S. Crocker April 2012 ASCII 69527 34

This document reproduces the Host/Host Protocol developed by the ARPA Network Working Group during 1969, 1970, and 1971. It describes a protocol used to manage communication between processes residing on independent Hosts. It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface. It was the official protocol of the ARPA Network from January 1972 until the switch to TCP/IP in January 1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series. This document is not an Internet Standards Track specification; it is published for the historical record.

draft-mckenzie-arpanet-host-host-protocol-01 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6529
RFC6530 Overview and Framework for Internationalized Email J. Klensin Y. Ko February 2012 ASCII 64371 26 SMTP Email I18n Internationalization SMTPUTF8

Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK]

draft-ietf-eai-frmwrk-4952bis-12 RFC4952 RFC5504 RFC5825 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6530
RFC6531 SMTP Extension for Internationalized Email J. Yao W. Mao February 2012 ASCII 40977 18 SMTP Email I18n Internationalization SMTPUTF8

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK]

draft-ietf-eai-rfc5336bis-16 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6531
RFC6532 Internationalized Email Headers A. Yang S. Steele N. Freed February 2012 ASCII 22725 11

Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.

This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK]

draft-ietf-eai-rfc5335bis-13 RFC5335 RFC2045 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6532 10.17487/RFC6532
RFC6533 Internationalized Delivery Status and Disposition Notifications T. Hansen Editor C. Newman A. Melnikov February 2012 ASCII 37990 19 dsn

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.

This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK]

draft-ietf-eai-rfc5337bis-dsn-06 RFC5337 RFC3461 RFC3464 RFC3798 RFC6522 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6533
RFC6534 Loss Episode Metrics for IP Performance Metrics (IPPM) N. Duffield A. Morton J. Sommers May 2012 ASCII 45147 21

The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts. However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. [STANDARDS-TRACK]

draft-ietf-ippm-loss-episode-metrics-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6534
RFC6535 Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) B. Huang H. Deng T. Savolainen February 2012 ASCII 54452 25 NAT NAT46 DNS DNS46 translation IPv4 applications IPv6 ENR

Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 and RFC 3338. [STANDARDS-TRACK]

draft-ietf-behave-v4v6-bih-09 RFC2767 RFC3338 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6535 10.17487/RFC6535
RFC6536 Network Configuration Protocol (NETCONF) Access Control Model A. Bierman M. Bjorklund March 2012 ASCII 90803 49 NETCONF YANG XML

The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK]

draft-ietf-netconf-access-control-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6536 10.17487/RFC6536
RFC6537 Host Identity Protocol Distributed Hash Table Interface J. Ahrenholz February 2012 ASCII 49467 20 HIP Host Identity Protocol DHT DIstributed Hash Table HIT Host Identity Tag resolution service

This document specifies a common interface for using the Host Identity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host- Identity-Tag-to-address lookup service. This document defines an Experimental Protocol for the Internet community.

draft-irtf-hiprg-dht-05 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6537
RFC6538 The Host Identity Protocol (HIP) Experiment Report T. Henderson A. Gurtov March 2012 ASCII 88376 35 Security ID/locator split IPsec Research

This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-hip-experiment-15 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6538
RFC6539 IBAKE: Identity-Based Authenticated Key Exchange V. Cakulev G. Sundaram I. Broustis March 2012 ASCII 28913 13 ibe identity based encryption

Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management. The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cakulev-ibake-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6539
RFC6540 IPv6 Support Required for All IP-Capable Nodes W. George C. Donley C. Liljenstolpe L. Howard April 2012 ASCII 12883 6 IPv4 requirement

Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application. This memo documents an Internet Best Current Practice.

draft-ietf-intarea-ipv6-required-02 BCP0177 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6540
RFC6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures M. Kucherawy February 2012 ASCII 31655 16 Authentication Reputation

This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. This document defines an Experimental Protocol for the Internet community.

draft-kucherawy-dkim-atps-16 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6541
RFC6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility S. Emery March 2012 ASCII 11080 6

Currently, channel bindings are implemented using an MD5 hash in the Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism (RFC 4121). This document updates RFC 4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. [STANDARDS-TRACK]

draft-ietf-krb-wg-gss-cb-hash-agility-10 RFC4121 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6542
RFC6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6 S. Gundavelli May 2012 ASCII 10565 5

Proxy Mobile IPv6 (RFC 5213) requires that all mobile access gateways use a fixed link-local address and a fixed link-layer address on any of their access links that they share with mobile nodes. This requirement was intended to ensure that a mobile node does not detect any change with respect to its Layer 3 attachment, even after it roams from one mobile access gateway to another. In the absence of any reserved addresses for this use, coordination across vendors and manual configuration of these addresses on all of the mobility elements in a Proxy Mobile IPv6 domain are required. This document attempts to simplify this operational requirement by making a reservation for special addresses that can be used for this purpose. This document also updates RFC 5213. [STANDARDS-TRACK]

draft-gundavelli-v6ops-pmipv6-address-reservations-06 RFC5213 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6543
RFC6544 TCP Candidates with Interactive Connectivity Establishment (ICE) J. Rosenberg A. Keranen B. B. Lowekamp A. B. Roach March 2012 ASCII 72318 29 ICE TCP NAT NAT traversal

Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. [STANDARDS-TRACK]

draft-ietf-mmusic-ice-tcp-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=6544 10.17487/RFC6544
RFC6545 Real-time Inter-network Defense (RID) K. Moriarty April 2012 ASCII 203100 84 incident response incident coordination incident handling incident communication

Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC 6045. [STANDARDS-TRACK]

draft-ietf-mile-rfc6045-bis-11 RFC6045 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=6545 10.17487/RFC6545
RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS B. Trammell April 2012 ASCII 19114 8 Coordinated Incident Response CSIRT Incident Object Description Exchange Format IODEF

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. [STANDARDS-TRACK]

draft-ietf-mile-rfc6046-bis-09 RFC6046 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=6546 10.17487/RFC6546
RFC6547 RFC 3627 to Historic Status W. George February 2012 ASCII 4917 3 IPv6 /127 point-to-point address inter-router links

This document moves "Use of /127 Prefix Length Between Routers Considered Harmful" (RFC 3627) to Historic status to reflect the updated guidance contained in "Using 127-Bit IPv6 Prefixes on Inter- Router Links" (RFC 6164). A Standards Track document supersedes an informational document; therefore, guidance provided in RFC 6164 is to be followed when the two documents are in conflict. This document links the two RFCs so that the IETF's updated guidance on this topic is clearer. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6man-3627-historic-01 RFC3627 RFC6164 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC6547
RFC6548 Independent Submission Editor Model N. Brownlee Editor IAB June 2012 ASCII 9298 5 Independent Stream Editor

This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administrative Oversight Committee (IAOC). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-ise-model-07 RFC5620 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6548
RFC6549 OSPFv2 Multi-Instance Extensions A. Lindem A. Roy S. Mirtorabi March 2012 ASCII 16639 9 Instance ID

OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet.

This document defines the OSPFv2 Instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances.

This document updates RFC 2328. [STANDARDS-TRACK]

draft-ietf-ospf-multi-instance-09 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6549 10.17487/RFC6549
RFC6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks T. Winter Editor P. Thubert Editor A. Brandt J. Hui R. Kelsey P. Levis K. Pister R. Struik JP. Vasseur R. Alexander March 2012 ASCII 360651 157 WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing Distance Vector Objective Function DAG for Directed Acyclic Graph

Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]

draft-ietf-roll-rpl-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6550 10.17487/RFC6550
RFC6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks JP. Vasseur Editor M. Kim Editor K. Pister N. Dejean D. Barthel March 2012 ASCII 67707 30 RPL ROLL LLN Constrained based routing,

Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]

draft-ietf-roll-routing-metrics-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6551 10.17487/RFC6551
RFC6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) P. Thubert Editor March 2012 ASCII 30419 14 WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing Distance Vector Objective Function DAG for Directed Acyclic Graph RPL

The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.

This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]

draft-ietf-roll-of0-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC6552
RFC6553 The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams J. Hui JP. Vasseur March 2012 ASCII 19093 9 LLN LLNs Trickle

The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]

draft-ietf-6man-rpl-option-06 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6553
RFC6554 An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) J. Hui JP. Vasseur D. Culler V. Manral March 2012 ASCII 30270 13 LLN LLNs

In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]

draft-ietf-6man-rpl-routing-header-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6554
RFC6555 Happy Eyeballs: Success with Dual-Stack Hosts D. Wing A. Yourtchenko April 2012 ASCII 34048 15

When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK]

draft-ietf-v6ops-happy-eyeballs-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6555 10.17487/RFC6555
RFC6556 Testing Eyeball Happiness F. Baker April 2012 ASCII 23727 10 test methodology IPv4 IPv6 session startup metrics

The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-baker-bmwg-testing-eyeball-happiness-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6556
RFC6557 Procedures for Maintaining the Time Zone Database E. Lear P. Eggert February 2012 ASCII 18469 9

Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone (TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers. This memo documents an Internet Best Current Practice.

draft-lear-iana-timezone-database-05 BCP0175 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6557
RFC6558 Sieve Extension for Converting Messages before Delivery A. Melnikov B. Leiba K. Li March 2012 ASCII 17152 8 Sieve CONVERT

This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. [STANDARDS-TRACK]

draft-ietf-sieve-convert-06 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6558
RFC6559 A Reliable Transport Mechanism for PIM D. Farinacci IJ. Wijnands S. Venaas M. Napierala March 2012 ASCII 70159 29

This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pim-port-09 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC6559
RFC6560 One-Time Password (OTP) Pre-Authentication G. Richards April 2012 ASCII 95896 43

The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password (OTP) authentication. [STANDARDS-TRACK]

draft-ietf-krb-wg-otp-preauth-21 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6560
RFC6561 Recommendations for the Remediation of Bots in ISP Networks J. Livingood N. Mody M. O'Reirdan March 2012 ASCII 74562 29 ISP Internet Service Provider Bot Botnet Remediation malware notification

This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-oreirdan-mody-bot-remediation-20 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6561
RFC6562 Guidelines for the Use of Variable Bit Rate Audio with Secure RTP C. Perkins JM. Valin March 2012 ASCII 14288 6 vbr

This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. [STANDARDS-TRACK]

draft-ietf-avtcore-srtp-vbr-audio-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6562
RFC6563 Moving A6 to Historic Status S. Jiang D. Conrad B. Carpenter March 2012 ASCII 16654 8

This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-jiang-a6-to-historic-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6563
RFC6564 A Uniform Format for IPv6 Extension Headers S. Krishnan J. Woodyatt E. Kline J. Hoagland M. Bhatia April 2012 ASCII 12879 6

In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed. [STANDARDS-TRACK]

draft-ietf-6man-exthdr-06 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6564 10.17487/RFC6564
RFC6565 OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol P. Pillay-Esnault P. Moyer J. Doyle E. Ertekin M. Lundberg June 2012 ASCII 43217 20 L3VPN BGP/MPLS VPN

Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. [STANDARDS-TRACK]

draft-ietf-l3vpn-ospfv3-pece-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6565
RFC6566 A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments Y. Lee Editor G. Bernstein Editor D. Li G. Martinelli March 2012 ASCII 68851 31

As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks.

This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to support Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation. This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-wson-impairments-10 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6566
RFC6567 Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP A. Johnston L. Liess April 2012 ASCII 25981 11

This document introduces the transport of call control User-to-User Information (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the Integrated Services Digital Network (ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-cuss-sip-uui-reqs-09 INFORMATIONAL INFORMATIONAL IETF rai cuss 10.17487/RFC6567
RFC6568 Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) E. Kim D. Kaspar JP. Vasseur April 2012 ASCII 64728 28

This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN Working Group is provided with the characteristics of each dimension. A complete list of practical use cases is not the goal of this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6lowpan-usecases-10 INFORMATIONAL INFORMATIONAL IETF int 6lowpan 10.17487/RFC6568
RFC6569 Guidelines for Development of an Audio Codec within the IETF JM. Valin S. Borilin K. Vos C. Montgomery R. Chen March 2012 ASCII 33718 14 audio codec speech codec

This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-codec-guidelines-08 INFORMATIONAL INFORMATIONAL IETF rai codec 10.17487/RFC6569
RFC6570 URI Template J. Gregorio R. Fielding M. Hadley M. Nottingham D. Orchard March 2012 ASCII 79813 34 template Uniform Resource Identifier URI URI Template Internationalized Resource Identifier IRI IRI Template

A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]

draft-gregorio-uritemplate-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6570 10.17487/RFC6570
RFC6571 Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks C. Filsfils Editor P. Francois Editor M. Shand B. Decraene J. Uttaro N. Leymann M. Horneffer June 2012 ASCII 71363 35 IP Fast Reroute Routing Convergence Network Topology IS-IS OSPF

In this document, we analyze the applicability of the Loop-Free Alternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-rtgwg-lfa-applicability-06 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=6571 10.17487/RFC6571
RFC6572 RADIUS Support for Proxy Mobile IPv6 F. Xia B. Sarikaya J. Korhonen Editor S. Gundavelli D. Damic June 2012 ASCII 74903 36

This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses RADIUS-based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization, and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the mobile node (MN) attaches, authenticates, and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. [STANDARDS-TRACK]

draft-ietf-netext-radius-pmip6-08 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6572
RFC6573 The Item and Collection Link Relations M. Amundsen April 2012 ASCII 7492 5

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-amundsen-item-and-collection-link-relations-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6573
RFC6574 Report from the Smart Object Workshop H. Tschofenig J. Arkko April 2012 ASCII 74281 32 Smart Objects Internet of Things

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-smart-object-workshop-10 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6574
RFC6575 Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs H. Shah Editor E. Rosen Editor G. Heron Editor V. Kompella Editor June 2012 ASCII 65881 28

The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet or both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. [STANDARDS-TRACK]

draft-ietf-l2vpn-arp-mediation-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC6575
RFC6576 IP Performance Metrics (IPPM) Standard Advancement Testing R. Geib Editor A. Morton R. Fardid A. Steinmitz March 2012 ASCII 84447 37 inter-operability equivalence measurement compliance metric

This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along the Standards Track. Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track. This document is an Internet Best Current Practice.

draft-ietf-ippm-metrictest-05 BCP0176 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=6576 10.17487/RFC6576
RFC6577 Authentication-Results Registration Update for Sender Policy Framework (SPF) Results M. Kucherawy March 2012 ASCII 8173 5 SPF Authentication

This memo updates the registry of authentication method results in Authentication-Results: message header fields, correcting a discontinuity between the original registry creation and the Sender Policy Framework (SPF) specification. [STANDARDS-TRACK]

draft-kucherawy-authres-spf-erratum-02 RFC7001 RFC5451 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6577
RFC6578 Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) C. Daboo A. Quillaud March 2012 ASCII 55731 29 sync-collection sync-token

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. [STANDARDS-TRACK]

draft-daboo-webdav-sync-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6578
RFC6579 The 'disclosure' Link Relation Type M. Yevstifeyev March 2012 ASCII 7427 5

This document specifies the 'disclosure' link relation type. It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified. [STANDARDS-TRACK]

draft-yevstifeyev-disclosure-relation-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6579
RFC6580 IANA Registries for the Remote Direct Data Placement (RDDP) Protocols M. Ko D. Black April 2012 ASCII 17613 10

The original RFCs that specified the Remote Direct Data Placement (RDDP) protocol suite did not create IANA registries for RDDP error codes, operation codes, and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. [STANDARDS-TRACK]

draft-ietf-storm-rddp-registries-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm http://www.rfc-editor.org/errata_search.php?rfc=6580 10.17487/RFC6580
RFC6581 Enhanced Remote Direct Memory Access (RDMA) Connection Establishment A. Kanevsky Editor C. Bestler Editor R. Sharp S. Wise April 2012 ASCII 57766 25

This document updates RFC 5043 and RFC 5044 by extending Marker Protocol Data Unit (PDU) Aligned Framing (MPA) negotiation for Remote Direct Memory Access (RDMA) connection establishment. The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP). The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration. [STANDARDS-TRACK]

draft-ietf-storm-mpa-peer-connect-09 RFC5043 RFC5044 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6581
RFC6582 The NewReno Modification to TCP's Fast Recovery Algorithm T. Henderson S. Floyd A. Gurtov Y. Nishida April 2012 ASCII 35413 16 congestion avoidance congestion control fast retransmit

RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. [STANDARDS-TRACK]

draft-ietf-tcpm-rfc3782-bis-05 RFC3782 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6582
RFC6583 Operational Neighbor Discovery Problems I. Gashinsky J. Jaeggli W. Kumari March 2012 ASCII 29480 12

In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.

This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. [STANDARDS-TRACK]

draft-ietf-v6ops-v6nd-problems-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6583
RFC6584 Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca April 2012 ASCII 67466 30 TESLA FLUTE

This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols. The first scheme is based on RSA Digital Signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a Group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service. [STANDARDS-TRACK]

draft-ietf-rmt-simple-auth-for-alc-norm-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC6584
RFC6585 Additional HTTP Status Codes M. Nottingham R. Fielding April 2012 ASCII 17164 10 Hypertext Transfer Protocol

This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]

draft-nottingham-http-new-status-04 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6585
RFC6586 Experiences from an IPv6-Only Network J. Arkko A. Keranen April 2012 ASCII 52062 21 IPv6 NAT64

This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-arkko-ipv6-only-experience-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6586
RFC6587 Transmission of Syslog Messages over TCP R. Gerhards C. Lonvick April 2012 ASCII 21006 11 SYSLOG SYSLOG transport TCP

There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice. This memo describes how TCP has been used as a transport for syslog messages. This document defines a Historic Document for the Internet community.

draft-gerhards-syslog-plain-tcp-14 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC6587
RFC6588 A URN Namespace for ucode C. Ishikawa April 2012 ASCII 14382 8

This document describes a Uniform Resource Name (URN) namespace for ucode, an identifier system for objects and places. ucode technology is used in many applications, and this document provides a URN namespace for ucode to enable its use in Internet-related devices and software. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ishikawa-yrpunl-ucode-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6588 10.17487/RFC6588
RFC6589 Considerations for Transitioning Content to IPv6 J. Livingood April 2012 ASCII 68822 27

This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6589
RFC6590 Redaction of Potentially Sensitive Data from Mail Abuse Reports J. Falk Editor M. Kucherawy Editor April 2012 ASCII 15927 8 ARF MARF feedback loop spam reporting

Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. [STANDARDS-TRACK]

draft-ietf-marf-redaction-08 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6590
RFC6591 Authentication Failure Reporting Using the Abuse Reporting Format H. Fontana April 2012 ASCII 32378 16 auth auth failure dkim spf AFRF ARF

This memo registers an extension report type for the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. [STANDARDS-TRACK]

draft-ietf-marf-authfailure-report-10 RFC6692 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6591
RFC6592 The Null Packet C. Pignataro April 1 2012 ASCII 11036 6

The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-pignataro-the-null-packet-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6592
RFC6593 Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS) C. Pignataro J. Clarke G. Salgueiro April 1 2012 ASCII 16752 8

With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence. Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.

This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. This document defines an Experimental Protocol for the Internet community.

draft-joegonzalocarlos-service-hide-n-seek-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6593
RFC6594 Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records O. Sury April 2012 ASCII 17418 9 DNS Domain Name System SSHFP SHA-256 Secure Shell ECDSA

This document updates the IANA registries in RFC 4255, which defines SSHFP, a DNS Resource Record (RR) that contains a standard Secure Shell (SSH) key fingerprint used to verify SSH host keys using DNS Security Extensions (DNSSEC). This document defines additional options supporting SSH public keys applying the Elliptic Curve Digital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm in SSHFP Resource Records. [STANDARDS-TRACK]

draft-os-ietf-sshfp-ecdsa-sha2-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6594
RFC6595 A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) K. Wierenga E. Lear S. Josefsson April 2012 ASCII 49522 22 Generic Security Service Application Program Interface SAML 2.0

The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. The Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]

draft-ietf-kitten-sasl-saml-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC6595
RFC6596 The Canonical Link Relation M. Ohye J. Kupke April 2012 ASCII 13800 8

RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship, "canonical", to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ohye-canonical-link-relation-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6596
RFC6597 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data J. Downs Editor J. Arbeiter Editor April 2012 ASCII 27339 13 KLV

This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE ST 336, into the Real-time Transport Protocol (RTP). [STANDARDS-TRACK]

draft-ietf-payload-rtp-klv-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6597
RFC6598 IANA-Reserved IPv4 Prefix for Shared Address Space J. Weil V. Kuarsingh C. Donley C. Liljenstolpe M. Azinger April 2012 ASCII 22055 11 shared block CGN NAT Carrier Grade NAT private address space service provider address translation non-globally routable non-overlapping address space

This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).

Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.

This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. This memo documents an Internet Best Current Practice.

draft-weil-shared-transition-space-request-15 RFC5735 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6598
RFC6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks G. Ash Editor D. McDysan April 2012 ASCII 82005 34

This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv-aware MPLS Traffic Engineering (DS-TE), Path Computation Element (PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. This document defines an Experimental Protocol for the Internet community.

draft-ash-gcac-algorithm-spec-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6601
RFC6602 Bulk Binding Update Support for Proxy Mobile IPv6 F. Abinader Editor S. Gundavelli Editor K. Leung S. Krishnan D. Premec May 2012 ASCII 56348 23 Proxy Mobile IPv6 PMIPv6 bulk registrations MN group ID

For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier. [STANDARDS-TRACK]

draft-ietf-netext-bulk-re-registration-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6602
RFC6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation J. Korhonen Editor T. Savolainen S. Krishnan O. Troan May 2012 ASCII 19485 10 OPTION_PD_EXCLUDE

This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation. The new mechanism updates RFC 3633. [STANDARDS-TRACK]

draft-ietf-dhc-pd-exclude-04 RFC3633 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6603 10.17487/RFC6603
RFC6604 xNAME RCODE and Status Bits Clarification D. Eastlake 3rd April 2012 ASCII 10790 5 DNS DNSSEC CNAME DNAME Domain Name response code canonical name

The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name), whereby a DNS query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. [STANDARDS-TRACK]

draft-ietf-dnsext-xnamercode-00 RFC1035 RFC2308 RFC2672 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6604
RFC6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC P. Hoffman W.C.A. Wijngaards April 2012 ASCII 14332 8 dnskey algorithm ds hash algo crypto DNS key DNSKEY algorithm DS digest hash cryptography SHA-384 ECDSAP256SHA256 ECDSAP384SHA384

This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK]

draft-ietf-dnsext-ecdsa-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6605
RFC6606 Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing E. Kim D. Kaspar C. Gomez C. Bormann May 2012 ASCII 75436 32 WSN Sensor Network Wireless Sensor Network WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing ieee 802.15.4 LLN Low Power radio 802.15.4 powerline ISA100.11a RFC 4944

IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.

This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6lowpan-routing-requirements-10 INFORMATIONAL INFORMATIONAL IETF int 6lowpan 10.17487/RFC6606
RFC6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6 K. Kinnear R. Johnson M. Stapp April 2012 ASCII 60312 26 draft-ietf-dhc-vpn-option-15 RFC3046 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6607 RFC6608 Subcodes for BGP Finite State Machine Error J. Dong M. Chen A. Suryanarayana May 2012 ASCII 8612 5

This document defines several subcodes for the BGP Finite State Machine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. This document updates RFC 4271. [STANDARDS-TRACK]

draft-ietf-idr-fsm-subcode-03 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC6608
RFC6609 Sieve Email Filtering: Include Extension C. Daboo A. Stone May 2012 ASCII 26142 14

The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. [STANDARDS-TRACK]

draft-ietf-sieve-include-15 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6609
RFC6610 DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6) H. Jang A. Yegin K. Chowdhury J. Choi T. Lemon May 2012 ASCII 36878 16

This document defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined that allow a mobile node to request the home agent IP address, Fully Qualified Domain Name (FQDN), or home network prefix and obtain it via the DHCP response. [STANDARDS-TRACK]

draft-ietf-mip6-hiopt-18 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC6610
RFC6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario K. Chowdhury Editor A. Yegin May 2012 ASCII 27152 12

Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. [STANDARDS-TRACK]

draft-ietf-mip6-bootstrapping-integrated-dhc-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC6611
RFC6612 Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues G. Giaretta Editor May 2012 ASCII 40116 18

The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netlmm-mip-interactions-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6612
RFC6613 RADIUS over TCP A. DeKok May 2012 ASCII 37646 16 Remote Authentication Dial-In User Server Transmission Control Protocol RADIUS/TCP

The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. This document defines an Experimental Protocol for the Internet community.

draft-ietf-radext-tcp-transport-09 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC6613
RFC6614 Transport Layer Security (TLS) Encryption for RADIUS S. Winter M. McCauley S. Venaas K. Wierenga May 2012 ASCII 48004 22 RADIUS AAA Security Reliability Remote Authentication Dial-In User Server

This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK]

draft-ietf-radext-radsec-12 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC6614
RFC6615 Definitions of Managed Objects for IP Flow Information Export T. Dietz Editor A. Kobayashi B. Claise G. Muenz June 2012 ASCII 137274 65 IPFIX MIB Filtering Sampling Selection

This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors, including basic configuration information. [STANDARDS-TRACK]

draft-ietf-ipfix-rfc5815bis-03 RFC5815 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6615
RFC6616 A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID E. Lear H. Tschofenig H. Mauldin S. Josefsson May 2012 ASCII 39323 18 web single sign-on

OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]

draft-ietf-kitten-sasl-openid-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC6616
RFC6617 Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE) D. Harkins June 2012 ASCII 53805 24 Authenticated Key Exchange Dictionary Attack

This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack and retains security even when used with weak pre-shared keys. This document defines an Experimental Protocol for the Internet community.

draft-harkins-ipsecme-spsk-auth-08 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6617
RFC6618 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent J. Korhonen Editor B. Patil H. Tschofenig D. Kroeselberg May 2012 ASCII 87475 38 Mobile IPv6 Security

Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent (HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol (IKE) version 1 or 2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mext-mip6-tls-05 EXPERIMENTAL EXPERIMENTAL IETF int mext 10.17487/RFC6618
RFC6619 Scalable Operation of Address Translators with Per-Interface Bindings J. Arkko L. Eggert M. Townsley June 2012 ASCII 18590 9 NAT IPv4 IPv6

This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. [STANDARDS-TRACK]

draft-arkko-dual-stack-extra-lite-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6619
RFC6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses E. Nordmark M. Bagnulo E. Levy-Abegnoli May 2012 ASCII 84010 35 ingress filtering BCP38

This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. [STANDARDS-TRACK]

draft-ietf-savi-fcfs-14 PROPOSED STANDARD PROPOSED STANDARD IETF int savi http://www.rfc-editor.org/errata_search.php?rfc=6620 10.17487/RFC6620
RFC6621 Simplified Multicast Forwarding J. Macker Editor May 2012 ASCII 139674 55 routing flooding optimized flooding CDS connected dominating set duplicate packet detection hash-based packet detection MPR MPR-CDS E-CDS edge mobility mobile ad hoc mesh network

This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document. This document defines an Experimental Protocol for the Internet community.

draft-ietf-manet-smf-14 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=6621 10.17487/RFC6621
RFC6622 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) U. Herberg T. Clausen May 2012 ASCII 48083 21 packetbb NHDP OLSRv2 security integrity routing

This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. [STANDARDS-TRACK]

draft-ietf-manet-packetbb-sec-09 RFC7182 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC6622
RFC6623 IANA Registry for MEDIACTRL Interactive Voice Response Control Package E. Burger May 2012 ASCII 15756 6

This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package, as described in RFC 6231. [STANDARDS-TRACK]

draft-ietf-mediactrl-6231-iana-00 RFC6231 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6623
RFC6624 Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling K. Kompella B. Kothari R. Cherukuri May 2012 ASCII 64693 26 BGP L2VPN discovery signaling pseudowire

Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-kompella-l2vpn-l2vpn-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6624
RFC6625 Wildcards in Multicast VPN Auto-Discovery Routes E. Rosen Editor Y. Rekhter Editor W. Hendrickx R. Qiu May 2012 ASCII 35348 17 mvpn

In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK]

draft-ietf-l3vpn-mvpn-wildcards-02 RFC6514 RFC7582 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6625
RFC6626 Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4) G. Tsirtsis V. Park V. Narayanan K. Leung May 2012 ASCII 9270 5 mobile router

The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism for NEMOv4. [STANDARDS-TRACK]

draft-ietf-mip4-nemov4-dynamic-06 RFC5177 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6626
RFC6627 Overview of Pre-Congestion Notification Encoding G. Karagiannis K. Chan T. Moncaster M. Menth P. Eardley B. Briscoe July 2012 ASCII 47274 20

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious \%pre-congestion.

The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pcn-encoding-comparison-09 INFORMATIONAL INFORMATIONAL IETF tsv pcn 10.17487/RFC6627
RFC6628 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 S. Shin K. Kobara June 2012 ASCII 45831 20 PAKE augmented PAKE off-line dictionary attacks resistance to server compromise

This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2). This document defines an Experimental Protocol for the Internet community.

draft-shin-augmented-pake-15 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6628
RFC6629 Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) J. Abley M. Bagnulo A. Garcia-Martinez June 2012 ASCII 70291 28 Cryptographically Generated Address CGA Hash-Based Address HBA Fault tolerance

This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-garcia-shim6-applicability-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6629
RFC6630 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) Z. Cao H. Deng Q. Wu G. Zorn Editor June 2012 ASCII 40373 20 ERP AAK EAP Early-authentication

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.

The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.

Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more Candidate Attachment Points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport.

This document specifies the extensions necessary to enable AAK support in ERP. [STANDARDS-TRACK]

draft-ietf-hokey-erp-aak-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6630
RFC6631 Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) D. Kuegler Y. Sheffer June 2012 ASCII 53353 26 pace password authenticated connection establishment

The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password-authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration. This document defines an Experimental Protocol for the Internet community.

draft-kuegler-ipsecme-pace-ikev2-10 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6631
RFC6632 An Overview of the IETF Network Management Standards M. Ersue Editor B. Claise June 2012 ASCII 210159 85 network management data model monitoring configuration alarm notification

This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsawg-management-stds-07 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC6632
RFC6633 Deprecation of ICMP Source Quench Messages F. Gont May 2012 ASCII 16367 8 congestion control icmp attacks tcp tcp security udp dccp sctp

This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. [STANDARDS-TRACK]

draft-ietf-tsvwg-source-quench-06 RFC0792 RFC1122 RFC1812 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6633
RFC6635 RFC Editor Model (Version 2) O. Kolkman Editor J. Halpern Editor IAB June 2012 ASCII 48170 21 RFC Series Editor Independenet Series Editor RSE ISE RSOC RFC Series Oversight Committee

The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620, and obsoletes that document. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-rfc-editor-model-v2-05 RFC5620 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6635
RFC6636 Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks H. Asaeda H. Liu Q. Wu May 2012 ASCII 30261 12 Mobility PMIPv6

The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-multimob-igmp-mld-tuning-06 INFORMATIONAL INFORMATIONAL IETF int multimob 10.17487/RFC6636
RFC6637 Elliptic Curve Cryptography (ECC) in OpenPGP A. Jivsov June 2012 ASCII 31532 15

This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. [STANDARDS-TRACK]

draft-jivsov-openpgp-ecc-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6637
RFC6638 Scheduling Extensions to CalDAV C. Daboo B. Desruisseaux June 2012 ASCII 156287 78 calsify calsched calsch calendar calendaring webcal ical icalendar ischedule itip imip text/calendar http

This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. [STANDARDS-TRACK]

draft-desruisseaux-caldav-sched-12 RFC4791 RFC5546 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6638
RFC6639 Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview D. King Editor M. Venkatesan Editor June 2012 ASCII 58669 29

A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.

The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks.

This document describes the MIB-based architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management, and identifies areas where additional MIB modules are required. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-mib-management-overview-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6639 10.17487/RFC6639
RFC6640 IETF Meeting Attendees' Frequently Asked (Travel) Questions W. George June 2012 ASCII 27610 13 Meetings

This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in the IETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-george-travel-faq-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6640
RFC6641 Using DNS SRV to Specify a Global File Namespace with NFS Version 4 C. Everhart W. Adamson J. Zhang June 2012 ASCII 24047 11 domainroot domain root file system

The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace. The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace. [STANDARDS-TRACK]

draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC6641
RFC6642 RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report Q. Wu Editor F. Xia R. Even June 2012 ASCII 29758 13 Feedback Suppression NACK Retransmission

In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK]

draft-ietf-avtcore-feedback-supression-rtp-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6642
RFC6643 Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules J. Schoenwaelder July 2012 ASCII 69140 36 SMIv2 YANG data modeling

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the Simple Network Management Protocol (SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. [STANDARDS-TRACK]

draft-ietf-netmod-smi-yang-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC6643
RFC6644 Rebind Capability in DHCPv6 Reconfigure Messages D. Evans R. Droms S. Jiang July 2012 ASCII 19176 10 internet protocol parameters addresses

This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-reconfigure-rebind-10 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6644
RFC6645 IP Flow Information Accounting and Export Benchmarking Methodology J. Novak July 2012 ASCII 87875 39 Performance Flow monitoring IPFIX Netflow

This document provides a methodology and framework for quantifying the performance impact of the monitoring of IP flows on a network device and the export of this information to a Collector. It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput. The metric is only applicable to the devices compliant with RFC 5470, "Architecture for IP Flow Information Export". The methodology quantifies the impact of the IP flow monitoring process on the network equipment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-ipflow-meth-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6645
RFC6646 DECoupled Application Data Enroute (DECADE) Problem Statement H. Song N. Zong Y. Yang R. Alimi July 2012 ASCII 25124 12 In-network storage P2P

Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache. This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-decade-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF tsv decade 10.17487/RFC6646
RFC6647 Email Greylisting: An Applicability Statement for SMTP M. Kucherawy D. Crocker June 2012 ASCII 38097 17 Email Greylisting Spam

This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.

Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. [STANDARDS-TRACK]

draft-ietf-appsawg-greylisting-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6647
RFC6648 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols P. Saint-Andre D. Crocker M. Nottingham June 2012 ASCII 28393 13

Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This memo documents an Internet Best Current Practice.

draft-ietf-appsawg-xdash-05 BCP0178 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg 10.17487/RFC6648
RFC6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos L. Hornquist Astrand T. Yu July 2012 ASCII 13498 7

The Kerberos 5 network authentication protocol, originally specified in RFC 1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the National Institute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average. DES is long past its sell-by date. Accordingly, this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos. Because RFC 1510 (obsoleted by RFC 4120) supports only DES, this document recommends the reclassification of RFC 1510 as Historic. This memo documents an Internet Best Current Practice.

draft-ietf-krb-wg-des-die-die-die-04 RFC1510 RFC1964 RFC4120 RFC4121 RFC4757 BCP0179 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec krb-wg 10.17487/RFC6649
RFC6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) J. Falk M. Kucherawy Editor June 2012 ASCII 35273 15 marf spam reporting

RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. [STANDARDS-TRACK]

draft-ietf-marf-as-16 RFC5965 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6650
RFC6651 Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting M. Kucherawy June 2012 ASCII 35028 18 authentication fraud phishing spoofing

This document presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. [STANDARDS-TRACK]

draft-ietf-marf-dkim-reporting-16 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6651
RFC6652 Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format S. Kitterman June 2012 ASCII 15373 8 fraud phishing spoofing

This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.

This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK]

draft-ietf-marf-spf-reporting-11 RFC4408 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6652
RFC6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks B. Sarikaya F. Xia T. Lemon July 2012 ASCII 28755 13

As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting (AAA) servers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sarikaya-v6ops-prefix-delegation-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6653
RFC6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd) T. Tsou C. Zhou T. Taylor Q. Chen July 2012 ASCII 16949 8 IPv6 transition

This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator's IPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-tsou-softwire-gwinit-6rd-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6654
RFC6655 AES-CCM Cipher Suites for Transport Layer Security (TLS) D. McGrew D. Bailey July 2012 ASCII 17052 8 Authentication Encryption Advanced Encryption Standard (AES)

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK]

draft-mcgrew-tls-aes-ccm-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6655 10.17487/RFC6655
RFC6656 Description of Cisco Systems' Subnet Allocation Option for DHCPv4 R. Johnson K. Kinnear M. Stapp July 2012 ASCII 54971 24

This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the Cisco Systems' Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented and that the working group will try to officially assign those numbers to those options. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dhc-subnet-alloc-13 INFORMATIONAL INFORMATIONAL IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6656 10.17487/RFC6656
RFC6657 Update to MIME regarding "charset" Parameter Handling in Textual Media Types A. Melnikov J. Reschke July 2012 ASCII 10111 6 MIME charset text

This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. [STANDARDS-TRACK]

draft-ietf-appsawg-mime-default-charset-04 RFC2046 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6657
RFC6658 Packet Pseudowire Encapsulation over an MPLS PSN S. Bryant Editor L. Martini G. Swallow A. Malis July 2012 ASCII 32164 15

This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. [STANDARDS-TRACK]

draft-ietf-pwe3-packet-pw-04 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC6658
RFC6659 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method A. Begen July 2012 ASCII 24234 12 IPTV FEC retransmission

The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-avtext-rams-scenarios-05 INFORMATIONAL INFORMATIONAL IETF rai avtext 10.17487/RFC6659
RFC6660 Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP) B. Briscoe T. Moncaster M. Menth July 2012 ASCII 52230 24 Quality of Service QoS Congestion Control Congestion Notification Tunnelling Encapsulation & Decapsulation Differentiated Services Integrated Services Signalling Protocol Flow Admission Control Flow Termination

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.

This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRACK]

draft-ietf-pcn-3-in-1-encoding-11 RFC5696 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn 10.17487/RFC6660
RFC6661 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation A. Charny F. Huang G. Karagiannis M. Menth T. Taylor Editor July 2012 ASCII 72258 33 PCN controlled load CL boundary node behavior

Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using three PCN marking states: not- marked, threshold-marked, and excess-traffic-marked. This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pcn-cl-edge-behaviour-14 EXPERIMENTAL EXPERIMENTAL IETF tsv pcn 10.17487/RFC6661
RFC6662 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation A. Charny J. Zhang G. Karagiannis M. Menth T. Taylor Editor July 2012 ASCII 67000 31 PCN single marking SM edge node behavior

Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked. This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pcn-sm-edge-behaviour-12 EXPERIMENTAL EXPERIMENTAL IETF tsv pcn 10.17487/RFC6662
RFC6663 Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain G. Karagiannis T. Taylor K. Chan M. Menth P. Eardley July 2012 ASCII 15316 7

Pre-Congestion Notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN-domain: (1) PCN-feedback-information is carried from the PCN-egress-node to the Decision Point; (2) the Decision Point may ask the PCN-ingress-node to measure, and report back, the rate of sent PCN-traffic between that PCN-ingress-node and PCN-egress-node. The Decision Point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors, Controlled Load (CL) and Single Marking (SM). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pcn-signaling-requirements-08 INFORMATIONAL INFORMATIONAL IETF tsv pcn 10.17487/RFC6663
RFC6664 S/MIME Capabilities for Public Key Definitions J. Schaad July 2012 ASCII 37926 19 OCSP CMS

This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-pubkey-caps-07 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6664
RFC6665 SIP-Specific Event Notification A.B. Roach July 2012 ASCII 125556 53 SUBSCRIBE NOTIFY state

This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.

Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.

This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK]

draft-ietf-sipcore-rfc3265bis-09 RFC3265 RFC3261 RFC4660 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6665
RFC6666 A Discard Prefix for IPv6 N. Hilliard D. Freedman August 2012 ASCII 10658 6 RTBH black hole

Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates the "IPv6 Special Purpose Address Registry" by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-ipv6-discard-prefix-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6666
RFC6667 LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements K. Raza S. Boutros C. Pignataro July 2012 ASCII 17068 8

The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired. However, a Typed Wildcard FEC Element must be individually defined for each FEC Element type. This specification defines the Typed Wildcard FEC Elements for the Pseudowire Identifier (PWid) (0x80) and Generalized PWid (0x81) FEC Element types. [STANDARDS-TRACK]

draft-ietf-pwe3-pw-typed-wc-fec-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6667
RFC6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol D. Bider M. Baushke July 2012 ASCII 8710 5

This memo defines algorithm names and parameters for use in some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol. It also updates RFC 4253 by specifying a new RECOMMENDED data integrity algorithm. [STANDARDS-TRACK]

draft-dbider-sha2-mac-for-ssh-06 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6668
RFC6669 An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks N. Sprecher L. Fang July 2012 ASCII 46171 21

This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of the MPLS Transport Profile (MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-oam-analysis-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6669 10.17487/RFC6669
RFC6670 The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) N. Sprecher KY. Hong July 2012 ASCII 77266 33

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work on MPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.

During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.

One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sprecher-mpls-tp-oam-considerations-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6670
RFC6671 Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM) M. Betts November 2012 ASCII 8941 5

This document assigns a Generic Associated Channel (G-ACh) Type for carrying ITU-T MPLS Transport Profile Operations, Administration, and Management (MPLS-TP OAM) messages in the MPLS Generic Associated Channel. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-betts-itu-oam-ach-code-point-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6671
RFC6672 DNAME Redirection in the DNS S. Rose W. Wijngaards June 2012 ASCII 45704 22

The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]

draft-ietf-dnsext-rfc2672bis-dname-26 RFC2672 RFC3363 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6672
RFC6673 Round-Trip Packet Loss Metrics A. Morton August 2012 ASCII 28458 14 IP IPPM

Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.

This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). [STANDARDS-TRACK]

draft-ietf-ippm-rt-loss-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6673
RFC6674 Gateway-Initiated Dual-Stack Lite Deployment F. Brockners S. Gundavelli S. Speicher D. Ward July 2012 ASCII 32731 15 GI-DS-Lite Gateway Initiated Dual-Stack Lite Dual-Stack Lite IPv6 Transitioning IPv6 Migration

Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual- Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. [STANDARDS-TRACK]

draft-ietf-softwire-gateway-init-ds-lite-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6674
RFC6675 A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP E. Blanton M. Allman L. Wang I. Jarvinen M. Kojo Y. Nishida August 2012 ASCII 34484 15 transmission control protocol retransmission congestion control

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TRACK]

draft-ietf-tcpm-3517bis-02 RFC3517 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6675
RFC6676 Multicast Addresses for Documentation S. Venaas R. Parekh G. Van de Velde T. Chown M. Eubanks August 2012 ASCII 14100 7

This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mboned-mcaddrdoc-04 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC6676
RFC6677 Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods S. Hartman Editor T. Clancy K. Hoeper July 2012 ASCII 79805 31

This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK]

draft-ietf-emu-chbind-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC6677
RFC6678 Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method K. Hoeper S. Hanna H. Zhou J. Salowey Editor July 2012 ASCII 54446 23

This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-emu-eaptunnel-req-09 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC6678
RFC6679 Explicit Congestion Notification (ECN) for RTP over UDP M. Westerlund I. Johansson C. Perkins P. O'Hanlon K. Carlberg August 2012 ASCII 148560 58 ECN RTP UDP Congestion Control VoIP IPTV Packet Loss

This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK]

draft-ietf-avtcore-ecn-for-rtp-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore http://www.rfc-editor.org/errata_search.php?rfc=6679 10.17487/RFC6679
RFC6680 Generic Security Service Application Programming Interface (GSS-API) Naming Extensions N. Williams L. Johansson S. Hartman S. Josefsson August 2012 ASCII 37063 18

The Generic Security Service Application Programming Interface (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers.

draft-ietf-kitten-gssapi-naming-exts-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten http://www.rfc-editor.org/errata_search.php?rfc=6680 10.17487/RFC6680
RFC6681 Raptor Forward Error Correction (FEC) Schemes for FECFRAME M. Watson T. Stockhammer M. Luby August 2012 ASCII 46372 22

This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g., UDP) or using RTP. [STANDARDS-TRACK]

draft-ietf-fecframe-raptor-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6681
RFC6682 RTP Payload Format for Raptor Forward Error Correction (FEC) M. Watson T. Stockhammer M. Luby August 2012 ASCII 35386 18

This document specifies an RTP payload format for the Forward Error Correction (FEC) repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP. This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows. [STANDARDS-TRACK]

draft-ietf-fecframe-rtp-raptor-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6682
RFC6683 Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection A. Begen T. Stockhammer August 2012 ASCII 22726 11 DVB FEC AL-FEC IPTV parity codes Raptor codes

Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward Error Correction (AL-FEC) protocol to protect the streaming media transported using RTP. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-fecframe-dvb-al-fec-04 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6683
RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) B. Trammell July 2012 ASCII 23550 12 mile incident handling

This document provides guidelines for extensions to the Incident Object Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mile-template-05 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC6684
RFC6685 Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry B. Trammell July 2012 ASCII 4363 3 mile xml schema

This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to Incident Object Description Exchange Format (IODEF). [STANDARDS-TRACK]

draft-ietf-mile-iodef-xmlreg-01 RFC5070 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC6685
RFC6686 Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments M. Kucherawy July 2012 ASCII 26421 12 SPF Sender ID authentication authorization email

In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.

The IESG required all of these documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward.

After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-spfbis-experiment-11 INFORMATIONAL INFORMATIONAL IETF app spfbis http://www.rfc-editor.org/errata_search.php?rfc=6686 10.17487/RFC6686
RFC6687 Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) J. Tripathi Editor J. de Oliveira Editor JP. Vasseur Editor October 2012 ASCII 63624 26 PDF 589296 ROLL

This document presents a performance evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network. Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios. Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-tripathi-roll-rpl-simulation-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6687
RFC6688 Parallel NFS (pNFS) Block Disk Protection D. Black Editor J. Glasgow S. Faibish July 2012 ASCII 12119 6 NFS NFSv4 pNFS SAN GPT

Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server. This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. [STANDARDS-TRACK]

draft-ietf-nfsv4-pnfs-block-disk-protection-03 RFC5663 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC6688
RFC6689 Usage of the RSVP ASSOCIATION Object L. Berger July 2012 ASCII 26037 11 Resource Reservation Protocol

The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This document reviews how the association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-assoc-info-03 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6689
RFC6690 Constrained RESTful Environments (CoRE) Link Format Z. Shelby August 2012 ASCII 47720 22 CoRE Link Format HTTP Link Header Format Resource Discovery

This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]

draft-ietf-core-link-format-14 PROPOSED STANDARD PROPOSED STANDARD IETF app core http://www.rfc-editor.org/errata_search.php?rfc=6690 10.17487/RFC6690
RFC6691 TCP Options and Maximum Segment Size (MSS) D. Borman July 2012 ASCII 16707 9

This memo discusses what value to use with the TCP Maximum Segment Size (MSS) option, and updates RFC 879 and RFC 2385. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tcpm-tcpmss-05 RFC0879 RFC2385 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6691
RFC6692 Source Ports in Abuse Reporting Format (ARF) Reports R. Clayton M. Kucherawy July 2012 ASCII 8053 5 ARF ports reporting feedback

This document defines an additional header field for use in Abuse Reporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.

This document updates RFC 6591. [STANDARDS-TRACK]

draft-kucherawy-marf-source-ports-05 RFC6591 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6692
RFC6693 Probabilistic Routing Protocol for Intermittently Connected Networks A. Lindgren A. Doria E. Davies S. Grasic August 2012 ASCII 280908 113 DTN Routing PRoPHET

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the \%best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-prophet-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6693
RFC6694 The "about" URI Scheme S. Moonesamy Editor August 2012 ASCII 11604 7

This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-appsawg-about-uri-scheme-07 INFORMATIONAL INFORMATIONAL IETF app appsawg 10.17487/RFC6694
RFC6695 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information R. Asati August 2012 ASCII 34678 15

The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).

This document doesn't define any new signaling protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-fecframe-config-signaling-09 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6695
RFC6696 EAP Extensions for the EAP Re-authentication Protocol (ERP) Z. Cao B. He Y. Shi Q. Wu Editor G. Zorn Editor July 2012 ASCII 103860 47 EAP keying EMSK inter-authenticator roaming

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]

draft-ietf-hokey-rfc5296bis-07 RFC5296 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6696
RFC6697 Handover Keying (HOKEY) Architecture Design G. Zorn Editor Q. Wu T. Taylor Y. Nir K. Hoeper S. Decugis July 2012 ASCII 44243 20 Handover Keying Architecture Re-authentication Early authentication

The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.

This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-hokey-arch-design-11 INFORMATIONAL INFORMATIONAL IETF sec hokey 10.17487/RFC6697
RFC6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA P. Hoffman J. Schlyter August 2012 ASCII 84034 37 DNSSEC certificates public keys PKI

Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]

draft-ietf-dane-protocol-23 RFC7218 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=6698 10.17487/RFC6698
RFC6701 Sanctions Available for Application to Violators of IETF IPR Policy A. Farrel P. Resnick August 2012 ASCII 25078 12

The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware.

The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied.

This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-farrresnickel-ipr-sanctions-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6701
RFC6702 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules T. Polk P. Saint-Andre August 2012 ASCII 35052 16

The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-polk-ipr-disclosure-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6702
RFC6703 Reporting IP Network Performance Metrics: Different Points of View A. Morton G. Ramachandran G. Maguluri August 2012 ASCII 60152 27 Loss Delay Delay Variation Capacity TCP

Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-reporting-metrics-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6703
RFC6704 Forcerenew Nonce Authentication D. Miles W. Dec J. Bristow R. Maglione August 2012 ASCII 26538 12 DHCP

Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In the Forcerenew Nonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. [STANDARDS-TRACK]

draft-ietf-dhc-forcerenew-nonce-07 RFC3203 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6704 10.17487/RFC6704
RFC6705 Localized Routing for Proxy Mobile IPv6 S. Krishnan R. Koodli P. Loureiro Q. Wu A. Dutta September 2012 ASCII 43309 20 PMIPv6

Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. [STANDARDS-TRACK]

draft-ietf-netext-pmip-lr-10 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6705
RFC6706 Asymmetric Extended Route Optimization (AERO) F. Templin Editor August 2012 ASCII 77250 33 route optimize optimization redirect redirection protocol routing link multi-access IPv6

Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues. This document defines an Experimental Protocol for the Internet community.

draft-templin-aero-12 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6706 10.17487/RFC6706
RFC6707 Content Distribution Network Interconnection (CDNI) Problem Statement B. Niven-Jenkins F. Le Faucheur N. Bitar September 2012 ASCII 75060 32 Delivery CDN

Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.

The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-cdni-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC6707
RFC6708 Application-Layer Traffic Optimization (ALTO) Requirements S. Kiesel Editor S. Previdi M. Stiemerling R. Woundy Y. Yang September 2012 ASCII 47549 20

Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure.

This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-alto-reqs-16 INFORMATIONAL INFORMATIONAL IETF tsv alto 10.17487/RFC6708
RFC6709 Design Considerations for Protocol Extensions B. Carpenter B. Aboba Editor S. Cheshire September 2012 ASCII 103913 42

This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-extension-recs-17 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6709
RFC6710 Simple Mail Transfer Protocol Extension for Message Transfer Priorities A. Melnikov K. Carlberg August 2012 ASCII 59966 28 SMTP priority MMHS

This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. [STANDARDS-TRACK]

draft-melnikov-smtp-priority-21 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6710 10.17487/RFC6710
RFC6711 An IANA Registry for Level of Assurance (LoA) Profiles L. Johansson August 2012 ASCII 14416 7 Identity Assurance

This document establishes an IANA registry for Level of Assurance (LoA) Profiles. The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 and OpenID Connect. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-johansson-loa-registry-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6711
RFC6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) T. Kause M. Peylo September 2012 ASCII 21308 10 CMPtrans

This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. [STANDARDS-TRACK]

draft-ietf-pkix-cmp-transport-protocols-20 RFC4210 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6712
RFC6713 The 'application/zlib' and 'application/gzip' Media Types J. Levine August 2012 ASCII 6525 4 compress deflate stream compression

This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-levine-application-gzip-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6713
RFC6714 Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) C. Holmberg S. Blau E. Burger August 2012 ASCII 50543 22 Middlebox IBCF SBC

This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. [STANDARDS-TRACK]

draft-ietf-simple-msrp-cema-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC6714
RFC6715 vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group D. Cauchie B. Leiba K. Li August 2012 ASCII 18951 11 expertise hobby interest

This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance (OMA) Converged Address Book group, in order to synchronize, using OMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. [STANDARDS-TRACK]

draft-ietf-vcarddav-oma-cab-extensions-03 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6715 10.17487/RFC6715
RFC6716 Definition of the Opus Audio Codec JM. Valin K. Vos T. Terriberry September 2012 ASCII 977743 326 voice music lossy compression VOIP

This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]

draft-ietf-codec-opus-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai codec http://www.rfc-editor.org/errata_search.php?rfc=6716 10.17487/RFC6716
RFC6717 kx509 Kerberized Certificate Issuance Protocol in Use in 2012 H. Hotz R. Allbery August 2012 ASCII 29044 13 Kerberos X.509 kx509 KCA kca-service kca_service

This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.

While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hotz-kx509-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6717
RFC6718 Pseudowire Redundancy P. Muley M. Aissaoui M. Bocci August 2012 ASCII 41486 18 Active standby protection dual-homing vpls vpws

This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment PW applications or between terminating PE (T-PE) nodes in multi-segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundant set. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pwe3-redundancy-09 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC6718
RFC6719 The Minimum Rank with Hysteresis Objective Function O. Gnawali P. Levis September 2012 ASCII 29637 13 Routing Protocol for Low Power and Lossy Networks RPL Low Power and Lossy Networks LLN

The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. [STANDARDS-TRACK]

draft-ietf-roll-minrank-hysteresis-of-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC6719
RFC6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) C. Pignataro R. Asati August 2012 ASCII 17823 8 GTSM LDP

The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router\'s IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP).

This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-gtsm-09 RFC5036 RFC7552 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6720
RFC6721 The Atom "deleted-entry" Element J. Snell September 2012 ASCII 22678 10 Atom Feed Entry Documents

This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. [STANDARDS-TRACK]

draft-snell-atompub-tombstones-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6721
RFC6722 Publishing the "Tao of the IETF" as a Web Page P. Hoffman Editor August 2012 ASCII 6192 3

This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead being published as a web page. It also contains the procedure for publishing and editing that web page. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hoffman-tao-as-web-page-04 RFC4677 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6722
RFC6723 Update of the Pseudowire Control-Word Negotiation Mechanism L. Jin Editor R. Key Editor S. Delord T. Nadeau S. Boutros September 2012 ASCII 20307 9 control word control word negotiation control word renegotiation control word negotiation mechanism control word renegotiation mechanism

The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. [STANDARDS-TRACK]

draft-ietf-pwe3-cbit-negotiation-05 RFC4447 RFC6073 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6723
RFC6724 Default Address Selection for Internet Protocol Version 6 (IPv6) D. Thaler Editor R. Draves A. Matsumoto T. Chown September 2012 ASCII 74407 32 source destination sort sorting

This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.

Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]

draft-ietf-6man-rfc3484bis-06 RFC3484 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6724 10.17487/RFC6724
RFC6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates S. Rose August 2012 ASCII 9236 5

The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA-maintained registry. This document presents a set of changes for some entries of the registry. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-registry-update-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6725
RFC6726 FLUTE - File Delivery over Unidirectional Transport T. Paila R. Walsh M. Luby V. Roca R. Lehtonen November 2012 ASCII 108261 46 Multicast

This document defines File Delivery over Unidirectional Transport (FLUTE), a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC 3926. [STANDARDS-TRACK]

draft-ietf-rmt-flute-revised-16 RFC3926 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=6726 10.17487/RFC6726
RFC6727 Definitions of Managed Objects for Packet Sampling T. Dietz Editor B. Claise J. Quittek October 2012 ASCII 55441 28 PSAMP IPFIX MIB Sampling Filtering Selection

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX-SELECTOR-MIB module. For IP Flow Information eXport (IPFIX) implementations that use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP- MIB module containing managed objects for providing information on applied packet selection functions and their parameters. [STANDARDS-TRACK]

draft-ietf-ipfix-psamp-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6727
RFC6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols G. Muenz B. Claise P. Aitken October 2012 ASCII 279937 129

This document specifies a data model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) protocols. It is for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant Monitoring Devices using the Network Configuration Protocol (NETCONF). The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). [STANDARDS-TRACK]

draft-ietf-ipfix-configuration-model-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6728 10.17487/RFC6728
RFC6729 Indicating Email Handling States in Trace Fields D. Crocker M. Kucherawy September 2012 ASCII 24665 12 Quarantine Moderation

This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. [STANDARDS-TRACK]

draft-ietf-appsawg-received-state-04 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6729 10.17487/RFC6729
RFC6730 Requirements for IETF Nominations Committee Tools S. Krishnan J. Halpern September 2012 ASCII 19765 10

This document defines the requirements for a set of tools for use by the IETF Nominations Committee. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-krishnan-nomcom-tools-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6730
RFC6731 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes T. Savolainen J. Kato T. Lemon December 2012 ASCII 68882 29 DNS RDNSS interface FQDN selection

A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. [STANDARDS-TRACK]

draft-ietf-mif-dns-server-selection-12 PROPOSED STANDARD PROPOSED STANDARD IETF int mif 10.17487/RFC6731
RFC6732 6to4 Provider Managed Tunnels V. Kuarsingh Editor Y. Lee O. Vautrin September 2012 ASCII 28156 12 6to4-PMT

6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The 6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-07 RFC7526 HISTORIC INFORMATIONAL INDEPENDENT 10.17487/RFC6732
RFC6733 Diameter Base Protocol V. Fajardo Editor J. Arkko J. Loughney G. Zorn Editor October 2012 ASCII 343760 152 Diameter AAA

The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]

draft-ietf-dime-rfc3588bis-33 RFC3588 RFC5719 RFC7075 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=6733 10.17487/RFC6733
RFC6734 Diameter Attribute-Value Pairs for Cryptographic Key Transport G. Zorn Q. Wu V. Cakulev October 2012 ASCII 12643 7 AAA,ERP,MSK

Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. [STANDARDS-TRACK]

draft-ietf-dime-local-keytran-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6734
RFC6735 Diameter Priority Attribute-Value Pairs K. Carlberg Editor T. Taylor October 2012 ASCII 21793 10 AVP

This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. [STANDARDS-TRACK]

draft-ietf-dime-priority-avps-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=6735 10.17487/RFC6735
RFC6736 Diameter Network Address and Port Translation Control Application F. Brockners S. Bhandari V. Singh V. Fajardo October 2012 ASCII 138288 58 NAT control NAT44 NAT66 CGN BNG

This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK]

draft-ietf-dime-nat-control-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6736
RFC6737 The Diameter Capabilities Update Application K. Jiao G. Zorn October 2012 ASCII 12380 6

This document defines a new Diameter application and associated Command Codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. [STANDARDS-TRACK]

draft-ietf-dime-capablities-update-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6737
RFC6738 Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers V. Cakulev A. Lior S. Mizikovsky October 2012 ASCII 35536 17 Internet Key Exchange Protocol version 2

The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec Security Associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and Shared Key (SK).

Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2. This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK. [STANDARDS-TRACK]

draft-ietf-dime-ikev2-psk-diameter-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6738
RFC6739 Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol H. Schulzrinne H. Tschofenig October 2012 ASCII 52011 25 Location

The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.

The <mapping> element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service.

This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping> elements between two entities. Exchanging cached <mapping> elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping> element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ecrit-lost-sync-18 EXPERIMENTAL EXPERIMENTAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=6739 10.17487/RFC6739
RFC6740 Identifier-Locator Network Protocol (ILNP) Architectural Description RJ Atkinson SN Bhatti November 2012 ASCII 126139 53

This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-arch-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6740 10.17487/RFC6740
RFC6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations RJ Atkinson SN Bhatti November 2012 ASCII 93512 38

This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-eng-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6741
RFC6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti S. Rose November 2012 ASCII 42996 20

This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-dns-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6742 10.17487/RFC6742
RFC6743 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) RJ Atkinson SN Bhatti November 2012 ASCII 24972 12

This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-icmpv6-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6743
RFC6744 IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) RJ Atkinson SN Bhatti November 2012 ASCII 33737 14

The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-noncev6-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6744
RFC6745 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) RJ Atkinson SN Bhatti November 2012 ASCII 25137 12

This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-icmpv4-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6745
RFC6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti November 2012 ASCII 24866 11

This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-v4opts-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6746
RFC6747 Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) RJ Atkinson SN Bhatti November 2012 ASCII 24322 12

This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-arp-07 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6747
RFC6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti November 2012 ASCII 86535 37

This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-adv-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6748
RFC6749 The OAuth 2.0 Authorization Framework D. Hardt Editor October 2012 ASCII 163498 76 Client Resource Owner Authorization Server Resource Server Token Endpoint Authorization Endpoint Authorization Request Authorization Grant Protected Resource Access Token Refresh Token Authorization Code Implicit Grant Client Identifier Access Token Scope Delegation

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]

draft-ietf-oauth-v2-31 RFC5849 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6749 10.17487/RFC6749
RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage M. Jones D. Hardt October 2012 ASCII 38949 18 Client Resource Owner Authorization Server Resource Server, Token Endpoint Authorization Endpoint Authorization Request, Authorization Grant Protected Resource Access Token Refresh Token Authorization Code Implicit Grant Client Identifier, Access Token Scope Bearer Authorization Header Bearer Access Token Type

This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]

draft-ietf-oauth-v2-bearer-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC6750
RFC6751 Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44) R. Despres Editor B. Carpenter D. Wing S. Jiang October 2012 ASCII 73468 33 Coexistence Transition Interworking Tunneling Encapsulation Mapping map-and-encap Global Addressing

In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. This document defines an Experimental Protocol for the Internet community.

draft-despres-6a44-02 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6751 10.17487/RFC6751
RFC6752 Issues with Private IP Addressing in the Internet A. Kirkham September 2012 ASCII 31838 14

The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-grow-private-ip-sp-cores-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6752
RFC6753 A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) J. Winterbottom H. Tschofenig H. Schulzrinne M. Thomson October 2012 ASCII 49866 25 HELD Dereference lbyr HTTP Location GEOPRIV

This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. [STANDARDS-TRACK]

draft-ietf-geopriv-deref-protocol-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6753
RFC6754 Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect Y. Cai L. Wei H. Ou V. Arya S. Jethwani October 2012 ASCII 24599 12

A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. [STANDARDS-TRACK]

draft-ietf-pim-ecmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6754
RFC6755 An IETF URN Sub-Namespace for OAuth B. Campbell H. Tschofenig October 2012 ASCII 8336 5 OAuth URN sub-namespace urn:ietf:params:oauth

This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-oauth-urn-sub-ns-06 INFORMATIONAL INFORMATIONAL IETF sec oauth 10.17487/RFC6755
RFC6756 Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines S. Trowbridge Editor E. Lear Editor G. Fishman Editor S. Bradner Editor September 2012 ASCII 33355 16

This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T A Series Supplement 3 (07/2012).

Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to the ITU-T A-Series of Recommendations.

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-rfc3356bis-05 RFC3356 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=6756 10.17487/RFC6756
RFC6757 Access Network Identifier (ANI) Option for Proxy Mobile IPv6 S. Gundavelli Editor J. Korhonen Editor M. Grayson K. Leung R. Pazhyannur October 2012 ASCII 43863 19 ANI ANI option Access Network Identifier option PMIPv6 ANI option

The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. [STANDARDS-TRACK]

draft-ietf-netext-access-network-option-13 RFC7563 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6757
RFC6758 Tunneling of SMTP Message Transfer Priorities A. Melnikov K. Carlberg October 2012 ASCII 22159 11 Priority MMHS

This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-melnikov-smtp-priority-tunneling-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6758
RFC6759 Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) B. Claise P. Aitken N. Ben-Dvora November 2012 ASCII 83584 43

This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-claise-export-application-info-in-ipfix-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6759 10.17487/RFC6759
RFC6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) S. Cheshire M. Krochmal February 2013 ASCII 38212 16

One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.

draft-cheshire-dnsext-nbp-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6760
RFC6761 Special-Use Domain Names S. Cheshire M. Krochmal February 2013 ASCII 28862 13

This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.

draft-cheshire-dnsext-special-names-03 RFC1918 RFC2606 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6761
RFC6762 Multicast DNS S. Cheshire M. Krochmal February 2013 ASCII 184992 70

As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.

Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.

The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.

draft-cheshire-dnsext-multicastdns-15 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6762
RFC6763 DNS-Based Service Discovery S. Cheshire M. Krochmal February 2013 ASCII 125192 49

This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.

draft-cheshire-dnsext-dns-sd-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6763
RFC6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) C. Daboo February 2013 ASCII 28361 14 SRV iCalendar

This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.

draft-daboo-srv-caldav-10 RFC4791 RFC6352 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6764
RFC6765 xDSL Multi-Pair Bonding (G.Bond) MIB E. Beili M. Morgenstern February 2013 ASCII 154301 73 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding aggregation G.998 G.998.1 G.998.2 G.998.3 TDIM IMA EFM

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendations G.998.1, G.998.2, and G.998.3. The textual conventions defining the bonding schemes are contained in a separate MIB module maintained by Internet Assigned Numbers Authority (IANA). The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB, and G9983-MIB, respectively.

draft-ietf-adslmib-gbond-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6765 10.17487/RFC6765
RFC6766 xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB E. Beili February 2013 ASCII 107078 55 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding aggregation G.998.3

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), as defined in ITU-T Recommendation G.998.3.

draft-ietf-adslmib-gbond-tdim-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6766 10.17487/RFC6766
RFC6767 Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB E. Beili M. Morgenstern February 2013 ASCII 105415 53 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding Ethernet bonding aggregation 802.3ah G.998.2

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendation G.998.2.

draft-ietf-adslmib-gbond-eth-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6767 10.17487/RFC6767
RFC6768 ATM-Based xDSL Bonded Interfaces MIB E. Beili February 2013 ASCII 64283 34 Network Management Simple Network Management Protocol SNMP Management Information Base bonding xDSL bonding aggregation G.Bond G.Bond/ATM G.998.1 IMA IMA+

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1.

draft-ietf-adslmib-gbond-atm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6768 10.17487/RFC6768
RFC6769 Simple Virtual Aggregation (S-VA) R. Raszuk J. Heitz A. Lo L. Zhang X. Xu October 2012 ASCII 16565 8 BGP aggregation

All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into the Forwarding Information Base (FIB).

Some routers in an Autonomous System (AS) announce an aggregate (the VA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix.

The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-grow-simple-va-12 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6769
RFC6770 Use Cases for Content Delivery Network Interconnection G. Bertrand Editor E. Stephan T. Burbridge P. Eardley K. Ma G. Watson November 2012 ASCII 33281 16 CDN CDNI

Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-cdni-use-cases-10 RFC3570 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC6770
RFC6771 Considerations for Having a Successful "Bar BOF" Side Meeting L. Eggert G. Camarillo October 2012 ASCII 24724 10

New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "bar BOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.

During recent IETF meetings, many such "bar BOF" get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings.

This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term "bar BOF" and instead use other terms such as "side meeting", in order to stress the unofficial nature of these get-togethers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-eggert-successful-bar-bof-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6771
RFC6772 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information H. Schulzrinne Editor H. Tschofenig Editor J. Cuellar J. Polk J. Morris M. Thomson January 2013 ASCII 87801 44 Authorization Policy Location Privacy

This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.

Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. [STANDARDS-TRACK]

draft-ietf-geopriv-policy-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6772
RFC6773 DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal T. Phelan G. Fairhurst C. Perkins November 2012 ASCII 45073 20 DCCP NAPT NAT UDP

This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK]

draft-ietf-dccp-udpencap-11 RFC4340 RFC5762 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=6773 10.17487/RFC6773
RFC6774 Distribution of Diverse BGP Paths R. Raszuk Editor R. Fernando K. Patel D. McPherson K. Kumaki November 2012 ASCII 48316 22

The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.

The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, the Nth best path can be distributed. This document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path.

This proposal does not specify any changes to the BGP protocol definition. It does not require a software upgrade of provider edge (PE) routers acting as route reflector clients. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-grow-diverse-bgp-path-dist-08 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6774
RFC6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) Z. Shelby Editor S. Chakrabarti E. Nordmark C. Bormann November 2012 ASCII 130616 55

The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]

draft-ietf-6lowpan-nd-21 RFC4944 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan 10.17487/RFC6775
RFC6776 Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block A. Clark Q. Wu October 2012 ASCII 17259 9 RTP Control Protocol

This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. [STANDARDS-TRACK]

draft-ietf-xrblock-rtcp-xr-meas-identity-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6776
RFC6777 Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks W. Sun Editor G. Zhang Editor J. Gao G. Xie R. Papneja November 2012 ASCII 57725 29 Provisioning performance Performance measurement UNI Bandwidth on Demand performance evaluation Measurement methodologies

When setting up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. [STANDARDS-TRACK]

draft-ietf-ccamp-dpm-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6777
RFC6778 Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching R. Sparks October 2012 ASCII 15396 8 tool

The IETF makes heavy use of email lists to conduct its work. Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sparks-genarea-mailarch-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6778
RFC6779 Definition of Managed Objects for the Neighborhood Discovery Protocol U. Herberg R. Cole I. Chakeres October 2012 ASCII 131403 67 Network Management Management Information base MIB SMIv2 Routing Neighbor Discovery MANET

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. [STANDARDS-TRACK]

draft-ietf-manet-nhdp-mib-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC6779
RFC6780 RSVP ASSOCIATION Object Extensions L. Berger F. Le Faucheur A. Narayanan October 2012 ASCII 41252 17

The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]

draft-ietf-ccamp-assoc-ext-06 RFC2205 RFC3209 RFC3473 RFC4872 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6780
RFC6781 DNSSEC Operational Practices, Version 2 O. Kolkman W. Mekking R. Gieben December 2012 ASCII 161581 71 DNSSEC operational key rollover

This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.

The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.

This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.

draft-ietf-dnsop-rfc4641bis-13 RFC4641 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6781
RFC6782 Wireline Incremental IPv6 V. Kuarsingh Editor L. Howard November 2012 ASCII 71197 29 transition IPv6 transition operator

Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-wireline-incremental-ipv6-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6782
RFC6783 Mailing Lists and Non-ASCII Addresses J. Levine R. Gellens November 2012 ASCII 21960 9 Mail internationalization mailing lists

This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice. This document is a product of the Internet Engineering Task Force (IETF).

draft-ietf-eai-mailinglistbis-05 RFC5983 INFORMATIONAL INFORMATIONAL IETF app eai 10.17487/RFC6783
RFC6784 Kerberos Options for DHCPv6 S. Sakane M. Ishiyama November 2012 ASCII 24110 12 security dhcpv6

This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos. [STANDARDS-TRACK]

draft-sakane-dhc-dhcpv6-kdc-option-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6784
RFC6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve B. Leiba November 2012 ASCII 42644 20 email filtering

Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228. [STANDARDS-TRACK]

draft-ietf-sieve-imap-sieve-09 RFC5228 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6785
RFC6786 Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs A. Yegin R. Cragie November 2012 ASCII 21361 11

This document specifies a mechanism for delivering the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs (AVPs) in encrypted form. [STANDARDS-TRACK]

draft-yegin-pana-encr-avp-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6786
RFC6787 Media Resource Control Protocol Version 2 (MRCPv2) D. Burnett S. Shanmugham November 2012 ASCII 496648 224 mrcp speechsc asr tts speech services speech recognition speech synthesis nlsml speaker authentication speaker verification speaker identification

The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. [STANDARDS-TRACK]

draft-ietf-speechsc-mrcpv2-28 PROPOSED STANDARD PROPOSED STANDARD IETF rai speechsc http://www.rfc-editor.org/errata_search.php?rfc=6787 10.17487/RFC6787
RFC6788 The Line-Identification Option S. Krishnan A. Kavanagh B. Varga S. Ooghe E. Nordmark November 2012 ASCII 38410 17

In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router. This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router. [STANDARDS-TRACK]

draft-ietf-6man-lineid-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6788
RFC6789 Congestion Exposure (ConEx) Concepts and Use Cases B. Briscoe Editor R. Woundy Editor A. Cooper Editor December 2012 ASCII 41078 17 Congestion Signaling Traffic Management

This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-conex-concepts-uses-05 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC6789
RFC6790 The Use of Entropy Labels in MPLS Forwarding K. Kompella J. Drake S. Amante W. Henderickx L. Yong November 2012 ASCII 53837 25 entropy hash ecmp load balancing

Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]

draft-ietf-mpls-entropy-label-06 RFC3031 RFC3107 RFC3209 RFC5036 RFC7274 RFC7447 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6790 10.17487/RFC6790
RFC6791 Stateless Source Address Mapping for ICMPv6 Packets X. Li C. Bao D. Wing R. Vaithianathan G. Huston November 2012 ASCII 11793 6 IP/ICMP Translation Algorithm IPv4-translatable IPv6 addresses ICMPv6 traceroute

A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. [STANDARDS-TRACK]

draft-ietf-v6ops-ivi-icmp-address-07 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC6791
RFC6792 Guidelines for Use of the RTP Monitoring Framework Q. Wu Editor G. Hunt P. Arden November 2012 ASCII 42473 17 Real Time Control Protocol

This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks that cover their set of concerns. Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-avtcore-monarch-22 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC6792
RFC6793 BGP Support for Four-Octet Autonomous System (AS) Number Space Q. Vohra E. Chen December 2012 ASCII 26366 12 autonomous system border gateway protocol

The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]

draft-ietf-idr-rfc4893bis-07 RFC4893 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC6793
RFC6794 A Framework for Session Initiation Protocol (SIP) Session Policies V. Hilt G. Camarillo J. Rosenberg December 2012 ASCII 94464 36

Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. [STANDARDS-TRACK]

draft-ietf-sip-session-policy-framework-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC6794
RFC6795 A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies V. Hilt G. Camarillo December 2012 ASCII 42920 18

This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents (UAs) to subscribe to session policies for a SIP session and to receive notifications if these policies change. [STANDARDS-TRACK]

draft-ietf-sipping-policy-package-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC6795
RFC6796 A User Agent Profile Data Set for Media Policy V. Hilt G. Camarillo J. Rosenberg D. Worley December 2012 ASCII 88634 43 SIP Session Policy Data Set

This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions. Examples for media properties are the codecs or media types used in the session. This document also defines an XML document format to describe policies that limit the media properties of SIP sessions. [STANDARDS-TRACK]

draft-camarillo-rai-media-policy-dataset-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6796
RFC6797 HTTP Strict Transport Security (HSTS) J. Hodges C. Jackson A. Barth November 2012 ASCII 103554 46 HTTPS TLS SSL ForceHTTPS man-in-the-middle MITM certificate error certificate verification security policy secure transport IDNA-Canonicalization

This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]

draft-ietf-websec-strict-transport-sec-14 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=6797 10.17487/RFC6797
RFC6798 RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting A. Clark Q. Wu November 2012 ASCII 26901 13

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications. [STANDARDS-TRACK]

draft-ietf-xrblock-rtcp-xr-pdv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6798
RFC6801 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework U. Kozat A. Begen November 2012 ASCII 24923 11

This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-fecframe-pseudo-cdp-05 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6801
RFC6802 Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets S. Baillargeon C. Flinta A. Johnsson November 2012 ASCII 37309 15 available capacity rate train interval padding buffer test session

This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-twamp-value-added-octets-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6802
RFC6803 Camellia Encryption for Kerberos 5 G. Hudson November 2012 ASCII 23516 13 Camellia Kerberos

This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC 3961. The new types use the Camellia block cipher in CBC mode with ciphertext stealing and the CMAC algorithm for integrity protection. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-krb-wg-camellia-cts-02 INFORMATIONAL INFORMATIONAL IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=6803 10.17487/RFC6803
RFC6804 DISCOVER: Supporting Multicast DNS Queries B. Manning November 2012 ASCII 19946 9

This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. This project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. This document defines a Historic Document for the Internet community.

draft-manning-opcode-discover-07 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6804
RFC6805 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS D. King Editor A. Farrel Editor November 2012 ASCII 77669 33

Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture.

Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.

This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pce-hierarchy-fwk-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6805
RFC6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals S. Hartman Editor K. Raeburn L. Zhu November 2012 ASCII 47572 19 authentication security protocols identity

This memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm Ticket-Granting Ticket (TGT) to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120. [STANDARDS-TRACK]

draft-ietf-krb-wg-kerberos-referrals-15 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6806
RFC6807 Population Count Extensions to Protocol Independent Multicast (PIM) D. Farinacci G. Shepherd S. Venaas Y. Cai December 2012 ASCII 32114 15

This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the Protocol Independent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pim-pop-count-07 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC6807
RFC6808 Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track L. Ciavattone R. Geib A. Morton M. Wieser December 2012 ASCII 62061 29 One-way Delay IP Performance Metrics IPPM

This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-testplan-rfc2679-03 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6808
RFC6809 Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) C. Holmberg I. Sedlacek H. Kaplan November 2012 ASCII 40053 19 proxy feature feature tag feature-capability indicator Feature-Caps capability

This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.

SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.

This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]

draft-ietf-sipcore-proxy-feature-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6809
RFC6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol R. Bush R. Austein January 2013 ASCII 59714 27

In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK]

draft-ietf-sidr-rpki-rtr-26 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6810
RFC6811 BGP Prefix Origin Validation P. Mohapatra J. Scudder D. Ward R. Bush R. Austein January 2013 ASCII 20082 10 SIDR security

To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]

draft-ietf-sidr-pfx-validate-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6811
RFC6812 Cisco Service-Level Assurance Protocol M. Chiba A. Clemm S. Medley J. Salowey S. Thombare E. Yedavalli January 2013 ASCII 68237 27 Cisco's SLA Protocol

Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is a Performance Measurement protocol that has been widely deployed. The protocol is used to measure service-level parameters such as network latency, delay variation, and packet/frame loss. This document describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to enable vendor interoperability. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cisco-sla-protocol-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6812
RFC6813 The Network Endpoint Assessment (NEA) Asokan Attack Analysis J. Salowey S. Hanna December 2012 ASCII 15899 8 Man-in-the-Middle MITM Security Endpoint Posture Protocol Forwarding TNC Channel Binding Cryptographic Countermeasure

The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack. This document describes the attack and countermeasures that may be mounted. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-nea-asokan-02 INFORMATIONAL INFORMATIONAL IETF sec nea 10.17487/RFC6813
RFC6814 Formally Deprecating Some IPv4 Options C. Pignataro F. Gont November 2012 ASCII 11327 6

A number of IPv4 options have become obsolete in practice, but have never been formally deprecated. This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry. Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770, and requests that the RFC Editor change their status to Historic. [STANDARDS-TRACK]

draft-gp-intarea-obsolete-ipv4-options-iana-02 RFC1385 RFC1393 RFC1475 RFC1770 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6814
RFC6815 Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful S. Bradner K. Dubray J. McQuaid A. Morton November 2012 ASCII 22308 11 testing performance

The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity. Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods. This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-2544-as-08 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6815
RFC6816 Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME V. Roca M. Cunche J. Lacan December 2012 ASCII 49938 24 Forward Error Correction LDPC-Staircase

This document describes a fully specified simple Forward Error Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum.

draft-ietf-fecframe-ldpc-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6816
RFC6817 Low Extra Delay Background Transport (LEDBAT) S. Shalunov G. Hazel J. Iyengar M. Kuehlewind December 2012 ASCII 57813 25 Congestion control delay-based scavenger P2P

Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ledbat-congestion-10 EXPERIMENTAL EXPERIMENTAL IETF tsv ledbat 10.17487/RFC6817
RFC6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile P. Yee January 2013 ASCII 17439 8

This document updates RFC 5280, the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. [STANDARDS-TRACK]

draft-ietf-pkix-rfc5280-clarifications-11 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6818
RFC6819 OAuth 2.0 Threat Model and Security Considerations T. Lodderstedt Editor M. McGloin P. Hunt January 2013 ASCII 158332 71 authorization authentication token counter-measures HTTP REST

This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-oauth-v2-threatmodel-08 INFORMATIONAL INFORMATIONAL IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6819 10.17487/RFC6819
RFC6820 Address Resolution Problems in Large Data Center Networks T. Narten M. Karir I. Foo January 2013 ASCII 42650 17 ARMD data center ARP ND Neighbor Discovery

This document examines address resolution issues related to the scaling of data centers with a very large number of hosts. The scope of this document is relatively narrow, focusing on address resolution (the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery (ND) in IPv6) within a data center. This document is a product of the Internet Engineering Task Force (IETF).

draft-ietf-armd-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF ops armd 10.17487/RFC6820
RFC6821 Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality E. Marocco A. Fusco I. Rimac V. Gurbani December 2012 ASCII 33299 16 cross-domain traffic bandwidth transit traffic peer-to-peer caching peer-to-peer swarm

Peer-to-peer (P2P) traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been the subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study or studies that have addressed facts pertaining to the myth. Using these studies, the authors hope to either confirm or refute each specific myth.

This document is a product of the IRTF P2PRG (Peer-to-Peer Research Group).

draft-irtf-p2prg-mythbustering-03 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6821
RFC6822 IS-IS Multi-Instance S. Previdi Editor L. Ginsberg M. Shand A. Roy D. Ward December 2012 ASCII 30254 14 intermediate system to intermediate system

This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances.

Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.

draft-ietf-isis-mi-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6822
RFC6823 Advertising Generic Information in IS-IS L. Ginsberg S. Previdi M. Shand December 2012 ASCII 22708 11 intermediate system to intermediate system

This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information.

draft-ietf-isis-genapp-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6823
RFC6824 TCP Extensions for Multipath Operation with Multiple Addresses A. Ford C. Raiciu M. Handley O. Bonaventure January 2013 ASCII 164866 64

TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.

Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mptcp-multiaddressed-12 EXPERIMENTAL EXPERIMENTAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=6824 10.17487/RFC6824
RFC6825 Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS M. Miyazawa T. Otani K. Kumaki T. Nadeau January 2013 ASCII 72765 40 TED-MIB ted mib

This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-ted-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6825
RFC6826 Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths IJ. Wijnands Editor T. Eckert N. Leymann M. Napierala January 2013 ASCII 23927 12

Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), that needs to pass through an MPLS domain in which Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs. [STANDARDS-TRACK]

draft-ietf-mpls-mldp-in-band-signaling-08 RFC7438 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6826
RFC6827 Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols A. Malis Editor A. Lindem Editor D. Papadimitriou Editor January 2013 ASCII 73279 30

The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.

Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK]

draft-ietf-ccamp-rfc5787bis-06 RFC5787 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6827
RFC6828 Content Splicing for RTP Sessions J. Xia January 2013 ASCII 38904 17

Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.

This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-avtext-splicing-for-rtp-12 INFORMATIONAL INFORMATIONAL IETF rai avtext 10.17487/RFC6828
RFC6829 Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 M. Chen P. Pan C. Pignataro R. Asati January 2013 ASCII 15683 8

The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage.

This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6 LDP sessions. This document updates RFC 4379. [STANDARDS-TRACK]

draft-ietf-mpls-ipv6-pw-lsp-ping-04 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6829
RFC6830 The Locator/ID Separation Protocol (LISP) D. Farinacci V. Fuller D. Meyer D. Lewis January 2013 ASCII 189977 75

This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.

Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-24 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6830
RFC6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments D. Farinacci D. Meyer J. Zwiebel S. Venaas January 2013 ASCII 71901 28

This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-multicast-14 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6831
RFC6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites D. Lewis D. Meyer D. Farinacci V. Fuller January 2013 ASCII 43758 19

This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-interworking-06 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6832
RFC6833 Locator/ID Separation Protocol (LISP) Map-Server Interface V. Fuller D. Farinacci January 2013 ASCII 30144 13

This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.

By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-ms-16 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6833
RFC6834 Locator/ID Separation Protocol (LISP) Map-Versioning L. Iannone D. Saucez O. Bonaventure January 2013 ASCII 51447 21

This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-map-versioning-09 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6834
RFC6835 The Locator/ID Separation Protocol Internet Groper (LIG) D. Farinacci D. Meyer January 2013 ASCII 26810 12

A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-lisp-lig-06 INFORMATIONAL INFORMATIONAL IETF int lisp 10.17487/RFC6835
RFC6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) V. Fuller D. Farinacci D. Meyer D. Lewis January 2013 ASCII 62093 25

This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE). This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-alt-11 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6836
RFC6837 NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database E. Lear January 2013 ASCII 72499 31

The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to- RLOC mappings scales well to at least 10^8 entries. This document defines an Experimental Protocol for the Internet community.

draft-lear-lisp-nerd-09 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6837
RFC6838 Media Type Specifications and Registration Procedures N. Freed J. Klensin T. Hansen January 2013 ASCII 72942 32

This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.

draft-ietf-appsawg-media-type-regs-14 RFC4288 BCP0013 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg 10.17487/RFC6838
RFC6839 Additional Media Type Structured Syntax Suffixes T. Hansen A. Melnikov January 2013 ASCII 26071 14 structured syntax suffix media type

A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-appsawg-media-type-suffix-regs-08 RFC3023 RFC7303 INFORMATIONAL INFORMATIONAL IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6839 10.17487/RFC6839
RFC6840 Clarifications and Implementation Notes for DNS Security (DNSSEC) S. Weiler Editor D. Blacka Editor February 2013 ASCII 47283 21 EAP AAA reconnect

This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.

This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.

draft-ietf-dnsext-dnssec-bis-updates-20 RFC4033 RFC4034 RFC4035 RFC5155 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6840 10.17487/RFC6840
RFC6841 A Framework for DNSSEC Policies and DNSSEC Practice Statements F. Ljunggren AM. Eklund Lowinder T. Okubo January 2013 ASCII 57936 27 DNS DNSSEC DP DPS

This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.

In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dnsop-dnssec-dps-framework-11 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6841
RFC6842 Client Identifier Option in DHCP Server Replies N. Swamy G. Halwasia P. Jhingran January 2013 ASCII 10030 5

This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. [STANDARDS-TRACK]

draft-ietf-dhc-client-id-07 RFC2131 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6842
RFC6843 RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting A. Clark K. Gross Q. Wu January 2013 ASCII 18354 9 Round Trip Delay End System Delay

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK]

draft-ietf-xrblock-rtcp-xr-delay-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6843
RFC6844 DNS Certification Authority Authorization (CAA) Resource Record P. Hallam-Baker R. Stradling January 2013 ASCII 36848 18 DNS DNSSEC PKIX

The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK]

draft-ietf-pkix-caa-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6844 10.17487/RFC6844
RFC6845 OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type N. Sheth L. Wang J. Zhang January 2013 ASCII 17019 9 OSPF P2MP Broadcast Interface

This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as Link State Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.

This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). [STANDARDS-TRACK]

draft-ietf-ospf-hybrid-bcast-and-p2mp-06 RFC2328 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC6845
RFC6846 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) G. Pelletier K. Sandlund L-E. Jonsson M. West January 2013 ASCII 187518 96

This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.

This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. [STANDARDS-TRACK]

draft-sandlund-rfc4996bis-02 RFC4996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6846 10.17487/RFC6846
RFC6847 Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL) D. Melman T. Mizrahi D. Eastlake 3rd January 2013 ASCII 28693 13 FCoE FCRB TRILL RBridge

Fibre Channel over Ethernet (FCoE) and Transparent Interconnection of Lots of Links (TRILL) are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's Media Access Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mme-trill-fcoe-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6847
RFC6848 Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO) J. Winterbottom M. Thomson R. Barnes B. Rosen R. George January 2013 ASCII 41081 21 Extension Local Civic Location GEOPRIV

New fields are occasionally added to civic addresses. A backward- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. [STANDARDS-TRACK]

draft-ietf-geopriv-local-civic-10 RFC4776 RFC5222 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6848
RFC6849 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback H. Kaplan Editor K. Hedayat N. Venna P. Jones N. Stratton February 2013 ASCII 66214 33 multimedia audio video RTCP diagnostic voip

The wide deployment of Voice over IP (VoIP), real-time text, and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, real-time text, or Video over IP service. Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, real-time text, and Video over IP performance metrics.

draft-ietf-mmusic-media-loopback-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6849
RFC6850 Definitions of Managed Objects for Routing Bridges (RBridges) A. Rijhsinghani K. Zebrose January 2013 ASCII 104287 59

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a Routing Bridge (RBridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. [STANDARDS-TRACK]

draft-ietf-trill-rbridge-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6850
RFC6851 Internet Message Access Protocol (IMAP) - MOVE Extension A. Gulbrandsen N. Freed Editor January 2013 ASCII 15689 8 IMAP

This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. [STANDARDS-TRACK]

draft-ietf-imapmove-command-05 PROPOSED STANDARD PROPOSED STANDARD IETF app imapmove 10.17487/RFC6851
RFC6852 Affirmation of the Modern Paradigm for Standards R. Housley S. Mills J. Jaffe B. Aboba L. St.Amour January 2013 ASCII 9696 5

On 29 August 2012, the leaders of the IEEE Standards Association, the IAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards. These principles have become known as the "OpenStand" principles. This document contains the text of the affirmation that was signed. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-modern-paradigm-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6852
RFC6853 DHCPv6 Redundancy Deployment Considerations J. Brzozowski J. Tremblay J. Chen T. Mrugalski February 2013 ASCII 34209 16 DHCPv6 Redundancy Deployment Considerations

This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services.

draft-ietf-dhc-dhcpv6-redundancy-consider-03 BCP0180 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc 10.17487/RFC6853
RFC6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields B. Leiba March 2013 ASCII 20190 9

The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations.

draft-leiba-5322upd-from-group-09 RFC5322 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6854
RFC6855 IMAP Support for UTF-8 P. Resnick Editor C. Newman Editor S. Shen Editor March 2013 ASCII 24370 12 IMAP IDNA

This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738.

draft-ietf-eai-5738bis-12 RFC5738 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6855 10.17487/RFC6855
RFC6856 Post Office Protocol Version 3 (POP3) Support for UTF-8 R. Gellens C. Newman J. Yao K. Fujiwara March 2013 ASCII 26790 14 internationalized

This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings.

draft-ietf-eai-rfc5721bis-08 RFC5721 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6856
RFC6857 Post-Delivery Message Downgrading for Internationalized Email Messages K. Fujiwara March 2013 ASCII 39255 20 EAI Email Address Internationalization Downgrade MAIL

The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.

draft-ietf-eai-popimap-downgrade-08 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6857 10.17487/RFC6857
RFC6858 Simplified POP and IMAP Downgrading for Internationalized Email A. Gulbrandsen March 2013 ASCII 12169 6

This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results.

draft-ietf-eai-simpledowngrade-07 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6858
RFC6859 Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership B. Leiba January 2013 ASCII 5619 3 nomcom IAOC

RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative Oversight Committee (IAOC) was formed; that body is not covered by RFC 3777. There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of the IAB, the IESG, and the IAOC. This memo documents an Internet Best Current Practice.

draft-leiba-3777upd-eligibility-06 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6859
RFC6860 Hiding Transit-Only Networks in OSPF Y. Yang A. Retana A. Roy January 2013 ASCII 26368 13

A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.

In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2.

This document updates RFCs 2328 and 5340. [STANDARDS-TRACK]

draft-ietf-ospf-prefix-hiding-07 RFC2328 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6860 10.17487/RFC6860
RFC6861 The "create-form" and "edit-form" Link Relations I. Dzmanashvili January 2013 ASCII 8191 6

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ioseb-dzmanashvili-link-relation-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6861
RFC6862 Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements G. Lebovitz M. Bhatia B. Weis March 2013 ASCII 67802 26

Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.

draft-ietf-karp-threats-reqs-07 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6862
RFC6863 Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide S. Hartman D. Zhang March 2013 ASCII 26996 11

This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.

draft-ietf-karp-ospf-analysis-06 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6863
RFC6864 Updated Specification of the IPv4 ID Field J. Touch February 2013 ASCII 44418 19

The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK]

draft-ietf-intarea-ipv4-id-update-07 RFC0791 RFC1122 RFC2003 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC6864
RFC6865 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME V. Roca M. Cunche J. Lacan A. Bouabdallah K. Matsuzono February 2013 ASCII 48493 23 Forward Error Correction Reed-Solomon

This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.

draft-ietf-fecframe-simple-rs-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6865
RFC6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks B. Carpenter S. Jiang February 2013 ASCII 26524 11

This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.

draft-ietf-6renum-static-problem-03 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC6866
RFC6867 An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP) Y. Nir Q. Wu January 2013 ASCII 19322 9

This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696. This document defines an Experimental Protocol for the Internet community.

draft-nir-ipsecme-erx-11 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6867
RFC6868 Parameter Value Encoding in iCalendar and vCard C. Daboo February 2013 ASCII 11025 7 calendar contact

This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.

draft-daboo-ical-vcard-parameter-encoding-04 RFC5545 RFC6321 RFC6350 RFC6351 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6868 10.17487/RFC6868
RFC6869 vCard KIND:device G. Salgueiro J. Clarke P. Saint-Andre February 2013 ASCII 14648 9 vCard

This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). [STANDARDS-TRACK]

draft-salgueiro-vcarddav-kind-device-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6869
RFC6870 Pseudowire Preferential Forwarding Status Bit P. Muley Editor M. Aissaoui Editor February 2013 ASCII 79254 35 PW redundancy active PW standby PW primary PW secondary PW PW precedence

This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured between Provider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes in Multi-Segment Pseudowire (MS-PW) applications.

In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates a Preferential Forwarding status with a value of active or standby for each PW in a redundant set.

In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW.

Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV.

draft-ietf-pwe3-redundancy-bit-09 RFC4447 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 http://www.rfc-editor.org/errata_search.php?rfc=6870 10.17487/RFC6870
RFC6871 Session Description Protocol (SDP) Media Capabilities Negotiation R. Gilman R. Even F. Andreasen February 2013 ASCII 124829 55 Session Capabilities Latent Configurations Media Format Capability

Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.

This document updates the IANA Considerations of RFC 5939.

draft-ietf-mmusic-sdp-media-capabilities-17 RFC5939 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6871
RFC6872 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model V. Gurbani Editor E. Burger Editor T. Anjali H. Abdelnur O. Festor February 2013 ASCII 72134 39 logging analytics information model

Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.

draft-ietf-sipclf-problem-statement-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipclf 10.17487/RFC6872
RFC6873 Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) G. Salgueiro V. Gurbani A. B. Roach February 2013 ASCII 63449 28 SIPCLF

The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.

draft-ietf-sipclf-format-11 RFC7355 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipclf 10.17487/RFC6873
RFC6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers B. Carpenter S. Cheshire R. Hinden February 2013 ASCII 19361 10

This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.

draft-ietf-6man-uri-zoneid-06 RFC3986 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6874 10.17487/RFC6874
RFC6875 The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan S. Kamei T. Momose T. Inoue T. Nishitani February 2013 ASCII 41572 18 overlay network content delivery network peer-to-peer traffic engineering experiments in Japan

This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic. These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure. Based on what was learned from these experiments, this document provides some suggestions that might be useful for the ALTO architecture and especially for application-independent ALTO- like server operation.

draft-kamei-p2p-experiments-japan-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6875
RFC6876 A Posture Transport Protocol over TLS (PT-TLS) P. Sangster N. Cam-Winget J. Salowey February 2013 ASCII 109852 44 Network Endpoint Assessment NEA

This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel.

draft-ietf-nea-pt-tls-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea 10.17487/RFC6876
RFC6877 464XLAT: Combination of Stateful and Stateless Translation M. Mawatari M. Kawashima C. Byrne April 2013 ASCII 31382 14 XLAT Stateful Translation Stateless Translation

This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.

draft-ietf-v6ops-464xlat-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6877
RFC6878 IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field A.B. Roach March 2013 ASCII 4688 3

This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261.

draft-ietf-sipcore-priority-00 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6878 10.17487/RFC6878
RFC6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods S. Jiang B. Liu B. Carpenter February 2013 ASCII 38833 17

This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.

draft-ietf-6renum-enterprise-06 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC6879
RFC6880 An Information Model for Kerberos Version 5 L. Johansson March 2013 ASCII 28121 14 kerberos kdc LDAP schema

This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center (KDC). This document describes the services exposed by an administrative interface to a KDC.

draft-ietf-krb-wg-kdc-model-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6880
RFC6881 Best Current Practice for Communications Services in Support of Emergency Calling B. Rosen J. Polk March 2013 ASCII 63007 28 SIP emergency emergency calls emergency call emergency calling 9-1-1 1-1-2 ecrit

The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.

draft-ietf-ecrit-phonebcp-20 BCP0181 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai ecrit 10.17487/RFC6881
RFC6882 Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs) K. Kumaki Editor T. Murai D. Cheng S. Matsushima P. Jiang March 2013 ASCII 33125 15

IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.

The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs.

draft-kumaki-murai-l3vpn-rsvp-te-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6882
RFC6883 IPv6 Guidance for Internet Content Providers and Application Service Providers B. Carpenter S. Jiang March 2013 ASCII 60430 24

This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.

draft-ietf-v6ops-icp-guidance-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6883
RFC6884 RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) Z. Fang March 2013 ASCII 43207 21 EVRC-WB EVRC-B

This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.

draft-ietf-avt-rtp-evrc-nw-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6884
RFC6885 Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS) M. Blanchet A. Sullivan March 2013 ASCII 72167 34

If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated, or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement.

draft-ietf-precis-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF app precis 10.17487/RFC6885
RFC6886 NAT Port Mapping Protocol (NAT-PMP) S. Cheshire M. Krochmal April 2013 ASCII 87891 33

This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.

draft-cheshire-nat-pmp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6886 10.17487/RFC6886
RFC6887 Port Control Protocol (PCP) D. Wing Editor S. Cheshire M. Boucadair R. Penno P. Selkirk April 2013 ASCII 221314 88 NAT Firewall

The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.

draft-ietf-pcp-base-29 RFC7488 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp http://www.rfc-editor.org/errata_search.php?rfc=6887 10.17487/RFC6887
RFC6888 Common Requirements for Carrier-Grade NATs (CGNs) S. Perreault Editor I. Yamagata S. Miyakawa A. Nakagawa H. Ashida April 2013 ASCII 32484 15 CGN NAT

This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787.

draft-ietf-behave-lsn-requirements-10 RFC4787 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC6888
RFC6889 Analysis of Stateful 64 Translation R. Penno T. Saxena M. Boucadair S. Sivakumar April 2013 ASCII 33171 15 NAT64 DNS64 NAT-PT ALG (Application Layer Gateway) NAT traversal IPv4-IPv6 interconnection IPv4-IPv6 translation

Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.

draft-ietf-behave-64-analysis-07 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC6889
RFC6890 Special-Purpose IP Address Registries M. Cotton L. Vegoda R. Bonica Editor B. Haberman April 2013 ASCII 48326 23 Internet Protocol space assignments

This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.

draft-bonica-special-purpose-07 RFC4773 RFC5156 RFC5735 RFC5736 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6890 10.17487/RFC6890
RFC6891 Extension Mechanisms for DNS (EDNS(0)) J. Damas M. Graff P. Vixie April 2013 ASCII 32856 16 DNS extensions domain name system resource records opt

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.

This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.

draft-ietf-dnsext-rfc2671bis-edns0-10 RFC2671 RFC2673 STD0075 INTERNET STANDARD INTERNET STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6891 10.17487/RFC6891
RFC6892 The 'describes' Link Relation Type E. Wilde March 2013 ASCII 10846 5

This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.

draft-wilde-describes-link-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6892
RFC6893 A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF) P. Higgs P. Szucs March 2013 ASCII 12403 8

This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF.

draft-higgs-oipf-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6893
RFC6894 Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection R. Papneja S. Vapiwala J. Karthik S. Poretsky S. Rao JL. Le Roux March 2013 ASCII 64597 35

This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms for link and node protection. This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS Traffic Engineered (MPLS-TE) tunnels.

draft-ietf-bmwg-protection-meth-14 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6894
RFC6895 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd April 2013 ASCII 38979 19 RRTYPE RCODE AFSDB

This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.

draft-ietf-dnsext-rfc6195bis-05 RFC6195 RFC1183 RFC2845 RFC2930 RFC3597 BCP0042 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC6895
RFC6896 SCS: KoanLogic's Secure Cookie Sessions for HTTP S. Barbato S. Dorigotti T. Fossati Editor March 2013 ASCII 44175 23 HTTP Secure Cookies

This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.

Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content via HTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, Home Office (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering.

draft-secure-cookie-session-protocol-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6896 10.17487/RFC6896
RFC6897 Multipath TCP (MPTCP) Application Interface Considerations M. Scharf A. Ford March 2013 ASCII 75704 31

Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.

draft-ietf-mptcp-api-07 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC6897
RFC6898 Link Management Protocol Behavior Negotiation and Configuration Modifications D. Li D. Ceccarelli L. Berger March 2013 ASCII 21446 11 LMP

The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled by Generalized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.

This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.

draft-ietf-ccamp-lmp-behavior-negotiation-11 RFC4204 RFC4207 RFC4209 RFC5818 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6898
RFC6901 JavaScript Object Notation (JSON) Pointer P. Bryan Editor K. Zyp M. Nottingham Editor April 2013 ASCII 13037 8

JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.

draft-ietf-appsawg-json-pointer-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6901 10.17487/RFC6901
RFC6902 JavaScript Object Notation (JSON) Patch P. Bryan Editor M. Nottingham Editor April 2013 ASCII 26405 18

JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents.

draft-ietf-appsawg-json-patch-10 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6902 10.17487/RFC6902
RFC6903 Additional Link Relation Types J. Snell March 2013 ASCII 10452 6 http link rel

This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.

draft-snell-additional-link-relations-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6903
RFC6904 Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) J. Lennox April 2013 ASCII 33486 15 real-time transport protocol rtp header extensions security

The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.

This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.

draft-ietf-avtcore-srtp-encrypted-header-ext-05 RFC3711 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6904
RFC6905 Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) T. Senevirathne D. Bond S. Aldrin Y. Li R. Watve March 2013 ASCII 24278 13

Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (TRILL).

draft-ietf-trill-oam-req-05 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC6905
RFC6906 The 'profile' Link Relation Type E. Wilde March 2013 ASCII 18469 8 application profile profile identifier

This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.

draft-wilde-profile-link-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6906
RFC6907 Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties T. Manderson K. Sriram R. White March 2013 ASCII 66099 31 Prefix origin validation Routing security BGP security

This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.

draft-ietf-sidr-usecases-06 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6907
RFC6908 Deployment Considerations for Dual-Stack Lite Y. Lee R. Maglione C. Williams C. Jacquenet M. Boucadair March 2013 ASCII 35359 14

This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.

draft-ietf-softwire-dslite-deployment-08 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC6908
RFC6909 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 S. Gundavelli Editor X. Zhou J. Korhonen G. Feige R. Koodli April 2013 ASCII 34575 14

This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session. Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network.

draft-ietf-netext-pmipv6-sipto-option-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6909
RFC6910 Completion of Calls for the Session Initiation Protocol (SIP) D. Worley M. Huelsemann R. Jesske D. Alexeitsev April 2013 ASCII 86166 37 call completion CC SS7 Signaling System 7 purpose header parameter m URI parameter m header parameter call-completion event package, CCBS CCNR CCNL Call-Info header field Presence Information Data Format PIDF P-Asserted-Identity header field

The "completion of calls" feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call.

For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'Automatic Redial' in "Session Initiation Protocol Service Examples" (RFC 5359).

For the realization of a more comprehensive solution with queuing, this document introduces an architecture for implementing these features in the Session Initiation Protocol where "completion of calls" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for completion of calls into a queue at the callee's endpoint; when a caller's request is ready to be serviced, re-attempt of the original, failed call is then made.

The architecture is designed to interoperate well with existing completion of calls solutions in other networks.

draft-ietf-bliss-call-completion-19 PROPOSED STANDARD PROPOSED STANDARD IETF rai bliss 10.17487/RFC6910
RFC6911 RADIUS Attributes for IPv6 Access Networks W. Dec Editor B. Sarikaya G. Zorn Editor D. Miles B. Lourdelet April 2013 ASCII 28123 15 AAA RADIUS IPv6

This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing.

draft-ietf-radext-ipv6-access-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC6911
RFC6912 Principles for Unicode Code Point Inclusion in Labels in the DNS A. Sullivan D. Thaler J. Klensin O. Kolkman April 2013 ASCII 27078 12

Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points. Most operators of zones should probably not permit registration of U-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.

draft-iab-dns-zone-codepoint-pples-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6912
RFC6913 Indicating Fax over IP Capability in the Session Initiation Protocol (SIP) D. Hanes G. Salgueiro K. Fleming March 2013 ASCII 18119 9 media feature tag

This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP). Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.

draft-hanes-dispatch-fax-capability-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6913
RFC6914 SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP) J. Rosenberg April 2013 ASCII 35472 15 SIP SIMPLE presence IM

The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other.

draft-ietf-simple-simple-09 INFORMATIONAL INFORMATIONAL IETF rai simple 10.17487/RFC6914
RFC6915 Flow Identity Extension for HTTP-Enabled Location Delivery (HELD) R. Bellis April 2013 ASCII 14175 9 HELD Flow

RFC 6155 specifies an extension for the HTTP-Enabled Location Delivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.

However, certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request.

This document specifies an XML Schema and a URN Sub-Namespace for a Flow Identity Extension for HELD to support this requirement.

This document updates RFC 6155 by deprecating the port number elements specified therein.

draft-ietf-geopriv-flow-identity-02 RFC6155 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6915
RFC6916 Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) R. Gagliano S. Kent S. Turner April 2013 ASCII 48395 20 Resource Public Key Infrastructure RPKI Algorithm Transition SIDR routing security BGP security

This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).

draft-ietf-sidr-algorithm-agility-12 BCP0182 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC6916
RFC6917 Media Resource Brokering C. Boulton L. Miniero G. Munson April 2013 ASCII 280399 136

The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers.

draft-ietf-mediactrl-mrb-19 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6917
RFC6918 Formally Deprecating Some ICMPv4 Message Types F. Gont C. Pignataro April 2013 ASCII 13639 8 IANA IPv4 Options

A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.

draft-gp-obsolete-icmp-types-iana-01 RFC1788 RFC0792 RFC0950 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6918
RFC6919 Further Key Words for Use in RFCs to Indicate Requirement Levels R. Barnes S. Kent E. Rescorla April 1 2013 ASCII 11076 6

RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.

draft-barnes-2119bis-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6919
RFC6920 Naming Things with Hashes S. Farrell D. Kutscher C. Dannewitz B. Ohlman A. Keranen P. Hallam-Baker April 2013 ASCII 54124 23 Cryptography URI Information Centric Networking

This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.

draft-farrell-decade-ni-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6920 10.17487/RFC6920
RFC6921 Design Considerations for Faster-Than-Light (FTL) Communication R. Hinden April 1 2013 ASCII 15100 7

We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.

draft-hinden-FTL-design-considerations-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6921
RFC6922 The application/sql Media Type Y. Shafranovich April 2013 ASCII 8453 5 SQL MIME

This document registers the application/sql media type to be used for the Structured Query Language (SQL).

draft-shafranovich-mime-sql-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6922
RFC6923 MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions R. Winter E. Gray H. van Helvoort M. Betts May 2013 ASCII 23811 12

This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T).

draft-ietf-mpls-tp-itu-t-identifiers-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6923
RFC6924 Registration of Second-Level URN Namespaces under "ietf" B. Leiba April 2013 ASCII 5952 4

RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of "ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf".

draft-leiba-urnbis-ietf-namespace-02 RFC2648 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6924
RFC6925 The DHCPv4 Relay Agent Identifier Sub-Option B. Joshi R. Desetti M. Stapp April 2013 ASCII 17664 8 DHCP relay

This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends.

draft-ietf-dhc-relay-id-suboption-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6925
RFC6926 DHCPv4 Bulk Leasequery K. Kinnear M. Stapp R. Desetti B. Joshi N. Russell P. Kurapati B. Volz April 2013 ASCII 88215 41

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.

draft-ietf-dhc-dhcpv4-bulk-leasequery-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6926
RFC6927 Variants in Second-Level Names Registered in Top-Level Domains J. Levine P. Hoffman May 2013 ASCII 39615 18 DNS variant TLDs

Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS. Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of the IETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA.

draft-levine-tld-variant-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6927
RFC6928 Increasing TCP's Initial Window J. Chu N. Dukkipati Y. Cheng M. Mathis April 2013 ASCII 56523 24

This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.

draft-ietf-tcpm-initcwnd-08 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6928
RFC6929 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions A. DeKok A. Lior April 2013 ASCII 133099 68

The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.

draft-ietf-radext-radius-extensions-13 RFC2865 RFC3575 RFC6158 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC6929
RFC6930 RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) D. Guo S. Jiang Editor R. Despres R. Maglione April 2013 ASCII 23573 12

The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.

draft-ietf-softwire-6rd-radius-attrib-11 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6930 10.17487/RFC6930
RFC6931 Additional XML Security Uniform Resource Identifiers (URIs) D. Eastlake 3rd April 2013 ASCII 75220 36

This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051.

draft-eastlake-additional-xmlsec-uris-10 RFC4051 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6931 10.17487/RFC6931
RFC6932 Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry D. Harkins Editor May 2013 ASCII 20785 12 elliptic curve Diffie-Hellman

This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.

draft-harkins-brainpool-ike-groups-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6932
RFC6933 Entity MIB (Version 4) A. Bierman D. Romascanu J. Quittek M. Chandramouli May 2013 ASCII 165278 76 management information base snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.

draft-ietf-eman-rfc4133bis-06 RFC4133 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman http://www.rfc-editor.org/errata_search.php?rfc=6933 10.17487/RFC6933
RFC6934 Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs) N. Bitar Editor S. Wadhwa Editor T. Haag H. Li June 2013 ASCII 104111 39

The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs). The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives.

draft-ietf-ancp-pon-05 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC6934
RFC6935 IPv6 and UDP Checksums for Tunneled Packets M. Eubanks P. Chimento M. Westerlund April 2013 ASCII 29055 12 Tunnel Encapsulation Integrity Packet Corruption Middlebox

This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.

draft-ietf-6man-udpchecksums-08 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6935 10.17487/RFC6935
RFC6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums G. Fairhurst M. Westerlund April 2013 ASCII 99557 40

This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.

draft-ietf-6man-udpzero-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6936 10.17487/RFC6936
RFC6937 Proportional Rate Reduction for TCP M. Mathis N. Dukkipati Y. Cheng May 2013 ASCII 39437 16 TCP loss recovery packet conservation self clock

This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.

draft-ietf-tcpm-proportional-rate-reduction-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6937
RFC6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID J. Scudder May 2013 ASCII 3875 3 BGP

This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC.

draft-ietf-idr-deprecate-dpa-etal-00 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC6938
RFC6939 Client Link-Layer Address Option in DHCPv6 G. Halwasia S. Bhandari W. Dec May 2013 ASCII 14739 7

This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.

draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6939
RFC6940 REsource LOcation And Discovery (RELOAD) Base Protocol C. Jennings B. Lowekamp Editor E. Rescorla S. Baset H. Schulzrinne January 2014 ASCII 403862 176 p2p dht p2psip chord peer to peer

This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.

draft-ietf-p2psip-base-26 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip http://www.rfc-editor.org/errata_search.php?rfc=6940 10.17487/RFC6940
RFC6941 MPLS Transport Profile (MPLS-TP) Security Framework L. Fang Editor B. Niven-Jenkins Editor S. Mansfield Editor R. Graveman Editor April 2013 ASCII 27119 15 threats mitigation defensive techniques

This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLS Networks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionality of a packet transport network.

draft-ietf-mpls-tp-security-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6941
RFC6942 Diameter Support for the EAP Re-authentication Protocol (ERP) J. Bournelle L. Morand S. Decugis Q. Wu G. Zorn May 2013 ASCII 35357 18

The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.

draft-ietf-dime-erp-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6942
RFC6943 Issues in Identifier Comparison for Security Purposes D. Thaler Editor May 2013 ASCII 62676 26 Canonicalization Normalization Hostname URI IRI

Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.

draft-iab-identifier-comparison-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6943
RFC6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status S. Rose April 2013 ASCII 13876 7

The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.

draft-ietf-dnsext-dnssec-algo-imp-status-04 RFC2536 RFC2539 RFC3110 RFC4034 RFC4398 RFC5155 RFC5702 RFC5933 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6944 10.17487/RFC6944
RFC6945 Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol R. Bush B. Wijnen K. Patel M. Baer May 2013 ASCII 52515 25

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol.

draft-ietf-sidr-rpki-rtr-protocol-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6945
RFC6946 Processing of IPv6 "Atomic" Fragments F. Gont May 2013 ASCII 18843 9 fragmentation attacks vulnerabilities atomic fragments

The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.

draft-ietf-6man-ipv6-atomic-fragments-04 RFC2460 RFC5722 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6946 10.17487/RFC6946
RFC6947 The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute M. Boucadair H. Kaplan R. Gilman S. Veikkolainen May 2013 ASCII 51910 24

This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax.

The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required, Interactive Connectivity Establishment (ICE), as specified in RFC 5245, provides such a solution.

draft-boucadair-mmusic-altc-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6947
RFC6948 Some Measurements on World IPv6 Day from an End-User Perspective A. Keranen J. Arkko July 2013 ASCII 25416 11 PDF 114829

During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services. Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.

draft-keranen-ipv6day-measurements-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6948
RFC6949 RFC Series Format Requirements and Future Development H. Flanagan N. Brownlee May 2013 ASCII 29181 14

This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.

draft-iab-rfcformatreq-03 RFC2223 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6949
RFC6950 Architectural Considerations on Application Features in the DNS J. Peterson O. Kolkman H. Tschofenig B. Aboba October 2013 ASCII 85548 31

A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.

draft-iab-dns-applications-07 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6950
RFC6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication M. Tuexen R. Stewart May 2013 ASCII 25676 12

This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.

Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.

This document covers only end-hosts and not tunneling (egress or ingress) endpoints.

draft-ietf-tsvwg-sctp-udp-encaps-14 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6951
RFC6952 Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide M. Jethanandani K. Patel L. Zheng May 2013 ASCII 37969 17 key authentication routing DoS

This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.

draft-ietf-karp-routing-tcp-analysis-07 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6952
RFC6953 Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements A. Mancuso Editor S. Probasco B. Patil May 2013 ASCII 53560 23

Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented.

draft-ietf-paws-problem-stmt-usecases-rqmts-15 INFORMATIONAL INFORMATIONAL IETF app paws 10.17487/RFC6953
RFC6954 Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2) J. Merkle M. Lochter July 2013 ASCII 20366 11 IKE Elliptic Curve

This document specifies use of the Elliptic Curve Cryptography (ECC) Brainpool elliptic curve groups for key exchange in the Internet Key Exchange Protocol version 2 (IKEv2).

draft-merkle-ikev2-ke-brainpool-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6954
RFC6955 Diffie-Hellman Proof-of-Possession Algorithms J. Schaad H. Prafullchandra May 2013 ASCII 81491 43 POP ECDH DH

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.

This document obsoletes RFC 2875.

draft-schaad-pkix-rfc2875-bis-08 RFC2875 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6955
RFC6956 Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library W. Wang E. Haleplidis K. Ogawa C. Li J. Halpern June 2013 ASCII 236056 111 ForCES LFB Library

This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions.

draft-ietf-forces-lfb-lib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC6956
RFC6957 Duplicate Address Detection Proxy F. Costa J-M. Combes Editor X. Pougnard H. Li June 2013 ASCII 32537 16 IPv6 SLAAC DAD SAVI

The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address.

draft-ietf-6man-dad-proxy-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6957
RFC6958 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting A. Clark S. Zhang J. Zhao Q. Wu Editor May 2013 ASCII 31057 16 Real Time Control Protocol

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6958
RFC6959 Source Address Validation Improvement (SAVI) Threat Scope D. McPherson F. Baker J. Halpern May 2013 ASCII 62217 25

The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.

draft-ietf-savi-threat-scope-08 INFORMATIONAL INFORMATIONAL IETF int savi 10.17487/RFC6959
RFC6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP S. Santesson M. Myers R. Ankney A. Malpani S. Galperin C. Adams June 2013 ASCII 82037 41 PKIX digital security ocsp

This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.

draft-ietf-pkix-rfc2560bis-20 RFC2560 RFC6277 RFC5912 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6960
RFC6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension Y. Pettersen June 2013 ASCII 21473 10 RFC 6066 RFC 2560 RFC 6960 RFC 5246 OCSP OCSP stapling multi-stapling certificate status checking revocation information status_request status_request_v2

This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.

draft-ietf-tls-multiple-cert-status-extension-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC6961
RFC6962 Certificate Transparency B. Laurie A. Langley E. Kasper June 2013 ASCII 55048 27 TLS certificates

This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.

Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

draft-laurie-pki-sunlight-12 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6962 10.17487/RFC6962
RFC6963 A Uniform Resource Name (URN) Namespace for Examples P. Saint-Andre May 2013 ASCII 11749 7 URN examples documentation

This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.

draft-saintandre-urn-example-05 BCP0183 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6963
RFC6964 Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin May 2013 ASCII 49568 20 IPv6 IPv4 IPv6/IPv4 IPv6-in-IPv4 tunnel automatic isatap enterprise site

Many end-user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

draft-templin-v6ops-isops-19 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6964
RFC6965 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design L. Fang Editor N. Bitar R. Zhang M. Daikoku P. Pan August 2013 ASCII 36728 16

This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport.

draft-ietf-mpls-tp-use-cases-and-design-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6965
RFC6967 Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments M. Boucadair J. Touch P. Levis R. Penno June 2013 ASCII 53498 24 NAT Host Identifier

This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.

This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches.

draft-ietf-intarea-nat-reveal-analysis-10 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC6967
RFC6968 FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca B. Adamson July 2013 ASCII 96399 40

This document introduces the FCAST reliable object (e.g., file) delivery application. It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered Coding Transport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol.

draft-ietf-rmt-fcast-08 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC6968
RFC6969 OSPFv3 Instance ID Registry Update A. Retana D. Cheng July 2013 ASCII 7959 4

This document modifies the "Unassigned" number space in the IANA "OSPFv3 Instance ID Address Family Values" registry by dividing it in two halves -- one half Unassigned but managed via Standards Action, and the other Reserved for Private Use. It updates RFC 5838.

draft-ietf-ospf-ospfv3-iid-registry-update-04 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6969 10.17487/RFC6969
RFC6970 Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF) M. Boucadair R. Penno D. Wing July 2013 ASCII 50900 23 UPnP pinhole PCP mapping NAT control interworking

This document specifies the behavior of the Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparent NAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router.

draft-ietf-pcp-upnp-igd-interworking-10 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC6970
RFC6971 Depth-First Forwarding (DFF) in Unreliable Networks U. Herberg Editor A. Cardenas T. Iwao M. Dow S. Cespedes June 2013 ASCII 95276 41 DFF Depth first forwarding IPv6 Forwarding plane Lossy networks Reliability

This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944. The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not. It is applicable for networks with little traffic and is used for unicast transmissions only.

draft-cardenas-dff-14 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6971 10.17487/RFC6971
RFC6972 Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP) Y. Zhang N. Zong July 2013 ASCII 53634 22 P2P

Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols. This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer Streaming Protocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP.

draft-ietf-ppsp-problem-statement-15 INFORMATIONAL INFORMATIONAL IETF tsv ppsp 10.17487/RFC6972
RFC6973 Privacy Considerations for Internet Protocols A. Cooper H. Tschofenig B. Aboba J. Peterson J. Morris M. Hansen R. Smith July 2013 ASCII 89198 36 Disclosure Anonymity Pseudonymity Confidentiality Identity

This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.

draft-iab-privacy-considerations-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6973
RFC6974 Applicability of MPLS Transport Profile for Ring Topologies Y. Weingarten S. Bryant D. Ceccarelli D. Caviglia F. Fondelli M. Corsi B. Wu X. Dai July 2013 ASCII 69318 30

This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology.

draft-ietf-mpls-tp-ring-protection-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6974
RFC6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC) S. Crocker S. Rose July 2013 ASCII 18353 9 DNS DNSSEC EDNS

The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.

draft-ietf-dnsext-dnssec-algo-signal-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6975
RFC6976 Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach M. Shand S. Bryant S. Previdi C. Filsfils P. Francois O. Bonaventure July 2013 ASCII 61011 28

This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.

This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations.

After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.

The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

draft-ietf-rtgwg-ordered-fib-12 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC6976
RFC6977 Triggering DHCPv6 Reconfiguration from Relay Agents M. Boucadair X. Pougnard July 2013 ASCII 29769 13 Reconfigure-Request Reconfigure-Reply Link Address Option

This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. The Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message.

draft-ietf-dhc-triggered-reconfigure-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6977
RFC6978 A TCP Authentication Option Extension for NAT Traversal J. Touch July 2013 ASCII 11461 6 TCP-AO

This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.

draft-touch-tcp-ao-nat-05 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6978
RFC6979 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) T. Pornin August 2013 ASCII 140386 79 dsa ecdsa digital signature deterministic

This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.

draft-pornin-deterministic-dsa-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6979 10.17487/RFC6979
RFC6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery F. Gont August 2013 ASCII 20850 10 vulnerabilities evasion monitoring

This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated.

draft-ietf-6man-nd-extension-headers-05 RFC3971 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6980
RFC6981 A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses S. Bryant S. Previdi M. Shand August 2013 ASCII 79311 34 not-via

This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.

The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

draft-ietf-rtgwg-ipfrr-notvia-addresses-11 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC6981
RFC6982 Improving Awareness of Running Code: The Implementation Status Section Y. Sheffer A. Farrel July 2013 ASCII 19358 9

This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.

The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.

draft-sheffer-running-code-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6982
RFC6983 Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI) R. van Brandenburg O. van Deventer F. Le Faucheur K. Leung July 2013 ASCII 107197 45 video caching HTTP content delivery

This document presents thoughts on the potential impact of supporting HTTP Adaptive Streaming (HAS) technologies in Content Distribution Network Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI. This document has been used as input information during the CDNI working group process for making a decision regarding support for HAS.

draft-brandenburg-cdni-has-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6983
RFC6984 Interoperability Report for Forwarding and Control Element Separation (ForCES) W. Wang K. Ogawa E. Haleplidis M. Gao J. Hadi Salim August 2013 ASCII 70308 29

This document captures the results of the second Forwarding and Control Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The results of the first ForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results.

draft-ietf-forces-interop-09 RFC6053 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6984
RFC6985 IMIX Genome: Specification of Variable Packet Sizes for Additional Testing A. Morton July 2013 ASCII 19782 10 Traffic Pattern Benchmarking

Benchmarking methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX" ("Internet Mix"). The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropriate for another. However, the mix of sizes may be known, and the tester may be asked to augment the fixed-size tests. To address this need and the perpetual goal of specifying repeatable test conditions, this document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification.

draft-ietf-bmwg-imix-genome-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6985
RFC6986 GOST R 34.11-2012: Hash Function V. Dolmatov Editor A. Degtyarev August 2013 ASCII 78975 40

This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831.

draft-dolmatov-gost34112012-01 RFC5831 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6986
RFC6987 OSPF Stub Router Advertisement A. Retana L. Nguyen A. Zinin R. White D. McPherson September 2013 ASCII 10890 7 ospf stub

This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.

This document obsoletes RFC 3137.

draft-ietf-ospf-rfc3137bis-04 RFC3137 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC6987
RFC6988 Requirements for Energy Management J. Quittek Editor M. Chandramouli R. Winter T. Dietz B. Claise September 2013 ASCII 58116 28 monitoring functions control functions

This document defines requirements for standards specifications for Energy Management. The requirements defined in this document are concerned with monitoring functions as well as control functions. Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, Power Inlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries. Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components.

This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management.

draft-ietf-eman-requirements-14 INFORMATIONAL INFORMATIONAL IETF ops eman 10.17487/RFC6988
RFC6989 Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Sheffer S. Fluhrer July 2013 ASCII 21099 10 Elliptic Curve cryptography secret key reuse recipient tests

This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996.

draft-ietf-ipsecme-dh-checks-05 RFC5996 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC6989
RFC6990 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting R. Huang Q. Wu H. Asaeda G. Zorn August 2013 ASCII 21657 11 RTCP XR MPEG2 PSI Decodability

An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP. The metrics specified in the RTCP XR block are not dependent on Program Specific Information (PSI) carried in MPEG-2 TS.

draft-ietf-xrblock-rtcp-xr-decodability-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6990
RFC6991 Common YANG Data Types J. Schoenwaelder Editor July 2013 ASCII 60242 30 YANG data model netconf

This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.

draft-ietf-netmod-rfc6021-bis-03 RFC6021 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6991 10.17487/RFC6991
RFC6992 Routing for IPv4-Embedded IPv6 Packets D. Cheng M. Boucadair A. Retana July 2013 ASCII 34703 15

This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described in RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network.

draft-ietf-ospf-ipv4-embedded-ipv6-routing-14 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC6992
RFC6993 Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) P. Saint-Andre July 2013 ASCII 7431 5 SIP Call-Info header field Instant Messaging Presence

This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).

draft-saintandre-impp-call-info-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6993
RFC6994 Shared Use of Experimental TCP Options J. Touch August 2013 ASCII 25577 11

This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints.

draft-ietf-tcpm-experimental-options-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6994
RFC6996 Autonomous System (AS) Reservation for Private Use J. Mitchell July 2013 ASCII 8198 4 asn

This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document.

draft-ietf-idr-as-private-reservation-05 RFC1930 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC6996
RFC6997 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks M. Goyal Editor E. Baccelli M. Philipp A. Brandt J. Martocci August 2013 ASCII 96596 40 P2P Routing RPL ROLL

This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and Lossy Networks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.

draft-ietf-roll-p2p-rpl-17 EXPERIMENTAL EXPERIMENTAL IETF rtg roll 10.17487/RFC6997
RFC6998 A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network M. Goyal Editor E. Baccelli A. Brandt J. Martocci August 2013 ASCII 68274 29 Measurement Route Quality P2P Routes RPL ROLL

This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route.

draft-ietf-roll-p2p-measurement-10 EXPERIMENTAL EXPERIMENTAL IETF rtg roll 10.17487/RFC6998
RFC7001 Message Header Field for Indicating Message Authentication Status M. Kucherawy September 2013 ASCII 101316 43 DKIM DomainKeys SenderID SPF ADSP ATPS VBR Authentication Reputation

This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.

draft-ietf-appsawg-rfc5451bis-10 RFC5451 RFC6577 RFC7410 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7001 10.17487/RFC7001
RFC7002 RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting A. Clark G. Zorn Q. Wu September 2013 ASCII 22523 12

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-discard-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7002
RFC7003 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting A. Clark R. Huang Q. Wu Editor September 2013 ASCII 25970 14 Real Time Control Protocol

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock http://www.rfc-editor.org/errata_search.php?rfc=7003 10.17487/RFC7003
RFC7004 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting G. Zorn R. Schott Q. Wu Editor R. Huang September 2013 ASCII 41795 21 RTCP XR Summary Statistics Burst/Gap Loss Burst/Gap Discard Frame Impairment

This document defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-summary-stat-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7004
RFC7005 RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting A. Clark V. Singh Q. Wu September 2013 ASCII 27050 14

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-jb-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7005
RFC7006 Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) M. Garcia-Martin S. Veikkolainen R. Gilman September 2013 ASCII 47133 22 PDF 163470 title capability connection data capability bandwidth capability

The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely used SDP offer/answer procedures.

This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ("b=" line), connection data ("c=" line), and session or media titles ("i=" line for each session or media).

draft-ietf-mmusic-sdp-miscellaneous-caps-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=7006 10.17487/RFC7006
RFC7007 Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) T. Terriberry August 2013 ASCII 6777 4

The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published.

draft-ietf-avtcore-avp-codecs-03 RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7007
RFC7008 A Description of the KCipher-2 Encryption Algorithm S. Kiyomoto W. Shin August 2013 ASCII 71051 37 encryption stream cipher cipher

This document describes the KCipher-2 encryption algorithm. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. As of the publication of this document, no security vulnerabilities have been found. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan.

draft-kiyomoto-kcipher2-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7008
RFC7009 OAuth 2.0 Token Revocation T. Lodderstedt Editor S. Dronia M. Scurtescu August 2013 ASCII 23517 11

This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.

draft-ietf-oauth-revocation-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7009
RFC7010 IPv6 Site Renumbering Gap Analysis B. Liu S. Jiang B. Carpenter S. Venaas W. George September 2013 ASCII 57067 26

This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering. The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process.

draft-ietf-6renum-gap-analysis-08 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC7010
RFC7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information B. Claise Editor B. Trammell Editor P. Aitken September 2013 ASCII 170852 76

This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101.

draft-ietf-ipfix-protocol-rfc5101bis-10 RFC5101 STD0077 INTERNET STANDARD INTERNET STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=7011 10.17487/RFC7011
RFC7012 Information Model for IP Flow Information Export (IPFIX) B. Claise Editor B. Trammell Editor September 2013 ASCII 50237 24

This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.

draft-ietf-ipfix-information-model-rfc5102bis-10 RFC5102 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=7012 10.17487/RFC7012
RFC7013 Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements B. Trammell B. Claise September 2013 ASCII 76406 32 IE-DOCTORS IANA

This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations.

draft-ietf-ipfix-ie-doctors-07 BCP0184 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops ipfix 10.17487/RFC7013
RFC7014 Flow Selection Techniques S. D'Antonio T. Zseby C. Henke L. Peluso September 2013 ASCII 72581 33

The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IP Flow Information Export (IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported.

draft-ietf-ipfix-flow-selection-tech-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7014
RFC7015 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol B. Trammell A. Wagner B. Claise September 2013 ASCII 112055 49 Flow metering Flow measurement IPFIX mediator

This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals.

draft-ietf-ipfix-a9n-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7015
RFC7016 Adobe's Secure Real-Time Media Flow Protocol M. Thornburgh November 2013 ASCII 236685 113 RTMFP

This memo describes Adobe's Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features that make it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used.

draft-thornburgh-adobe-rtmfp-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7016
RFC7017 IMAP Access to IETF Email List Archives R. Sparks August 2013 ASCII 9886 5

The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists. Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service.

draft-sparks-genarea-imaparch-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7017
RFC7018 Auto-Discovery VPN Problem Statement and Requirements V. Manral S. Hanna September 2013 ASCII 27284 12 IPsec Overlay SDN IKE

This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution.

Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements.

draft-ietf-ipsecme-ad-vpn-problem-09 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC7018
RFC7019 Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD) J. Buford M. Kolberg Editor September 2013 ASCII 83788 41 application-layer multicast

We define a REsource LOcation And Discovery (RELOAD) Usage for Application-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay-independent way. Two example algorithms are defined, based on Scribe and P2PCast.

This document is a product of the Scalable Adaptive Multicast Research Group (SAM RG).

draft-irtf-samrg-sam-baseline-protocol-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7019
RFC7020 The Internet Numbers Registry System R. Housley J. Curran G. Huston D. Conrad August 2013 ASCII 19332 9

This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.

This document also provides information about the processes for further evolution of the Internet Numbers Registry System.

This document replaces RFC 2050.

This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today.

draft-housley-rfc2050bis-02 RFC2050 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7020
RFC7021 Assessing the Impact of Carrier-Grade NAT on Network Applications C. Donley Editor L. Howard V. Kuarsingh J. Berg J. Doshi September 2013 ASCII 66150 29 CGN NAT444 DS-Lite Dual-Stack Lite IPv4 NAT IPv6 LSN transition

NAT444 is an IPv4 extension technology being considered by Service Providers as a means to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Carrier- Grade NAT (CGN) in the Service Provider network, often resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications. This document was updated to include the Dual-Stack Lite (DS-Lite) impacts also.

draft-donley-nat444-impacts-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7021
RFC7022 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) A. Begen C. Perkins D. Wing E. Rescorla September 2013 ASCII 21717 10

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.

For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222.

draft-ietf-avtcore-6222bis-06 RFC6222 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7022
RFC7023 MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking D. Mohan Editor N. Bitar Editor A. Sajassi Editor S. DeLord P. Niger R. Qiu October 2013 ASCII 47621 23

This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge (PWE3) architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects.

draft-ietf-pwe3-mpls-eth-oam-iwk-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7023
RFC7024 Virtual Hub-and-Spoke in BGP/MPLS VPNs H. Jeng J. Uttaro L. Jalil B. Decraene Y. Rekhter R. Aggarwal October 2013 ASCII 62926 25

With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each Provider Edge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.

Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers.

draft-ietf-l3vpn-virtual-hub-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7024
RFC7025 Requirements for GMPLS Applications of PCE T. Otani K. Ogaki D. Caviglia F. Zhang C. Margaria September 2013 ASCII 26498 12 Path Computation CSPF PCC Traffic Engineering TE

The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE.

draft-ietf-pce-gmpls-aps-req-09 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7025
RFC7026 Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel A. Farrel S. Bryant September 2013 ASCII 9297 5 ACH G-ACh Pseudowire PW MPLS-TP

The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs

No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.

This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.

draft-ietf-mpls-retire-ach-tlv-03 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7026
RFC7027 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) J. Merkle M. Lochter October 2013 ASCII 16366 10 TLS Elliptic Curve Cryptography

This document specifies the use of several Elliptic Curve Cryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol.

draft-merkle-tls-brainpool-04 RFC4492 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7027 10.17487/RFC7027
RFC7028 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 JC. Zuniga LM. Contreras CJ. Bernardos S. Jeon Y. Kim September 2013 ASCII 63110 29 multimob PMIPv6 MTMA selector MLD IGMP

This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile Access Gateway can provide access to multicast content in the local network. The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios.

draft-ietf-multimob-pmipv6-ropt-08 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7028
RFC7029 Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding S. Hartman M. Wasserman D. Zhang October 2013 ASCII 45360 19 MITM man-in-the-middle EMSK crypto binding Extended Master Session Key tunnel

As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.

draft-ietf-emu-crypto-bind-04 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC7029
RFC7030 Enrollment over Secure Transport M. Pritikin Editor P. Yee Editor D. Harkins Editor October 2013 ASCII 123989 53 pki est

This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.

draft-ietf-pkix-est-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=7030 10.17487/RFC7030
RFC7031 DHCPv6 Failover Requirements T. Mrugalski K. Kinnear September 2013 ASCII 39321 17 DHCPv6 Failover

The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. RFC 3315 allows for, but does not define, any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol.

draft-ietf-dhc-dhcpv6-failover-requirements-07 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7031
RFC7032 LDP Downstream-on-Demand in Seamless MPLS T. Beckhaus Editor B. Decraene K. Tiruveedhula M. Konstantynowicz Editor L. Martini October 2013 ASCII 75588 35

Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDP Downstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design.

In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence.

draft-ietf-mpls-ldp-dod-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7032
RFC7033 WebFinger P. Jones G. Salgueiro M. Jones J. Smarr September 2013 ASCII 61552 28 WebFinger JRD JSON Resource Descriptor service discovery service discovery protocol information discovery information discovery protocol

This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.

draft-ietf-appsawg-webfinger-18 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7033
RFC7034 HTTP Header Field X-Frame-Options D. Ross T. Gondrom October 2013 ASCII 27263 14 frame-options HTTP header websec

To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages.

draft-ietf-websec-x-frame-options-12 INFORMATIONAL INFORMATIONAL IETF app websec 10.17487/RFC7034
RFC7035 Relative Location Representation M. Thomson B. Rosen D. Stanley G. Bajko A. Thomson October 2013 ASCII 74709 39 Relative location

This document defines an extension to the Presence Information Data Format Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described.

Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset.

draft-ietf-geopriv-relative-location-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7035
RFC7036 Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group R. Housley October 2013 ASCII 14314 7

When the Long-Term Archive and Notary Services (LTANS) working group was chartered, an object identifier arc was set aside for use by that working group. This document describes the object identifiers that were assigned, and it establishes IANA allocation policies for any future assignments within that arc.

draft-housley-ltans-oids-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7036
RFC7037 RADIUS Option for the DHCPv6 Relay Agent L. Yeh M. Boucadair October 2013 ASCII 23356 10 DHCPv6 RADIUS

The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. This architecture assumes that the Network Access Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client. When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server. The DHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests.

draft-ietf-dhc-dhcpv6-radius-opt-14 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7037
RFC7038 Use of OSPF-MDR in Single-Hop Broadcast Networks R. Ogier October 2013 ASCII 15535 7 routing mobile ad hoc network MANET designated router wireless point-to-multipoint interface

RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANET Designated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks.

draft-ietf-ospf-manet-single-hop-mdr-04 RFC5614 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC7038
RFC7039 Source Address Validation Improvement (SAVI) Framework J. Wu J. Bi M. Bagnulo F. Baker C. Vogt Editor October 2013 ASCII 31946 14 anti-spoofing BCP38 ingress filtering

Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.

draft-ietf-savi-framework-06 INFORMATIONAL INFORMATIONAL IETF int savi 10.17487/RFC7039
RFC7040 Public IPv4-over-IPv6 Access Network Y. Cui J. Wu P. Wu O. Vautrin Y. Lee November 2013 ASCII 27273 13 Public 4over6 IPv4 over IPv6 Access Network DHCPv4 over IPv6 IPv6 Tunnel IPv6 Transition

This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows the Hub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network.

draft-ietf-softwire-public-4over6-10 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC7040
RFC7041 Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging F. Balus Editor A. Sajassi Editor N. Bitar Editor November 2013 ASCII 31236 15

The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multiple Provider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability than Provider Bridges (PBs) in terms of the number of customer Media Access Control addresses and the number of service instances that can be supported.

The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid Spanning Tree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks.

This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model.

draft-ietf-l2vpn-pbb-vpls-pe-model-07 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7041
RFC7042 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters D. Eastlake 3rd J. Abley October 2013 ASCII 53488 27 Ethernet Ethertype 802 OUI EUI LSAP

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342.

draft-eastlake-rfc5342bis-05 RFC5342 RFC2153 BCP0141 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7042
RFC7043 Resource Records for EUI-48 and EUI-64 Addresses in the DNS J. Abley October 2013 ASCII 15504 8 IEEE ethernet

48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended Unique Identifier (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g., Ethernet.

This document describes two new DNS resource record types, EUI48 and EUI64, for encoding Ethernet addresses in the DNS.

This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated.

draft-jabley-dnsext-eui48-eui64-rrtypes-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7043
RFC7044 An Extension to the Session Initiation Protocol (SIP) for Request History Information M. Barnes F. Audet S. Schubert J. van Elburg C. Holmberg February 2014 ASCII 85068 36 history-info retarget enhanced services voicemail automatic call distribution

This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244.

draft-ietf-sipcore-rfc4244bis-12 RFC4244 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=7044 10.17487/RFC7044
RFC7045 Transmission and Processing of IPv6 Extension Headers B. Carpenter S. Jiang December 2013 ASCII 21852 10

Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.

draft-ietf-6man-ext-transmit-05 RFC2460 RFC2780 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7045
RFC7046 A Common API for Transparent Hybrid Multicast M. Waehlisch T. Schmidt S. Venaas December 2013 ASCII 85861 41 Peer-to-Peer (P2P) adaptive multicast multicast naming multicast addressing

Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM) Research Group.

draft-irtf-samrg-common-api-11 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7046
RFC7047 The Open vSwitch Database Management Protocol B. Pfaff B. Davie Editor December 2013 ASCII 69446 35 vswitch virtualization overlay OVS

Open vSwitch is an open-source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments. A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network. Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol. This document defines the OVSDB management protocol. The Open vSwitch project includes open-source OVSDB client and server implementations.

draft-pfaff-ovsdb-proto-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7047
RFC7048 Neighbor Unreachability Detection Is Too Impatient E. Nordmark I. Gashinsky January 2014 ASCII 17946 8 6MAN IPv6 Neighbor Discovery

IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative neighbor -- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time. By default, this time is 3 seconds after the node starts probing. However, if there are no alternative neighbors, this timeout behavior is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC 4861.

draft-ietf-6man-impatient-nud-07 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7048
RFC7049 Concise Binary Object Representation (CBOR) C. Bormann P. Hoffman October 2013 ASCII 134062 54 parser encoder binary format data interchange format JSON

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

draft-bormann-cbor-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7049 10.17487/RFC7049
RFC7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis T. Savolainen J. Korhonen D. Wing November 2013 ASCII 50097 22 NAT64 DNS64 464XLAT Pref64::/n

This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments.

draft-ietf-behave-nat64-discovery-heuristic-17 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC7050
RFC7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix J. Korhonen Editor T. Savolainen Editor November 2013 ASCII 55248 25 NAT64 DNS64 464XLAT Pref64::/n

Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by the NAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery.

draft-ietf-behave-nat64-learn-analysis-03 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC7051
RFC7052 Locator/ID Separation Protocol (LISP) MIB G. Schudel A. Jain V. Moreno October 2013 ASCII 125519 66

This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.

draft-ietf-lisp-mib-13 EXPERIMENTAL EXPERIMENTAL IETF int lisp http://www.rfc-editor.org/errata_search.php?rfc=7052 10.17487/RFC7052
RFC7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol M. Tuexen I. Ruengeler R. Stewart November 2013 ASCII 15773 8

This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding Selective Acknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems.

draft-ietf-tsvwg-sctp-sack-immediately-04 RFC4960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7053
RFC7054 Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) A. Farrel H. Endo R. Winter Y. Koike M. Paul November 2013 ASCII 25444 11

The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how the Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces.

This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP.

draft-ietf-mpls-tp-mip-mep-map-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7054
RFC7055 A GSS-API Mechanism for the Extensible Authentication Protocol S. Hartman Editor J. Howlett December 2013 ASCII 87564 35

This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol.

draft-ietf-abfab-gss-eap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7055
RFC7056 Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism S. Hartman J. Howlett December 2013 ASCII 24622 11

The naming extensions to the Generic Security Service Application Programming Interface (GSS-API) provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication, Authorization, and Accounting (AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes how to use the Naming Extensions API to access that information.

draft-ietf-abfab-gss-eap-naming-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7056
RFC7057 Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) S. Winter J. Salowey December 2013 ASCII 16006 7 EAP AAA

This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture.

draft-ietf-abfab-eapapplicability-06 RFC3748 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7057
RFC7058 Media Control Channel Framework (CFW) Call Flow Examples A. Amirante T. Castaldi L. Miniero S P. Romano November 2013 ASCII 387335 182 MediaCtrl Media Server Control Media Control Channel Framework

This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference document for both implementors and protocol researchers.

draft-ietf-mediactrl-call-flows-13 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC7058
RFC7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms S. Steffann I. van Beijnum R. van Rein November 2013 ASCII 98886 41

This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them.

draft-steffann-tunnels-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7059
RFC7060 Using LDP Multipoint Extensions on Targeted LDP Sessions M. Napierala E. Rosen IJ. Wijnands November 2013 ASCII 19384 9

Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. However, the specification for the Multipoint Extensions to LDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over a Targeted LDP session.

draft-ietf-mpls-targeted-mldp-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7060
RFC7061 eXtensible Access Control Markup Language (XACML) XML Media Type R. Sinnema E. Wilde November 2013 ASCII 14666 8

This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML).

draft-sinnema-xacml-media-type-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7061
RFC7062 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks F. Zhang Editor D. Li H. Li S. Belotti D. Ceccarelli November 2013 ASCII 56109 26

This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.

draft-ietf-ccamp-gmpls-g709-framework-15 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7062
RFC7063 Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments L. Zheng J. Zhang R. Parekh December 2013 ASCII 21964 12

This document provides supporting documentation to advance the IETF stream's Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from Proposed Standard to Internet Standard.

draft-ietf-pim-rfc4601-update-survey-report-03 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC7063
RFC7064 URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol S. Nandakumar G. Salgueiro P. Jones M. Petit-Huguenin November 2013 ASCII 15045 9

This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.

draft-nandakumar-rtcweb-stun-uri-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7064
RFC7065 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers M. Petit-Huguenin S. Nandakumar G. Salgueiro P. Jones November 2013 ASCII 16143 9

This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).

draft-petithuguenin-behave-turn-uris-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7065
RFC7066 IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts J. Korhonen Editor J. Arkko Editor T. Savolainen S. Krishnan November 2013 ASCII 44253 20

As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316.

draft-ietf-v6ops-rfc3316bis-06 RFC3316 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7066
RFC7067 Directory Assistance Problem and High-Level Design Proposal L. Dunbar D. Eastlake 3rd R. Perlman I. Gashinsky November 2013 ASCII 34720 15 TRILL Orchestration Directory Push Pull RBridge ARP

Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC&Label) that the switch does not know, the data frame is flooded within the frame's Data Label across the TRILL campus.

This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (Address Resolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security.

draft-ietf-trill-directory-framework-07 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7067
RFC7068 Diameter Overload Control Requirements E. McMurry B. Campbell November 2013 ASCII 69536 29

When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided.

draft-ietf-dime-overload-reqs-13 INFORMATIONAL INFORMATIONAL IETF ops dime 10.17487/RFC7068
RFC7069 DECoupled Application Data Enroute (DECADE) R. Alimi A. Rahman D. Kutscher Y. Yang H. Song K. Pentikousis November 2013 ASCII 81867 35 decade

Content distribution applications, such as those employing peer-to-peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks. Often, however, content distribution applications use network resources inefficiently. One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end-host and in-network content distribution mechanisms. This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document. DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources. This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples.

draft-alimi-decade-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7069
RFC7070 An Architecture for Reputation Reporting N. Borenstein M. Kucherawy November 2013 ASCII 32262 14 domain security messaging dkim spf authentication reputation

This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over the Internet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC 4101 for describing a protocol model.

draft-ietf-repute-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7070
RFC7071 A Media Type for Reputation Interchange N. Borenstein M. Kucherawy November 2013 ASCII 29541 17 reputation domain security messaging dkim spf authentication

This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.

draft-ietf-repute-media-type-13 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7071
RFC7072 A Reputation Query Protocol N. Borenstein M. Kucherawy November 2013 ASCII 17416 9 reputation domain security messaging dkim spf authentication

This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.

draft-ietf-repute-query-http-11 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7072
RFC7073 A Reputation Response Set for Email Identifiers N. Borenstein M. Kucherawy November 2013 ASCII 14857 8 reputation domain security messaging dkim spf authentication

This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.

draft-ietf-repute-email-identifiers-10 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7073
RFC7074 Revised Definition of the GMPLS Switching Capability and Type Fields L. Berger J. Meuric November 2013 ASCII 19376 9

GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307.

draft-ietf-ccamp-swcaps-update-03 RFC3471 RFC4202 RFC4203 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7074
RFC7075 Realm-Based Redirection In Diameter T. Tsou R. Hao T. Taylor Editor November 2013 ASCII 21434 10 Diameter routing

The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when the Straightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server".

This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time Attribute-Value Pairs (AVPs).

draft-ietf-dime-realm-based-redirect-13 RFC6733 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7075
RFC7076 P6R's Secure Shell Public Key Subsystem M. Joseph J. Susoy November 2013 ASCII 20430 11 key management certificate management security

The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.

The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key Management Interoperability Protocol (KMIP), Simple Network Management Protocol (SNMP)).

The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).

Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.

draft-joseph-pkix-p6rsshextension-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7076
RFC7077 Update Notifications for Proxy Mobile IPv6 S. Krishnan S. Gundavelli M. Liebsch H. Yokota J. Korhonen November 2013 ASCII 49176 21 MIPv6

This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose.

draft-ietf-netext-update-notifications-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7077
RFC7078 Distributing Address Selection Policy Using DHCPv6 A. Matsumoto T. Fujisaki T. Chown January 2014 ASCII 25094 12

RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site.

draft-ietf-6man-addr-select-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7078
RFC7079 The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results N. Del Regno Editor A. Malis Editor November 2013 ASCII 67854 41 Control Word (CW) Control Channel (CC)

The IETF Pseudowire Emulation Edge-to-Edge (PWE3) working group has defined many encapsulations of various layer 1 and layer 2 service- specific PDUs and circuit data. In most of these encapsulations, use of the Pseudowire (PW) Control Word is required. However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations. This survey of the Pseudowire / Virtual Circuit Connectivity Verification (VCCV) user community was conducted to determine implementation trends and the possibility of always mandating the Control Word.

draft-ietf-pwe3-vccv-impl-survey-results-03 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC7079
RFC7080 Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges A. Sajassi S. Salam N. Bitar F. Balus December 2013 ASCII 61560 26 h-vpls

The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008. It aims to improve the scalability of Media Access Control (MAC) addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access.

draft-ietf-l2vpn-pbb-vpls-interop-06 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7080
RFC7081 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) E. Ivov P. Saint-Andre E. Marocco November 2013 ASCII 46772 19 real-time communication unified communication voice video instant messaging chat presence telephony

This document suggests some strategies for the combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) both in user-oriented clients and in deployed servers. Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real-time communication service by using complementary subsets of features from SIP and from XMPP. Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize "best current practices". Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication.

draft-ivov-xmpp-cusax-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7081
RFC7082 Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP) R. Shekh-Yusef M. Barnes December 2013 ASCII 18709 10

The Centralized Conferencing Manipulation Protocol (CCMP) document (RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the Centralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.

This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the <service-uris> element in the SIP conferencing event package.

draft-yusef-dispatch-ccmp-indication-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7082
RFC7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT R. Droms November 2013 ASCII 14630 7

This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with new values.

draft-ietf-dhc-dhcpv6-solmaxrt-update-05 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7083
RFC7084 Basic Requirements for IPv6 Customer Edge Routers H. Singh W. Beebee C. Donley B. Stark November 2013 ASCII 46569 21 6rd DS-Lite

This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204.

draft-ietf-v6ops-6204bis-12 RFC6204 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7084
RFC7085 Top-Level Domains That Are Already Dotless J. Levine P. Hoffman December 2013 ASCII 11369 6 DNS

Recent statements from the Internet Architecture Board (IAB) and the Internet Corporation of Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee have focused on the problems that the DNS is likely to experience with top-level domains (TLDs) that contain address records (so-called "dotless domains"). In order to help researchers determine the extent of the issues with dotless domains, this document lists the current dotless TLDs and gives a script for finding them. This document lists data about dotless TLDs but does not address the policy and technology issues other than to point to the statements of others.

draft-hoffine-already-dotless-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7085
RFC7086 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) A. Keranen G. Camarillo J. Maenpaa January 2014 ASCII 21406 10 HIP overlay P2P

This document is the HIP-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP.

draft-ietf-hip-reload-instance-10 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC7086
RFC7087 A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations H. van Helvoort Editor L. Andersson Editor N. Sprecher Editor December 2013 ASCII 43925 21

The MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force (IETF). The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has specified a Transport Network architecture.

This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network Recommendations.

It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context.

draft-ietf-mpls-tp-rosetta-stone-13 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7087
RFC7088 Session Initiation Protocol Service Example -- Music on Hold D. Worley February 2014 ASCII 69311 36 Music on hold

"Music on hold" is one of the features of telephone systems that is most desired by buyers of business telephone systems. Music on hold means that when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards-compliant. The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music-on-hold method described in Section 2.3 of RFC 5359.

draft-worley-service-example-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7088
RFC7089 HTTP Framework for Time-Based Access to Resource States -- Memento H. Van de Sompel M. Nelson R. Sanderson December 2013 ASCII 107130 50 HTTP content negotiation datetime negotiation resource versions archival resources Memento

The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.

draft-vandesompel-memento-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7089
RFC7090 Public Safety Answering Point (PSAP) Callback H. Schulzrinne H. Tschofenig C. Holmberg M. Patel April 2014 ASCII 37445 18 PSAP callback SIP emergency VoIP

After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim. A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine.

The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to mark PSAP callbacks.

draft-ietf-ecrit-psap-callback-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC7090
RFC7091 GOST R 34.10-2012: Digital Signature Algorithm V. Dolmatov Editor A. Degtyarev December 2013 ASCII 39924 21

This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification. This document updates RFC 5832.

draft-dolmatov-gost34102012-00 RFC5832 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7091
RFC7092 A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents H. Kaplan V. Pascual December 2013 ASCII 22085 10 SIP B2BUA taxonomy

In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).

There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.

draft-ietf-straw-b2bua-taxonomy-03 INFORMATIONAL INFORMATIONAL IETF rai straw 10.17487/RFC7092
RFC7093 Additional Methods for Generating Key Identifiers Values S. Turner S. Kent J. Manger December 2013 ASCII 7622 5

This document specifies additional example methods for generating Key Identifier values for use in the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) certificate extensions.

draft-turner-additional-methods-4kis-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7093
RFC7094 Architectural Considerations of IP Anycast D. McPherson D. Oran D. Thaler E. Osterweil January 2014 ASCII 50246 22 anycast architecture

This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.

draft-iab-anycast-arch-implications-12 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7094
RFC7095 jCard: The JSON Format for vCard P. Kewisch January 2014 ASCII 59088 29 jCard JSON vCard addressbook contacts CardDAV PIM

This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.

draft-ietf-jcardcal-jcard-07 PROPOSED STANDARD PROPOSED STANDARD IETF app jcardcal 10.17487/RFC7095
RFC7096 Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) S. Belotti Editor P. Grandi D. Ceccarelli Editor D. Caviglia F. Zhang D. Li January 2014 ASCII 50281 23 Routing CCAMP Working Group OSPF GMPLS G709 OTN

ITU-T recommendation G.709-2012 has introduced new fixed and flexible Optical channel Data Unit (ODU) containers in Optical Transport Networks (OTNs).

This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs.

draft-ietf-ccamp-otn-g709-info-model-13 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7096
RFC7097 RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets J. Ott V. Singh Editor I. Curcio January 2014 ASCII 20581 11 RTP RTCP discard metrics

The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order to provide a variety of short- term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the de- jitter buffer after successful reception.

draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7097
RFC7098 Using the IPv6 Flow Label for Load Balancing in Server Farms B. Carpenter S. Jiang W. Tarreau January 2014 ASCII 30884 13 ECMP

This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.

draft-ietf-intarea-flow-label-balancing-03 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC7098
RFC7100 Retirement of the "Internet Official Protocol Standards" Summary Document P. Resnick December 2013 ASCII 5365 3

This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.

draft-resnick-retire-std1-01 RFC5000 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7100
RFC7101 List of Internet Official Protocol Standards: Replaced by a Web Page S. Ginoza December 2013 ASCII 6922 4

At one time, the RFC Editor published snapshots of the "Internet Official Protocol Standards". These documents were known as xx00 documents, the last of which was published in May 2008. These snapshots have been replaced by a web page, so the RFC Editor will no longer be publishing these snapshots as RFCs. As a result, the RFC Editor will classify unpublished RFC xx00 numbers through 7000 as never issued. Starting with the RFC number 7100, xx00 numbers will be available for assignment.

draft-rfced-rfcxx00-retired-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7101
RFC7102 Terms Used in Routing for Low-Power and Lossy Networks JP. Vasseur January 2014 ASCII 16444 8

This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.

draft-ietf-roll-terminology-13 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7102
RFC7103 Advice for Safe Handling of Malformed Messages M. Kucherawy G. Shapiro N. Freed January 2014 ASCII 48387 24 MTA SMTP

Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance.

draft-ietf-appsawg-malformed-mail-11 INFORMATIONAL INFORMATIONAL IETF app appsawg 10.17487/RFC7103
RFC7104 Duplication Grouping Semantics in the Session Description Protocol A. Begen Y. Cai H. Ou January 2014 ASCII 17719 10 SDP ssrc synchronization source grouping framework

Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing.

draft-ietf-mmusic-duplication-grouping-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7104
RFC7105 Using Device-Provided Location-Related Measurements in Location Configuration Protocols M. Thomson J. Winterbottom January 2014 ASCII 155084 74 HELD Location Measurements Device-based

This document describes a protocol for a Device to provide location-related measurement data to a Location Information Server (LIS) within a request for location information. Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment. A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.

draft-ietf-geopriv-held-measurements-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7105
RFC7106 A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State E. Ivov January 2014 ASCII 11939 6 SIP Conference Event Package service-uris conference-uris URI purpose

This document defines and registers a value of "grouptextchat" ("Group Text Chat") for the URI <purpose> element of SIP's Conference Event Package.

draft-ivov-grouptextchat-purpose-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7106
RFC7107 Object Identifier Registry for the S/MIME Mail Security Working Group R. Housley January 2014 ASCII 43898 18

When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group. This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.

draft-housley-smime-oids-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7107
RFC7108 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes J. Abley T. Manderson January 2014 ASCII 24125 11

Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion.

Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed. Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.

This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service.

draft-jabley-dnsop-anycast-mapping-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7108 10.17487/RFC7108
RFC7109 Flow Bindings Initiated by Home Agents for Mobile IPv6 H. Yokota D. Kim B. Sarikaya F. Xia February 2014 ASCII 40637 18 MIPv6 Flow mobility

There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6.

draft-yokota-mext-ha-init-flow-binding-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7109
RFC7110 Return Path Specified Label Switched Path (LSP) Ping M. Chen W. Cao S. Ning F. Jounay S. Delord January 2014 ASCII 44625 21 Tunnel Stack Reply TC

This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness.

draft-ietf-mpls-return-path-specified-lsp-ping-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7110 10.17487/RFC7110
RFC7111 URI Fragment Identifiers for the text/csv Media Type M. Hausenblas E. Wilde J. Tennison January 2014 ASCII 24818 13 mime

This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell. Fragment identification can use single items or ranges.

draft-hausenblas-csv-fragment-08 RFC4180 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7111
RFC7112 Implications of Oversized IPv6 Header Chains F. Gont V. Manral R. Bonica January 2014 ASCII 15897 8

The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that can, in turn, extend each of the headers. In those scenarios in which the IPv6 Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6 Header Chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the First Fragment of a packet is required to contain the entire IPv6 Header Chain.

draft-ietf-6man-oversized-header-chain-09 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7112
RFC7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) F. Gont February 2014 ASCII 29272 13

The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.

draft-ietf-v6ops-ra-guard-implementation-07 RFC6105 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7113
RFC7114 Creation of a Registry for smime-type Parameter Values B. Leiba January 2014 ASCII 7176 4

Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the Content-Type parameter "smime-type". As the list of defined values for that parameter has increased, it has become clear that a registry is needed to document these values. This document creates the registry, registers the current values, and specifies the policies for registration of new values.

draft-leiba-smime-type-registry-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7114
RFC7115 Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) R. Bush January 2014 ASCII 26033 11

Deployment of BGP origin validation that is based on the Resource Public Key Infrastructure (RPKI) has many operational considerations. This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood.

draft-ietf-sidr-origin-ops-23 BCP0185 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC7115
RFC7116 Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries K. Scott M. Blanchet February 2014 ASCII 18568 10

The DTNRG Research Group has defined the experimental Licklider Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields are subject to a registry. For the purpose of its research work, the group has created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions.

draft-dtnrg-ltp-cbhe-registries-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7116
RFC7117 Multicast in Virtual Private LAN Service (VPLS) R. Aggarwal Editor Y. Kamite L. Fang Y. Rekhter C. Kodeboniya February 2014 ASCII 126280 50

RFCs 4761 and 4762 describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported.

This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances.

draft-ietf-l2vpn-vpls-mcast-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC7117
RFC7118 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) I. Baz Castillo J. Millan Villegas V. Pascual January 2014 ASCII 51248 25 SIP WebSocket

The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments.

draft-ietf-sipcore-sip-websocket-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC7118
RFC7119 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators B. Claise A. Kobayashi B. Trammell February 2014 ASCII 74807 32

This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns.

draft-ietf-ipfix-mediation-protocol-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7119
RFC7120 Early IANA Allocation of Standards Track Code Points M. Cotton January 2014 ASCII 17722 9 early allocation policy protocol

This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.

draft-cotton-rfc4020bis-02 RFC4020 BCP0100 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7120
RFC7121 High Availability within a Forwarding and Control Element Separation (ForCES) Network Element K. Ogawa W. Wang E. Haleplidis J. Hadi Salim February 2014 ASCII 62599 31 ForCES HA

This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) Network Element (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism.

draft-ietf-forces-ceha-10 RFC5810 RFC7391 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC7121
RFC7122 Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP) H. Kruse S. Jero S. Ostermann March 2014 ASCII 25889 11

This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.

draft-irtf-dtnrg-dgram-clayer-05 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7122
RFC7123 Security Implications of IPv6 on IPv4 Networks F. Gont W. Liu February 2014 ASCII 42374 19

This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues.

draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC7123
RFC7124 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB E. Beili February 2014 ASCII 12123 6 EFM-CU-MIB ieee

This document updates RFC 5066. It amends that specification by informing the Internet community about the transition of the EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group.

draft-ietf-opsawg-rfc5066bis-07 RFC5066 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7124
RFC7125 Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element B. Trammell P. Aitken February 2014 ASCII 11679 6

This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.

draft-trammell-ipfix-tcpcontrolbits-revision-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7125
RFC7126 Recommendations on Filtering of IPv4 Packets Containing IPv4 Options F. Gont R. Atkinson C. Pignataro February 2014 ASCII 72504 36

This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.

draft-ietf-opsec-ip-options-filtering-07 BCP0186 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC7126
RFC7127 Characterization of Proposed Standards O. Kolkman S. Bradner S. Turner January 2014 ASCII 9902 5 Guidance Standards Standards Process Advancement Proposed Standard

RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.

draft-kolkman-proposed-standards-clarified-06 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7127
RFC7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report R. Bush R. Austein K. Patel H. Gredler M. Waehlisch February 2014 ASCII 19348 11 routing security

This document is an implementation report for the Resource Public Key Infrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab.

draft-ietf-sidr-rpki-rtr-impl-05 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC7128
RFC7129 Authenticated Denial of Existence in the DNS R. Gieben W. Mekking February 2014 ASCII 62936 30 Internet DNSSEC Denial of Existence NSEC NSEC3

Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.

This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.

draft-gieben-auth-denial-of-existence-dns-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7129
RFC7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces M. Bhatia Editor M. Chen Editor S. Boutros Editor M. Binderberger Editor J. Haas Editor February 2014 ASCII 21291 11

This document defines a mechanism to run Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link.

This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of Layer 3 (L3) bidirectional forwarding.

draft-ietf-bfd-on-lags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7130
RFC7131 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples M. Barnes F. Audet S. Schubert H. van Elburg C. Holmberg March 2014 ASCII 93039 52 SIP History-Info RFC4244bis Example Call Flow

This document describes use cases and documents call flows that require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details.

draft-ietf-sipcore-rfc4244bis-callflows-08 INFORMATIONAL INFORMATIONAL IETF rai sipcore 10.17487/RFC7131
RFC7132 Threat Model for BGP Path Security S. Kent A. Chi February 2014 ASCII 52539 20 BGPSEC RPKI SIDR

This document describes a threat model for the context in which External Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the Resource Public Key Infrastructure (RPKI) and focuses on the ability of an Autonomous System (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term "PATHSEC" to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of the RPKI.

The document characterizes classes of potential adversaries that are considered to be threats and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in the BGP-4 standard. It concludes with a brief discussion of residual vulnerabilities.

draft-ietf-sidr-bgpsec-threats-09 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC7132
RFC7133 Information Elements for Data Link Layer Traffic Measurement S. Kashima A. Kobayashi Editor P. Aitken May 2014 ASCII 76209 41 IPFIX PSAMP Provider Bridge Provider Backbone Bridge ipfix

This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.

draft-ietf-ipfix-data-link-layer-monitoring-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7133
RFC7134 The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" B. Rosen March 2014 ASCII 3565 2 Resource-Priority Namespaces Resource-Priority Priority-values

RFC 4412 defines the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updates RFC 4412 to change the management policy of these registries to "IETF Review".

draft-rosen-rph-reg-policy-01 RFC4412 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC7134
RFC7135 Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications J. Polk May 2014 ASCII 20749 9

This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace 'esnet' and registers this namespace with IANA. The new header field namespace allows for local emergency session establishment to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations.

draft-polk-local-emergency-rph-namespace-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7135
RFC7136 Significance of IPv6 Interface Identifiers B. Carpenter S. Jiang February 2014 ASCII 23172 10

The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.

draft-ietf-6man-ug-06 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7136
RFC7137 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks A. Retana S. Ratliff February 2014 ASCII 16017 8

This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.

This document updates RFC 5820.

draft-ietf-ospf-manet-single-hop-or-04 RFC5820 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC7137
RFC7138 Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks D. Ceccarelli Editor F. Zhang S. Belotti R. Rao J. Drake March 2014 ASCII 77038 36 OSPF GMPLS G709 OTN

This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203.

draft-ietf-ccamp-gmpls-ospf-g709v3-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7138
RFC7139 GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks F. Zhang Editor G. Zhang S. Belotti D. Ceccarelli K. Pithewan March 2014 ASCII 58382 27

ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.

This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.

draft-ietf-ccamp-gmpls-signaling-g709v3-12 RFC4328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=7139 10.17487/RFC7139
RFC7140 LDP Extensions for Hub and Spoke Multipoint Label Switched Path L. Jin F. Jounay IJ. Wijnands N. Leymann March 2014 ASCII 33570 15 P2MP LSP MP2MP LSP

This document introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed.

draft-ietf-mpls-mldp-hsmp-06 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7140
RFC7141 Byte and Packet Congestion Notification B. Briscoe J. Manner February 2014 ASCII 103344 41 active queue management aqm availability denial of service dos quality of service qos congestion control fairness incentives architecture layering protocol

This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), and newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms.

draft-ietf-tsvwg-byte-pkt-congest-12 RFC2309 RFC2914 BCP0041 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC7141
RFC7142 Reclassification of RFC 1142 to Historic M. Shand L. Ginsberg February 2014 ASCII 5036 3

This memo reclassifies RFC 1142, "OSI IS-IS Intra-domain Routing Protocol", to Historic status. This memo also obsoletes RFC 1142.

draft-ietf-isis-rfc1142-to-historic-00 RFC1142 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC7142
RFC7143 Internet Small Computer System Interface (iSCSI) Protocol (Consolidated) M. Chadalapaka J. Satran K. Meth D. Black April 2014 ASCII 655576 295 iSCSI SCSI storage SAN block storage SCSI object storage devices OSD SAM disk T10

This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as a few improvements and corrections to the original iSCSI protocol.

This document obsoletes RFCs 3720, 3980, 4850, and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics.

draft-ietf-storm-iscsi-cons-10 RFC3720 RFC3980 RFC4850 RFC5048 RFC3721 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7143
RFC7144 Internet Small Computer System Interface (iSCSI) SCSI Features Update F. Knight M. Chadalapaka April 2014 ASCII 49817 25

Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in RFC 7143 (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5.

draft-ietf-storm-iscsi-sam-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7144
RFC7145 Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification M. Ko A. Nezhinsky April 2014 ASCII 214093 91

Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol.

This document obsoletes RFC 5046.

draft-ietf-storm-iser-15 RFC5046 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7145
RFC7146 Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3 D. Black P. Koning April 2014 ASCII 37991 18 IPsec

RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP). This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.

draft-ietf-storm-ipsec-ips-update-04 RFC3720 RFC3723 RFC3821 RFC3822 RFC4018 RFC4172 RFC4173 RFC4174 RFC5040 RFC5041 RFC5042 RFC5043 RFC5044 RFC5045 RFC5046 RFC5047 RFC5048 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7146
RFC7147 Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI) M. Bakke P. Venkatesen April 2014 ASCII 175936 92 ISCSI-MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP).

This document obsoletes RFC 4544.

draft-ietf-storm-iscsimib-04 RFC4544 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7147
RFC7148 Prefix Delegation Support for Proxy Mobile IPv6 X. Zhou J. Korhonen C. Williams S. Gundavelli CJ. Bernardos March 2014 ASCII 60422 27 Prefix Delegation Proxy Mobile IPv6 PMIPv6 Mobile Router

This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes.

draft-ietf-netext-pd-pmip-14 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7148
RFC7149 Software-Defined Networking: A Perspective from within a Service Provider Environment M. Boucadair C. Jacquenet March 2014 ASCII 47516 20 Network Automation Policy Management Connectivity Provisioning Service Parameter Exposure Dynamic Negotiation Dynamic Service Provisioning Autonomic Programmable Networks

Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.

It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.

draft-sin-sdnrg-sdn-approach-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7149
RFC7150 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol F. Zhang A. Farrel March 2014 ASCII 24156 12

The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.

This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object.

draft-ietf-pce-vendor-constraints-11 RFC7470 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7150
RFC7151 File Transfer Protocol HOST Command for Virtual Hosts P. Hethmon R. McMurray March 2014 ASCII 54330 24 FTP HOST

The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.

draft-hethmon-mcmurray-ftpext-ftp-hosts-05 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7151
RFC7152 Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN) R. Key Editor S. DeLord F. Jounay L. Huang Z. Liu M. Paul March 2014 ASCII 22795 12 RMP Rooted-Multipoint VPLS Virtual Private LAN Service E-VPN Ethernet Virtual Private Network MPLS Multi-Protocol Label Switching CE Carrier Ethernet

This document provides functional requirements for the support of Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer 2 Virtual Private Network solutions (referred to as simply "L2VPN"). It is intended that potential solutions will use these requirements as guidelines.

draft-ietf-l2vpn-etree-reqt-05 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7152
RFC7153 IANA Registries for BGP Extended Communities E. Rosen Y. Rekhter March 2014 ASCII 30557 16 Border Gateway Protocol

This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the "IANA Considerations" sections of future protocol specifications. This document updates RFC 4360 and RFC 5701.

draft-ietf-idr-extcomm-iana-02 RFC4360 RFC5701 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7153
RFC7154 IETF Guidelines for Conduct S. Moonesamy Editor March 2014 ASCII 12363 7

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.

This document is an updated version of the guidelines for conduct originally published in RFC 3184.

draft-moonesamy-ietf-conduct-3184bis-07 RFC3184 BCP0054 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7154
RFC7155 Diameter Network Access Server Application G. Zorn Editor April 2014 ASCII 154559 70 AAA Authentication Authorization Accounting Remote Access

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.

draft-ietf-dime-rfc4005bis-14 RFC4005 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7155
RFC7156 Diameter Support for Proxy Mobile IPv6 Localized Routing G. Zorn Q. Wu J. Korhonen April 2014 ASCII 25657 11

In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol.

draft-ietf-dime-pmip6-lr-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7156
RFC7157 IPv6 Multihoming without Network Address Translation O. Troan Editor D. Miles S. Matsushima T. Okimoto D. Wing March 2014 ASCII 49038 22 NPTv6

Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution.

draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7157
RFC7158 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor March 2014 ASCII 27451 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

draft-ietf-json-rfc4627bis-10 RFC7159 PROPOSED STANDARD PROPOSED STANDARD IETF app json 10.17487/RFC7158
RFC7159 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor March 2014 ASCII 27451 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

draft-ietf-json-rfc4627bis-rfc7159bis RFC4627 RFC7158 PROPOSED STANDARD PROPOSED STANDARD IETF app json http://www.rfc-editor.org/errata_search.php?rfc=7159 10.17487/RFC7159
RFC7160 Support for Multiple Clock Rates in an RTP Session M. Petit-Huguenin G. Zorn Editor April 2014 ASCII 25255 13

This document clarifies the RTP specification regarding the use of different clock rates in an RTP session. It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document. It updates RFC 3550.

draft-ietf-avtext-multiple-clock-rates-11 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC7160
RFC7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL) LM. Contreras CJ. Bernardos I. Soto March 2014 ASCII 85916 37 PMIPv6 Proxy Mobile IPv6 multicast handover SIAL

This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).

draft-ietf-multimob-handover-optimization-07 EXPERIMENTAL EXPERIMENTAL IETF int multimob http://www.rfc-editor.org/errata_search.php?rfc=7161 10.17487/RFC7161
RFC7162 IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) A. Melnikov D. Cridland May 2014 ASCII 111930 52 IMAP CONDSTORE QRESYNC VANISHED EXPUNGE quick resynchronization

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.

Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.

This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.

Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.

draft-ietf-qresync-rfc5162bis-10 RFC4551 RFC5162 RFC2683 PROPOSED STANDARD PROPOSED STANDARD IETF app qresync 10.17487/RFC7162
RFC7163 URN for Country-Specific Emergency Services C. Holmberg I. Sedlacek March 2014 ASCII 7884 4 sip emergency urn country 5031 sos

This document updates the registration guidance provided in Section 4.2 of RFC 5031, which allows the registration of service URNs with the 'sos' service type only for emergency services "that are offered widely and in different countries". This document updates those instructions to allow such registrations when, at the time of registration, those services are offered in only one country.

draft-ietf-ecrit-country-emg-urn-03 RFC5031 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC7163
RFC7164 RTP and Leap Seconds K. Gross R. Brandenburg March 2014 ASCII 20637 9 Leap second rtp Real-time Transport Protocol ntp Network Time Protocol UTC Universal Coordinated Time tai International Atomic Time Unix time

This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.

draft-ietf-avtcore-leap-second-08 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7164
RFC7165 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) R. Barnes April 2014 ASCII 58324 25 JWS JWE JWK JWA JWT CMS S/MIME JOSE XMPP ALTO OAuth

Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax (CMS) has provided a binary secure object format based on ASN.1. Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript Object Notation (JSON). This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development.

draft-ietf-jose-use-cases-06 INFORMATIONAL INFORMATIONAL IETF sec jose 10.17487/RFC7165
RFC7166 Supporting Authentication Trailer for OSPFv3 M. Bhatia V. Manral A. Lindem March 2014 ASCII 49533 23

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.

The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.

draft-ietf-ospf-rfc6506bis-05 RFC6506 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7166
RFC7167 A Framework for Point-to-Multipoint MPLS in Transport Networks D. Frost S. Bryant M. Bocci L. Berger April 2014 ASCII 23842 12 mpls-tp mpls

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to-multipoint transport paths.

draft-ietf-mpls-tp-p2mp-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7167
RFC7168 The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) I. Nazar April 1 2014 ASCII 14490 7

The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.

draft-nazar-htcpcp-tea-00 RFC2324 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7168
RFC7169 The NSA (No Secrecy Afforded) Certificate Extension S. Turner April 1 2014 ASCII 5480 3

This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic Key Certificates) digital certificates. Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained. In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party. Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party.

draft-turner-no-secrecy-afforded-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7169
RFC7170 Tunnel Extensible Authentication Protocol (TEAP) Version 1 H. Zhou N. Cam-Winget J. Salowey S. Hanna May 2014 ASCII 205545 101 EAP Tunnel

This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.

draft-ietf-emu-eap-tunnel-method-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC7170
RFC7171 PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods N. Cam-Winget P. Sangster May 2014 ASCII 45604 19 NEA EAP

This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport Layer Security (TLS). The document also describes the intended applicability of PT-EAP.

draft-ietf-nea-pt-eap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea 10.17487/RFC7171
RFC7172 Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling D. Eastlake 3rd M. Zhang P. Agarwal R. Perlman D. Dutt May 2014 ASCII 61855 27 TRILL VLAN Fine-Grained Label

The IETF has standardized Transparent Interconnection of Lots of Links (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.

draft-ietf-trill-fine-labeling-07 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7172
RFC7173 Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires L. Yong D. Eastlake 3rd S. Aldrin J. Hudson May 2014 ASCII 21280 11 TRILL pseudowires MPLS RBridge

This document specifies how to interconnect a pair of Transparent Interconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End (PWE3) standards.

draft-ietf-trill-o-pw-06 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7173
RFC7174 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework S. Salam T. Senevirathne S. Aldrin D. Eastlake 3rd May 2014 ASCII 73464 33 RBridge CFM BFD MEP MIP MA Fault Performance Maintenance Continuity Connectivity Delay Operations Administration

This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM.

draft-ietf-trill-oam-framework-04 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7174
RFC7175 Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support V. Manral D. Eastlake 3rd D. Ward A. Banerjee May 2014 ASCII 24954 12 RBridge Echo one-hop

This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in Routing Bridge (RBridge) campuses based on the RBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.

BFD is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in IP and MPLS networks, using UDP and Associated Channel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL.

draft-ietf-trill-rbridge-bfd-07 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7175
RFC7176 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS D. Eastlake 3rd T. Senevirathne A. Ghanwani D. Dutt A. Banerjee May 2014 ASCII 98059 45 Affinity multicast multi-topology fine-grained VLAN

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes RFC 6326.

draft-ietf-isis-rfc6326bis-03 RFC6326 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7176
RFC7177 Transparent Interconnection of Lots of Links (TRILL): Adjacency D. Eastlake 3rd R. Perlman A. Ghanwani H. Yang V. Manral May 2014 ASCII 77117 35 RBridge TRILL Adjacency BFD p2p point-to-point

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network (LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System (IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325.

draft-ietf-trill-rfc6327bis-04 RFC6327 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7177
RFC7178 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support D. Eastlake 3rd V. Manral Y. Li S. Aldrin D. Ward May 2014 ASCII 49461 21 TRILL native

This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the Transparent Interconnection of Lots of Links (TRILL) protocol.

draft-ietf-trill-rbridge-channel-08 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7178
RFC7179 Transparent Interconnection of Lots of Links (TRILL): Header Extension D. Eastlake 3rd A. Ghanwani V. Manral Y. Li C. Bestler May 2014 ASCII 25422 12 RBridge extension option

The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325.

draft-ietf-trill-rbridge-extension-05 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7179
RFC7180 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates D. Eastlake 3rd M. Zhang A. Ghanwani V. Manral A. Banerjee May 2014 ASCII 56276 24 TRILL RBridge IS-IS reachability overload MTU DEI multicast

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using Intermediate System to Intermediate System (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.

RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439.

draft-ietf-trill-clear-correct-06 RFC6325 RFC6327 RFC6439 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7180
RFC7181 The Optimized Link State Routing Protocol Version 2 T. Clausen C. Dearlove P. Jacquet U. Herberg April 2014 ASCII 253538 115 MANET ad hoc network NHDP

This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).

draft-ietf-manet-olsrv2-19 RFC7183 RFC7187 RFC7188 RFC7466 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7181
RFC7182 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) U. Herberg T. Clausen C. Dearlove April 2014 ASCII 68671 31 NHDP OLSRv2 security integrity routing

This document revises, extends, and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively.

draft-ietf-manet-rfc6622-bis-06 RFC6622 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7182
RFC7183 Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) U. Herberg C. Dearlove T. Clausen April 2014 ASCII 33255 15 MANET OLSRv2 Security Integrity protection ICV

This document specifies integrity and replay protection for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a Timestamp TLV based on Portable Operating System Interface (POSIX) time.

The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444.

This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.

draft-ietf-manet-nhdp-olsrv2-sec-05 RFC6130 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7183 10.17487/RFC7183
RFC7184 Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 U. Herberg R. Cole T. Clausen April 2014 ASCII 175224 86 Network Management Management Information Base MIB SMIv2 Routing MANET Optimized Link STate Routing Protocol version 2

This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing Protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications. This additional state and performance information is useful for troubleshooting problems and performance issues of the routing protocol. Two levels of compliance allow this MIB module to be deployed on constrained routers.

draft-ietf-manet-olsrv2-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7184
RFC7185 Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale C. Dearlove T. Clausen P. Jacquet April 2014 ASCII 59906 25 MANET ad hoc network proactive NHDP neighborhood discovery OLSR OLSRv2 routing protocol metrics

The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.

draft-ietf-manet-olsrv2-metrics-rationale-04 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC7185
RFC7186 Security Threats for the Neighborhood Discovery Protocol (NHDP) J. Yi U. Herberg T. Clausen April 2014 ASCII 45763 20

This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP) and describes their potential impacts on Mobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described.

draft-ietf-manet-nhdp-sec-threats-06 INFORMATIONAL INFORMATIONAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7186 10.17487/RFC7186
RFC7187 Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) C. Dearlove T. Clausen April 2014 ASCII 9341 5

This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays. The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization.

draft-ietf-manet-olsrv2-rmpr-optimization-01 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7187
RFC7188 Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs C. Dearlove T. Clausen April 2014 ASCII 36174 16 MANET OLSRv2 NHDP TLV

This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updates RFC 7181 (OLSRv2) and RFC 6130 (NHDP).

draft-ietf-manet-nhdp-olsrv2-tlv-extension-05 RFC6130 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7188
RFC7189 Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP) G. Mirsky March 2014 ASCII 14254 7 PW VCCV MPLS-TP CC/CV/RDI

This document specifies how signaling and selection processes for Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs. This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined.

draft-ietf-pwe3-mpls-tp-cv-adv-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7189
RFC7190 Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) C. Villamizar March 2014 ASCII 36633 15 MPLS composite link link aggregation ECMP link bundling multipath MPLS-TP

Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.

Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.

draft-ietf-mpls-multipath-use-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7190
RFC7191 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types R. Housley April 2014 ASCII 53803 25

This document defines the syntax for two Cryptographic Message Syntax (CMS) content types: one for key package receipts and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.

draft-housley-ct-keypackage-receipt-n-error-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7191
RFC7192 Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types S. Turner April 2014 ASCII 11255 6 Key Package Key Package Receipt Key Package Error

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData.

draft-turner-ct-keypackage-receipt-n-error-algs-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7192
RFC7193 The application/cms Media Type S. Turner R. Housley J. Schaad April 2014 ASCII 23621 12 Cryptographic Message Syntax

This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types.

draft-turner-application-cms-media-type-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7193 10.17487/RFC7193
RFC7194 Default Port for Internet Relay Chat (IRC) via TLS/SSL R. Hartmann August 2014 ASCII 9497 6

This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.

draft-hartmann-default-port-for-irc-via-tls-ssl-09 RFC1459 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7194
RFC7195 Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) M. Garcia-Martin S. Veikkolainen May 2014 ASCII 92699 39 PSTN

This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN).

draft-ietf-mmusic-sdp-cs-23 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7195
RFC7196 Making Route Flap Damping Usable C. Pelsser R. Bush K. Patel P. Mohapatra O. Maennel May 2014 ASCII 15202 8 rfd

Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process.

draft-ietf-idr-rfd-usable-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7196 10.17487/RFC7196
RFC7197 Duplication Delay Attribute in the Session Description Protocol A. Begen Y. Cai H. Ou April 2014 ASCII 22559 11 Interleaving temporal diversity temporal redundancy time shifted delayed duplication

A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply "delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol.

draft-ietf-mmusic-delayed-duplication-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7197
RFC7198 Duplicating RTP Streams A. Begen C. Perkins April 2014 ASCII 29317 13 RTP duplication live/live redundancy

Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.

draft-ietf-avtext-rtp-duplication-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC7198
RFC7199 Location Configuration Extensions for Policy Management R. Barnes M. Thomson J. Winterbottom H. Tschofenig April 2014 ASCII 41313 20 geopriv geolocation privacy policy

Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules.

draft-ietf-geopriv-policy-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7199
RFC7200 A Session Initiation Protocol (SIP) Load-Control Event Package C. Shen H. Schulzrinne A. Koike April 2014 ASCII 98689 44 SIP Overload Control Server Performance

This specification defines a load-control event package for the Session Initiation Protocol (SIP). It allows SIP entities to distribute load-filtering policies to other SIP entities in the network. The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts.

draft-ietf-soc-load-control-event-package-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7200
RFC7201 Options for Securing RTP Sessions M. Westerlund C. Perkins April 2014 ASCII 92462 37 Secure RTP SRTP key management real-time media

The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.

draft-ietf-avtcore-rtp-security-options-10 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC7201
RFC7202 Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution C. Perkins M. Westerlund April 2014 ASCII 23428 10 SRTP RTP Profile Payload Format

This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.

draft-ietf-avt-srtp-not-mandatory-16 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC7202
RFC7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information T. Takahashi K. Landfield Y. Kadobayashi April 2014 ASCII 57694 28 data structure information architecture incident response response team security incident information exchange knowledge sharing security operation automation vulnerability CERT CSIRT

This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information.

draft-ietf-mile-sci-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC7203
RFC7204 Requirements for Labeled NFS T. Haynes April 2014 ASCII 39350 18 NFSv4

This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into the Network File System (NFS) version 4.2 (NFSv4.2). It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. The intent here is not to present the protocol changes but to describe the environment in which they reside.

draft-ietf-nfsv4-labreqs-05 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC7204
RFC7205 Use Cases for Telepresence Multistreams A. Romanow S. Botzko M. Duckworth R. Even Editor April 2014 ASCII 42087 17

Telepresence conferencing systems seek to create an environment that gives users (or user groups) that are not co-located a feeling of co-located presence through multimedia communication that includes at least audio and video signals of high fidelity. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would enable senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference.

draft-ietf-clue-telepresence-use-cases-09 INFORMATIONAL INFORMATIONAL IETF rai clue 10.17487/RFC7205
RFC7206 Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks P. Jones G. Salgueiro J. Polk L. Liess H. Kaplan May 2014 ASCII 28383 15

This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.

draft-ietf-insipid-session-id-reqts-11 INFORMATIONAL INFORMATIONAL IETF rai insipid 10.17487/RFC7206
RFC7207 A Uniform Resource Name (URN) Namespace for Eurosystem Messaging M. Ortseifen G. Dickfeld April 2014 ASCII 15690 8 URN Namespace Eurosystem TARGET2 TARGET2-Securities ESCB

This document defines and registers with IANA a Uniform Resource Name (URN) namespace for usage within messages standardized by the Eurosystem. The URN namespace is managed by Deutsche Bundesbank, which is a member of the European System of Central Banks (ESCB).

draft-bundesbank-eurosystem-namespace-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7207
RFC7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 S. Kitterman April 2014 ASCII 144189 64 spoofing spf anti-forgery authentication

Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.

This document obsoletes RFC 4408.

draft-ietf-spfbis-4408bis-21 RFC4408 RFC7372 PROPOSED STANDARD PROPOSED STANDARD IETF app spfbis http://www.rfc-editor.org/errata_search.php?rfc=7208 10.17487/RFC7208
RFC7209 Requirements for Ethernet VPN (EVPN) A. Sajassi R. Aggarwal J. Uttaro N. Bitar W. Henderickx A. Isaac May 2014 ASCII 34040 15 ethernet l2vpn

The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues.

draft-ietf-l2vpn-evpn-req-07 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7209
RFC7210 Database of Long-Lived Symmetric Cryptographic Keys R. Housley T. Polk S. Hartman D. Zhang April 2014 ASCII 32642 14

This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database. In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.

draft-ietf-karp-crypto-key-table-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg karp http://www.rfc-editor.org/errata_search.php?rfc=7210 10.17487/RFC7210
RFC7211 Operations Model for Router Keying S. Hartman D. Zhang June 2014 ASCII 47824 18

The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face.

draft-ietf-karp-ops-model-10 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC7211
RFC7212 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol D. Frost S. Bryant M. Bocci June 2014 ASCII 52340 23

The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes.

draft-ietf-mpls-gach-adv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7212
RFC7213 MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing D. Frost S. Bryant M. Bocci June 2014 ASCII 20407 9 MPLS

The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets.

draft-ietf-mpls-tp-ethernet-addressing-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7213
RFC7214 Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry L. Andersson C. Pignataro May 2014 ASCII 12382 7

RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586.

This document also updates RFCs 6374, 6378, 6427, and 6428.

draft-ietf-mpls-moving-iana-registries-04 RFC5586 RFC6374 RFC6378 RFC6427 RFC6428 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7214
RFC7215 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations L. Jakab A. Cabellos-Aparicio F. Coras J. Domingo-Pascual D. Lewis April 2014 ASCII 68686 30 LISP deployment

This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.

draft-ietf-lisp-deployment-12 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC7215
RFC7216 Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS M. Thomson R. Bellis April 2014 ASCII 39389 18 HELD LIS Discovery NAT Residential Gateway

The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.

This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.

draft-ietf-geopriv-res-gw-lis-discovery-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7216
RFC7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) F. Gont April 2014 ASCII 48497 19

This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).

draft-ietf-6man-stable-privacy-addresses-17 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7217
RFC7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) O. Gudmundsson April 2014 ASCII 8907 5 DNSSEC DANE Applications

Experience has shown that people get confused when discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in TLSA records. This document updates the format of the IANA registry created by RFC 6698.

draft-ietf-dane-registry-acronyms-04 RFC6698 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7218
RFC7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) M. Bagnulo A. Garcia-Martinez May 2014 ASCII 90423 38 IPv6 ingress filtering packet filtering Neighbor Discovery

This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.

draft-ietf-savi-send-11 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC7219
RFC7220 Description Option for the Port Control Protocol (PCP) M. Boucadair R. Penno D. Wing May 2014 ASCII 11332 6

This document extends the Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does this by defining a new DESCRIPTION option.

draft-ietf-pcp-description-option-05 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7220
RFC7221 Handling of Internet-Drafts by IETF Working Groups A. Farrel D. Crocker Editor April 2014 ASCII 31669 14 IETF process working group Internet-Draft adoption handling creation

The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication.

draft-crocker-id-adoption-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7221
RFC7222 Quality-of-Service Option for Proxy Mobile IPv6 M. Liebsch P. Seite H. Yokota J. Korhonen S. Gundavelli May 2014 ASCII 139026 58 QoS Quality of Service PMIP-QoS PMIPv6-QoS WiFi-QoS 3GPP-QoS

This specification defines a new mobility option, the Quality-of- Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches.

draft-ietf-netext-pmip6-qos-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7222
RFC7223 A YANG Data Model for Interface Management M. Bjorklund May 2014 ASCII 70537 39 NETCONF ietf-interfaces

This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data and state data (status information and counters for the collection of statistics).

draft-ietf-netmod-interfaces-cfg-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7223 10.17487/RFC7223
RFC7224 IANA Interface Type YANG Module M. Bjorklund May 2014 ASCII 51377 37 yang netconf iana-if-type

This document defines the initial version of the iana-if-type YANG module.

draft-ietf-netmod-iana-if-type-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7224
RFC7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) M. Boucadair May 2014 ASCII 40239 17

This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals.

draft-ietf-pcp-nat64-prefix64-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7225
RFC7226 Requirements for Advanced Multipath in MPLS Networks C. Villamizar Editor D. McDysan Editor S. Ning A. Malis L. Yong May 2014 ASCII 38581 17 MPLS Advanced Multipath composite link link aggregation ECMP link bundling delay metric

This document provides a set of requirements for Advanced Multipath in MPLS networks.

Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques.

draft-ietf-rtgwg-cl-requirement-16 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC7226
RFC7227 Guidelines for Creating New DHCPv6 Options D. Hankins T. Mrugalski M. Siodelski S. Jiang S. Krishnan May 2014 ASCII 83694 35 DHCPv6 option guidelines option guidance option format

This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.

draft-ietf-dhc-option-guidelines-17 RFC3315 BCP0187 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=7227 10.17487/RFC7227
RFC7228 Terminology for Constrained-Node Networks C. Bormann M. Ersue A. Keranen May 2014 ASCII 37635 17 IoT Internet of Things Embedded Internet Smart Object Sensor Network WSN Constrained node Constrained network LLN LoWPAN 6LoWPAN Always-on Low-power Energy efficient

The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.

draft-ietf-lwig-terminology-07 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC7228
RFC7229 Object Identifiers for Test Certificate Policies R. Housley May 2014 ASCII 6589 4

This document provides several certificate policy identifiers for testing certificate handling software.

draft-housley-pkix-test-oids-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7229
RFC7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing R. Fielding Editor J. Reschke Editor June 2014 ASCII 205947 89 Hyptertext Transfer Protocol HTTP HTTP message format

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.

draft-ietf-httpbis-p1-messaging-26 RFC2145 RFC2616 RFC2817 RFC2818 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7230 10.17487/RFC7230
RFC7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content R. Fielding Editor J. Reschke Editor June 2014 ASCII 235053 101 Hypertext Transfer Protocol HTTP HTTP semantics HTTP payload HTTP content HTTP method HTTP status code

The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.

draft-ietf-httpbis-p2-semantics-26 RFC2616 RFC2817 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7231 10.17487/RFC7231
RFC7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests R. Fielding Editor J. Reschke Editor June 2014 ASCII 56696 28 HyperText Transfer Protocol HTTP HTTP conditional requests

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.

draft-ietf-httpbis-p4-conditional-26 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7232
RFC7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests R. Fielding Editor Y. Lafon Editor J. Reschke Editor June 2014 ASCII 46933 25

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.

draft-ietf-httpbis-p5-range-26 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7233 10.17487/RFC7233
RFC7234 Hypertext Transfer Protocol (HTTP/1.1): Caching R. Fielding Editor M. Nottingham Editor J. Reschke Editor June 2014 ASCII 90647 43 HTTP caching HyperText Transfer Protocol HTTP

The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.

draft-ietf-httpbis-p6-cache-26 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7234
RFC7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication R. Fielding Editor J. Reschke Editor June 2014 ASCII 38142 19 HTTP authentication HyperText Transfer Protocol HTTP

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.

draft-ietf-httpbis-p7-auth-26 RFC2616 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7235
RFC7236 Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations J. Reschke June 2014 ASCII 5770 3 HyperText Transfer Protocol HTTP Authentication Authentication Scheme

This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.

draft-ietf-httpbis-authscheme-registrations-10 INFORMATIONAL INFORMATIONAL IETF app httpbis 10.17487/RFC7236
RFC7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations J. Reschke June 2014 ASCII 8732 5 HyperText Transfer Protocol HTTP Request Method

This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.

draft-ietf-httpbis-method-registrations-15 INFORMATIONAL INFORMATIONAL IETF app httpbis 10.17487/RFC7237
RFC7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) J. Reschke June 2014 ASCII 10623 6 HTTP redirect status code

This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).

draft-reschke-http-status-308-07 RFC7538 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC7238
RFC7239 Forwarded HTTP Extension A. Petersson M. Nilsson June 2014 ASCII 35003 16 proxy x-forwarded-for x-forwarded-by x-forwarded-host x-forwarded-proto via

This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.

This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.

draft-ietf-appsawg-http-forwarded-10 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7239
RFC7240 Prefer Header for HTTP J. Snell June 2014 ASCII 32796 17 http prefer

This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.

draft-snell-http-prefer-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7240 10.17487/RFC7240
RFC7241 The IEEE 802/IETF Relationship S. Dawkins P. Thaler D. Romascanu B. Aboba Editor July 2014 ASCII 80378 35 snmp aaa simple network management protocol authentication authorization accounting

This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.

Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication.

draft-iab-rfc4441rev-08 RFC4441 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7241 10.17487/RFC7241
RFC7242 Delay-Tolerant Networking TCP Convergence-Layer Protocol M. Demmer J. Ott S. Perreault June 2014 ASCII 53818 22

This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of the IRTF's DTN Research Group (DTNRG).

draft-irtf-dtnrg-tcp-clayer-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7242
RFC7243 RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric V. Singh Editor J. Ott I. Curcio May 2014 ASCII 23198 12 rtp reception statistics de-jitter buffer

The RTP Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a report computing the bytes discarded from the de-jitter buffer after successful reception.

draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7243
RFC7244 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting H. Asaeda Q. Wu R. Huang May 2014 ASCII 27341 13

This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of initial synchronization delay and synchronization offset metrics for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-synchronization-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7244
RFC7245 An Architecture for Media Recording Using the Session Initiation Protocol A. Hutton Editor L. Portman Editor R. Jain K. Rehor May 2014 ASCII 34314 16 sip

Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment that is based on the Session Initiation Protocol (SIP).

draft-ietf-siprec-architecture-12 INFORMATIONAL INFORMATIONAL IETF rai siprec 10.17487/RFC7245
RFC7246 Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context IJ. Wijnands Editor P. Hitchen N. Leymann W. Henderickx A. Gulko J. Tantsura June 2014 ASCII 24698 13

An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non-label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.

draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 RFC7438 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7246
RFC7247 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling P. Saint-Andre A. Houri J. Hildebrand May 2014 ASCII 57218 24 XMPP SIP

As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.

draft-ietf-stox-core-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai stox 10.17487/RFC7247
RFC7248 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence P. Saint-Andre A. Houri J. Hildebrand May 2014 ASCII 60875 30 XMPP Jabber SIP SIMPLE IM Instant Messaging Presence

This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).

draft-ietf-stox-presence-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai stox 10.17487/RFC7248
RFC7249 Internet Numbers Registries R. Housley May 2014 ASCII 10070 6

RFC 7020 provides information about the Internet Numbers Registry System and how it is used in the distribution of autonomous system (AS) numbers and globally unique unicast Internet Protocol (IP) address space.

This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.

draft-housley-number-registries-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7249
RFC7250 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) P. Wouters Editor H. Tschofenig Editor J. Gilmore S. Weiler T. Kivinen June 2014 ASCII 38040 18 TLS DNSSEC DANE Raw Public Key

This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.

draft-ietf-tls-oob-pubkey-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7250
RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS D. McGrew D. Bailey M. Campagna R. Dugal June 2014 ASCII 18851 10

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data-origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security. The cipher suites defined in this document use Elliptic Curve Cryptography (ECC) and are advantageous in networks with limited bandwidth.

draft-mcgrew-tls-aes-ccm-ecc-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7251
RFC7252 The Constrained Application Protocol (CoAP) Z. Shelby K. Hartke C. Bormann June 2014 ASCII 258789 112

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.

CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.

draft-ietf-core-coap-18 PROPOSED STANDARD PROPOSED STANDARD IETF app core 10.17487/RFC7252
RFC7253 The OCB Authenticated-Encryption Algorithm T. Krovetz P. Rogaway May 2014 ASCII 39712 19 OCB AEAD authenticated-encryption

This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG).

draft-irtf-cfrg-ocb-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7253
RFC7254 A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI) M. Montemurro Editor A. Allen D. McDonald P. Gosden May 2014 ASCII 33488 16 GSM UMTS LTE 3GPP Mobile identifier instance ID

This specification defines a Uniform Resource Name (URN) namespace for the Global System for Mobile Communications Association (GSMA) and a Namespace Specific String (NSS) for the International Mobile station Equipment Identity (IMEI), as well as an associated parameter for the International Mobile station Equipment Identity and Software Version number (IMEISV). The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, Universal Mobile Telecommunications System (UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA. URNs from this namespace almost always contain personally identifiable information and need to be treated accordingly.

draft-montemurro-gsma-imei-urn-20 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7254
RFC7255 Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID A. Allen Editor May 2014 ASCII 21606 9 GSM UMTS LTE 3GPP IMS SIP GRUU Mobile identifier instance ID

This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association (GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior.

draft-allen-dispatch-imei-urn-as-instanceid-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7255
RFC7256 Multicast Control Extensions for the Access Node Control Protocol (ANCP) F. Le Faucheur R. Maglione T. Taylor July 2014 ASCII 234572 99

This document specifies the extensions to the Access Node Control Protocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document (RFC 5851) and one additional use case described in this document. These use cases are organized into the following ANCP capabilities:

o multicast replication initiated by the Network Access Server (NAS);

o conditional access and admission control with white and black lists;

o conditional access and admission control with grey lists;

o bandwidth delegation; and

o committed bandwidth reporting.

These capabilities may be combined according to the rules given in this specification.

This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.

draft-ietf-ancp-mc-extensions-16 RFC6320 PROPOSED STANDARD PROPOSED STANDARD IETF int ancp 10.17487/RFC7256
RFC7257 Virtual Private LAN Service (VPLS) Management Information Base T. Nadeau Editor A. Kiran Koushik Editor R. Mediratta Editor July 2014 ASCII 89099 48

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Virtual Private LAN services. It needs to be used in conjunction with the Pseudowire (PW) Management Information Base (PW-STD-MIB from RFC 5601).

draft-ietf-l2vpn-vpls-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7257 10.17487/RFC7257
RFC7258 Pervasive Monitoring Is an Attack S. Farrell H. Tschofenig May 2014 ASCII 13396 6 pervasive monitoring

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

draft-farrell-perpass-attack-06 BCP0188 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7258
RFC7259 The Jabber-ID Header Field P. Saint-Andre May 2014 ASCII 12816 7 Jabber XMPP Extensible Messaging and Presence Protocol email netnews message header field IM instant messaging

This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.

draft-saintandre-jabberid-13 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7259
RFC7260 GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration A. Takacs D. Fedyk J. He June 2014 ASCII 58030 24 MPLS-TP Transport Profile GELS Ethernet Label Switching PBB-TE connectivity monitoring OAM configuration

Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling.

draft-ietf-ccamp-oam-configuration-fwk-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=7260 10.17487/RFC7260
RFC7261 Offer/Answer Considerations for G723 Annex A and G729 Annex B M. Perumal P. Ravindran May 2014 ASCII 14097 8 offer answer

This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D, and G729E when the value of the annexa or annexb parameter does not match in the Session Description Protocol (SDP) offer and answer.

draft-ietf-mmusic-sdp-g723-g729-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7261
RFC7262 Requirements for Telepresence Multistreams A. Romanow S. Botzko M. Barnes June 2014 ASCII 26403 12

This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein.

draft-ietf-clue-telepresence-requirements-07 INFORMATIONAL INFORMATIONAL IETF rai clue 10.17487/RFC7262
RFC7263 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing N. Zong X. Jiang R. Even Y. Zhang June 2014 ASCII 42104 20 P2P

This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.

draft-ietf-p2psip-drr-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7263
RFC7264 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing N. Zong X. Jiang R. Even Y. Zhang June 2014 ASCII 31995 15 P2P

This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.

draft-ietf-p2psip-rpr-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7264
RFC7265 jCal: The JSON Format for iCalendar P. Kewisch C. Daboo M. Douglass May 2014 ASCII 56274 31

This specification defines "jCal", a JSON format for iCalendar data. The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.

draft-ietf-jcardcal-jcal-10 RFC7529 PROPOSED STANDARD PROPOSED STANDARD IETF app jcardcal 10.17487/RFC7265
RFC7266 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting A. Clark Q. Wu R. Schott G. Zorn June 2014 ASCII 48110 23

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated Session Description Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-qoe-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7266
RFC7267 Dynamic Placement of Multi-Segment Pseudowires L. Martini Editor M. Bocci Editor F. Balus Editor June 2014 ASCII 49414 24 pw pw switching point pe sub-tlv

RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet Switched Network domains. A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.

draft-ietf-pwe3-dynamic-ms-pw-22 RFC6073 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7267
RFC7268 RADIUS Attributes for IEEE 802 Networks B. Aboba J. Malinen P. Congdon J. Salowey M. Jones July 2014 ASCII 56686 29

RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs). This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute. This document updates RFCs 3580 and 4072.

draft-ietf-radext-ieee802ext-12 RFC3580 RFC4072 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC7268
RFC7269 NAT64 Deployment Options and Experience G. Chen Z. Cao C. Xie D. Binet June 2014 ASCII 56043 22

This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document.

draft-ietf-v6ops-nat64-experience-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7269
RFC7270 Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX) A. Yourtchenko P. Aitken B. Claise June 2014 ASCII 33990 21 IPFIX

This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012.

draft-yourtchenko-cisco-ies-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7270
RFC7271 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators J. Ryoo Editor E. Gray Editor H. van Helvoort A. D'Alessandro T. Cheung E. Osborne June 2014 ASCII 87586 40 PSC mode APS mode capabilities priority non-revertive MS-W support SD support EXER support

This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.

This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode.

This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.

This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.

draft-ietf-mpls-tp-psc-itu-04 RFC6378 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7271
RFC7272 Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) R. van Brandenburg H. Stokking O. van Deventer F. Boronat M. Montagud K. Gross June 2014 ASCII 56261 23 Inter-Destination Media Synchronization RTP Control Protocol RTCP

This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize.

Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.

draft-ietf-avtcore-idms-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7272
RFC7273 RTP Clock Source Signalling A. Williams K. Gross R. van Brandenburg H. Stokking June 2014 ASCII 63009 30 clock source

NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies Session Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session.

draft-ietf-avtcore-clksrc-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7273
RFC7274 Allocating and Retiring Special-Purpose MPLS Labels K. Kompella L. Andersson A. Farrel June 2014 ASCII 23442 11

Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special-purpose labels" in this document.

As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.

This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry.

This document updates a number of previous RFCs that use the term "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.

draft-ietf-mpls-special-purpose-labels-06 RFC3032 RFC3038 RFC3209 RFC3811 RFC4182 RFC4928 RFC5331 RFC5586 RFC5921 RFC5960 RFC6391 RFC6478 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7274
RFC7275 Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy L. Martini S. Salam A. Sajassi M. Bocci S. Matsushima T. Nadeau June 2014 ASCII 172294 83 iccp

This document specifies an Inter-Chassis Communication Protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems. It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms.

draft-ietf-pwe3-iccp-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7275
RFC7276 An Overview of Operations, Administration, and Maintenance (OAM) Tools T. Mizrahi N. Sprecher E. Bellagamba Y. Weingarten June 2014 ASCII 120925 53

Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.

This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.

The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.

draft-ietf-opsawg-oam-overview-16 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7276
RFC7277 A YANG Data Model for IP Management M. Bjorklund June 2014 ASCII 50043 30 netmod

This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data.

draft-ietf-netmod-ip-cfg-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7277
RFC7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link C. Byrne D. Drown A. Vizdal June 2014 ASCII 19965 10

This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples.

draft-ietf-v6ops-64share-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7278
RFC7279 An Acceptable Use Policy for New ICMP Types and Codes M. Shore C. Pignataro May 2014 ASCII 17829 10 icmp icmpv4 icmpv6

In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use.

This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not.

draft-shore-icmp-aup-12 BCP0189 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7279
RFC7280 IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry G. Fairhurst June 2014 ASCII 14954 7 ULE IANA

This document updates RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) Next- Header registry. This registry is used by ULE and Generic Stream Encapsulation (GSE) to record the code points of Extension Headers and protocols supported by these encapsulation protocols.

draft-fairhurst-ipdvb-ule-iana-07 RFC4326 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7280
RFC7281 Authentication-Results Registration for S/MIME Signature Verification A. Melnikov June 2014 ASCII 23717 11 Authentication-Results S/MIME

RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication- Results header field for S/MIME-related signature checks.

draft-melnikov-authentication-results-smime-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7281
RFC7282 On Consensus and Humming in the IETF P. Resnick June 2014 ASCII 52339 19 accommodate agree agreement appease argue argument balloting capitulated capitulation chair choice choose coin compromise count decide decision disagree disagreement hands horse-trade horse-trading hum issue judge judging king majority member minority object objection objector president rough unaddressed vote voting working group

The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.

Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.

draft-resnick-on-consensus-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7282
RFC7283 Handling Unknown DHCPv6 Messages Y. Cui Q. Sun T. Lemon July 2014 ASCII 13021 7 DHCPv6 Unknown Messages

DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages. This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents. This document updates RFC 3315.

draft-ietf-dhc-dhcpv6-unknown-msg-08 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7283
RFC7284 The Profile URI Registry M. Lanthaler June 2014 ASCII 8848 5 profile profiles URI registry

This document defines a registry for profile URIs to be used in specifications standardizing profiles.

draft-lanthaler-profile-registry-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7284
RFC7285 Application-Layer Traffic Optimization (ALTO) Protocol R. Alimi Editor R. Penno Editor Y. Yang Editor S. Kiesel S. Previdi W. Roome S. Shalunov R. Woundy September 2014 ASCII 194499 91 ALTO Information Resources Network Map PID Filtered Network Map Cost Map Endpoint Property Service Endpoint Cost Service

Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.

The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.

This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.

draft-ietf-alto-protocol-27 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC7285
RFC7286 Application-Layer Traffic Optimization (ALTO) Server Discovery S. Kiesel M. Stiemerling N. Schwan M. Scharf H. Song November 2014 ASCII 32830 15

The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers.

This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.

draft-ietf-alto-server-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC7286
RFC7287 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains T. Schmidt Editor S. Gao H. Zhang M. Waehlisch June 2014 ASCII 66766 28

Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations.

draft-ietf-multimob-pmipv6-source-09 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7287
RFC7288 Reflections on Host Firewalls D. Thaler June 2014 ASCII 28885 13 Filter Filtering

In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice. Unlike traditional firewalls that protect network links, host firewalls run in end-user systems. Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall. It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication. In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward.

draft-iab-host-firewalls-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7288
RFC7289 Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs V. Kuarsingh Editor J. Cianfarani June 2014 ASCII 45731 20 NAT444 LSN Large-Scale NAT

This document specifies a framework to integrate a Network Address Translation (NAT) layer into an operator's network to function as a Carrier-Grade NAT (also known as CGN or Large-Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber-side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near- term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model that allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs, which allow for virtual routing separation, helping ease the CGN's impact on the network. This document does not intend to defend the merits of CGN.

draft-ietf-opsawg-lsn-deployment-06 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7289
RFC7290 Test Plan and Results for Advancing RFC 2680 on the Standards Track L. Ciavattone R. Geib A. Morton M. Wieser July 2014 ASCII 59898 31 packet loss IPPM implementation comparison perfas+ netem IPPM comparison metric test, WIPM NetProbe

This memo provides the supporting test plan and results to advance RFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680.

draft-ietf-ippm-testplan-rfc2680-05 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7290
RFC7291 DHCP Options for the Port Control Protocol (PCP) M. Boucadair R. Penno D. Wing July 2014 ASCII 20868 11 PCP Server discovery Port Mapping Shared Address

This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document.

draft-ietf-pcp-dhcp-13 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7291
RFC7292 PKCS #12: Personal Information Exchange Syntax v1.1 K. Moriarty Editor M. Nystrom S. Parkinson A. Rusch M. Scott July 2014 ASCII 58991 29 PKCS#12 PKCS12v1.1 PKCS#12v1.1

PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.

This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

draft-moriarty-pkcs12v1-1-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7292 10.17487/RFC7292
RFC7293 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension W. Mills M. Kucherawy July 2014 ASCII 54440 24 Security Privacy Email Account Expiration

This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called "Require-Recipient-Valid-Since" that can be used to tunnel the request through servers that do not support the extension.

The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications.

draft-ietf-appsawg-rrvs-header-field-11 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7293
RFC7294 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications A. Clark G. Zorn C. Bi Q. Wu July 2014 ASCII 43611 22 Real Time Control Protocol

This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of concealment metrics for audio applications of RTP.

draft-ietf-xrblock-rtcp-xr-loss-conceal-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7294
RFC7295 Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication H. Tschofenig L. Eggert Z. Sarker July 2014 ASCII 59655 26 Congestion Control RTCWEB Workshop Real-Time Communication

This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community.

The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF).

draft-iab-cc-workshop-report-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7295
RFC7296 Internet Key Exchange Protocol Version 2 (IKEv2) C. Kaufman P. Hoffman Y. Nir P. Eronen T. Kivinen October 2014 ASCII 354358 142 IKE IPsec

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.

draft-kivinen-ipsecme-ikev2-rfc5996bis-04 RFC5996 RFC7427 STD0079 INTERNET STANDARD INTERNET STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7296 10.17487/RFC7296
RFC7297 IP Connectivity Provisioning Profile (CPP) M. Boucadair C. Jacquenet N. Wang July 2014 ASCII 48281 22

This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.

Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.

draft-boucadair-connectivity-provisioning-profile-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7297
RFC7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication D. Ovsienko July 2014 ASCII 128503 55 routing protocol authentication applied cryptography

This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.

draft-ovsienko-babel-hmac-authentication-09 RFC6126 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7298
RFC7299 Object Identifier Registry for the PKIX Working Group R. Housley July 2014 ASCII 65861 30 Public-Key Infrastructure using X.509

When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.

draft-housley-pkix-oids-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7299
RFC7300 Reservation of Last Autonomous System (AS) Numbers J. Haas J. Mitchell July 2014 ASCII 7952 5 asn last asns

This document reserves two Autonomous System Numbers (ASNs) at the end of the 16-bit and 32-bit ranges, described in this document as "Last ASNs", and provides guidance to implementers and operators on their use. This document updates Section 10 of RFC 1930.

draft-ietf-idr-last-as-reservation-07 RFC1930 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC7300
RFC7301 Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension S. Friedl A. Popov A. Langley E. Stephan July 2014 ASCII 17439 9 ALPN

This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.

draft-ietf-tls-applayerprotoneg-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7301
RFC7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition P. Lemieux July 2014 ASCII 14419 8 EIDR Entertainment Identifier Registry URN

Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.

draft-pal-eidr-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7302
RFC7303 XML Media Types H. Thompson C. Lilley July 2014 ASCII 77654 35 application/xml application/xml-external-parsed-entity application/xml-dtd text/xml text/xml-external-parsed-entity +xml

This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.

draft-ietf-appsawg-xml-mediatypes-10 RFC3023 RFC6839 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7303
RFC7304 A Method for Mitigating Namespace Collisions W. Kumari July 2014 ASCII 6626 4

This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict.

draft-wkumari-dnsop-defense-collision-mitigate-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7304
RFC7305 Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT) E. Lear Editor July 2014 ASCII 37799 17

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). The workshop was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack). This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time. Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

draft-iab-itat-report-04 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7305 10.17487/RFC7305
RFC7306 Remote Direct Memory Access (RDMA) Protocol Extensions H. Shah F. Marti W. Noureddine A. Eiriksson R. Sharp June 2014 ASCII 73986 34 iWARP RDMAP DDP RDMA DMA

This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP) as specified in RFC 5040. RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper-Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data.

draft-ietf-storm-rdmap-ext-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7306
RFC7307 LDP Extensions for Multi-Topology Q. Zhao K. Raza C. Zhou L. Fang L. Li D. King July 2014 ASCII 39530 20 MT Label Distribution Protocol

Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks, new extensions are required.

This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.

draft-ietf-mpls-ldp-multi-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7307
RFC7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) E. Osborne July 2014 ASCII 14811 7 colors link colors igp te extensions

MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).

This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.

draft-ietf-mpls-extended-admin-group-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7308
RFC7309 Redundancy Mechanism for Inter-domain VPLS Service Z. Liu L. Jin R. Chen D. Cai S. Salam July 2014 ASCII 24644 12 ICCP PW

In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domain VPLS solution that provides PE node redundancy across domains.

draft-ietf-l2vpn-vpls-inter-domain-redundancy-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC7309
RFC7310 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs J. Lindsay H. Foerster July 2014 ASCII 32743 16

This document specifies a scheme for packetizing Standard apt-X or Enhanced apt-X encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP).

draft-ietf-payload-rtp-aptx-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC7310
RFC7311 The Accumulated IGP Metric Attribute for BGP P. Mohapatra R. Fernando E. Rosen J. Uttaro August 2014 ASCII 32615 15

Routing protocols that have been designed to run within a single administrative domain (IGPs) generally do so by assigning a metric to each link and then choosing, as the installed path between two nodes, the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains (autonomous systems), does not make its path-selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so.

draft-ietf-idr-aigp-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7311
RFC7312 Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) J. Fabini A. Morton August 2014 ASCII 41125 17 Measurement Wireless Reactive Repeatability Continuity Actionable Conservative Spatial Composition Temporal Composition

To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.

draft-ietf-ippm-2330-update-05 RFC2330 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7312
RFC7313 Enhanced Route Refresh Capability for BGP-4 K. Patel E. Chen B. Venkatachalapathy July 2014 ASCII 15111 8 Border Gateway Protocol bgp rib BGP Routing Information Base

In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner. This document updates RFC 2918.

draft-ietf-idr-bgp-enhanced-route-refresh-10 RFC2918 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7313
RFC7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option M. Andrews July 2014 ASCII 8473 4 IXFR AXFR zone transfer DNS SOA

This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries.

draft-andrews-dnsext-expire-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7314
RFC7315 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP R. Jesske K. Drage C. Holmberg July 2014 ASCII 101144 43

This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455.

draft-drage-sipping-rfc3455bis-14 RFC3455 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7315
RFC7316 The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header) J. van Elburg K. Drage M. Ohsugi S. Schubert K. Arai July 2014 ASCII 33599 15

This document specifies the SIP P-Private-Network-Indication P-header used by the 3GPP. The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network and identifies that private network. A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic.

draft-vanelburg-dispatch-private-network-ind-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7316
RFC7317 A YANG Data Model for System Management A. Bierman M. Bjorklund August 2014 ASCII 60119 35 NETCONF

This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.

draft-ietf-netmod-system-mgmt-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7317
RFC7318 Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates A. Newton G. Huston July 2014 ASCII 8214 5

This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of Resource Public Key Infrastructure (RPKI) resource certificates.

draft-ietf-sidr-policy-qualifiers-02 RFC6487 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7318
RFC7319 IANA Considerations for Connectivity Fault Management (CFM) Code Points D. Eastlake 3rd July 2014 ASCII 7759 5 CFM OAM Connectivity Continuity Fault IANA TRILL

IEEE 802.1 has specified Connectivity Fault Management (CFM) Operations, Administration, and Maintenance (OAM) facilities. CFM messages are structured with an OpCode field and have provision for the inclusion of TLV-structured information. IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF. This document specifies the IANA considerations for the assignment of values from these blocks.

draft-eastlake-iana-cfm-considerations-02 BCP0191 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7319
RFC7320 URI Design and Ownership M. Nottingham July 2014 ASCII 18275 9 URI structure

Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards.

draft-ietf-appsawg-uri-get-off-my-lawn-05 RFC3986 BCP0190 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7320 10.17487/RFC7320
RFC7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) D. McGrew P. Hoffman August 2014 ASCII 25724 11

This document updates the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.

ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.

draft-ietf-ipsecme-esp-ah-reqts-10 RFC4835 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7321
RFC7322 RFC Style Guide H. Flanagan S. Ginoza September 2014 ASCII 49915 24 editorial guidance format style manual house style

This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".

draft-iab-styleguide-02 RFC2223 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7322
RFC7323 TCP Extensions for High Performance D. Borman B. Braden V. Jacobson R. Scheffenegger Editor September 2014 ASCII 106013 49 Timestamps Timestamp RTT RTTM Window Scale PAWS TCP options

This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.

This document obsoletes RFC 1323 and describes changes from it.

draft-ietf-tcpm-1323bis-21 RFC1323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC7323
RFC7324 Updates to MPLS Transport Profile Linear Protection E. Osborne July 2014 ASCII 23687 11 multiprotocol label switching mpls-tp psc protection state coordination

This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC 6378.

draft-ietf-mpls-psc-updates-06 RFC6378 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7324
RFC7325 MPLS Forwarding Compliance and Performance Requirements C. Villamizar Editor K. Kompella S. Amante A. Malis C. Pignataro August 2014 ASCII 139536 59 MPLS ECMP link bundling multipath MPLS-TP forwarding

This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers.

draft-ietf-mpls-forwarding-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7325
RFC7326 Energy Management Framework J. Parello B. Claise B. Schoening J. Quittek September 2014 ASCII 107145 54

This document defines a framework for Energy Management (EMAN) for devices and device components within, or connected to, communication networks. The framework presents a physical reference model and information model. The information model consists of an Energy Management Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery. Additionally, the framework models relationships and capabilities between Energy Objects.

draft-ietf-eman-framework-19 INFORMATIONAL INFORMATIONAL IETF ops eman 10.17487/RFC7326
RFC7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML R. Gieben August 2014 ASCII 17590 10

This document presents a technique for using a Markdown syntax variant, called Pandoc, and a bit of XML (as defined in RFC 2629) as a source format for documents that are Internet-Drafts (I-Ds) or RFCs.

The goal of this technique (which is called Pandoc2rfc) is to let an author of an I-D focus on the main body of text without being distracted too much by XML tags; however, it does not alleviate the need to typeset some files in XML.

draft-gieben-pandoc2rfc-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7328
RFC7329 A Session Identifier for the Session Initiation Protocol (SIP) H. Kaplan August 2014 ASCII 39057 17

There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.

The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.

draft-kaplan-insipid-session-id-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7329
RFC7330 Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management T. Nadeau Z. Ali N. Akiya August 2014 ASCII 20910 11 Network Management management Information Base MIB SMIv2 BFD

This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD-related MIB modules that would otherwise define their own representations.

draft-ietf-bfd-tc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7330
RFC7331 Bidirectional Forwarding Detection (BFD) Management Information Base T. Nadeau Z. Ali N. Akiya August 2014 ASCII 72272 39 Network Management Management Information Base MIB SMIv2 BFD

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Bidirectional Forwarding Detection (BFD) protocol.

draft-ietf-bfd-mib-22 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=7331 10.17487/RFC7331
RFC7332 Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) H. Kaplan V. Pascual August 2014 ASCII 11157 5

SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs and the requirements for them to prevent infinite loops.

draft-ietf-straw-b2bua-loop-detection-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai straw http://www.rfc-editor.org/errata_search.php?rfc=7332 10.17487/RFC7332
RFC7333 Requirements for Distributed Mobility Management H. Chan Editor D. Liu P. Seite H. Yokota J. Korhonen August 2014 ASCII 50110 24 Distributed Mobility Management Network function distribution Flat mobile network Mobile network operation and management Control and data plane separation

This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described.

draft-ietf-dmm-requirements-17 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC7333
RFC7334 PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths Q. Zhao D. Dhody D. King Z. Ali R. Casellas August 2014 ASCII 48897 25 Core-tree

The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs.

This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.

draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08 EXPERIMENTAL EXPERIMENTAL IETF rtg pce 10.17487/RFC7334
RFC7335 IPv4 Service Continuity Prefix C. Byrne August 2014 ASCII 7763 4

Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element. Per this memo, IANA has generalized that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution.

draft-ietf-v6ops-clatip-04 RFC6333 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC7335
RFC7336 Framework for Content Distribution Network Interconnection (CDNI) L. Peterson B. Davie R. van Brandenburg Editor August 2014 ASCII 145294 58 CDNI content delivery network federation cdni request routing cdni logging cdmi metadata cdni control

This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466.

draft-ietf-cdni-framework-14 RFC3466 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC7336
RFC7337 Content Distribution Network Interconnection (CDNI) Requirements K. Leung Editor Y. Lee Editor August 2014 ASCII 55208 23

Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users.

The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group.

draft-ietf-cdni-requirements-17 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC7337
RFC7338 Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks F. Jounay Editor Y. Kamite Editor G. Heron M. Bocci September 2014 ASCII 36120 18

This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling, and maintenance aspects of point-to-multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, point-to-multipoint PWs can be used to optimize the support of multicast Layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service).

draft-ietf-pwe3-p2mp-pw-requirements-10 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC7338
RFC7339 Session Initiation Protocol (SIP) Overload Control V. Gurbani Editor V. Hilt H. Schulzrinne September 2014 ASCII 89898 38 SIP Overload Control

Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all the SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behavior of SIP servers involved in overload control and also specifies a loss-based overload scheme for SIP.

draft-ietf-soc-overload-control-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7339
RFC7340 Secure Telephone Identity Problem Statement and Requirements J. Peterson H. Schulzrinne H. Tschofenig September 2014 ASCII 65026 25 SIP XMPP Secure Origin Identification Communication Security RTCWeb Problem Statement Real-Time Communication

Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.

draft-ietf-stir-problem-statement-05 INFORMATIONAL INFORMATIONAL IETF rai stir 10.17487/RFC7340
RFC7341 DHCPv4-over-DHCPv6 (DHCP 4o6) Transport Q. Sun Y. Cui M. Siodelski S. Krishnan I. Farrer August 2014 ASCII 35599 16 ipv6 transition softwire migration tunnel residual ipv4 dhcpv6 relay ipv6-only

IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.

draft-ietf-dhc-dhcpv4-over-dhcpv6-09 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7341
RFC7342 Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers L. Dunbar W. Kumari I. Gashinsky August 2014 ASCII 28413 14

This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.

draft-dunbar-armd-arp-nd-scaling-practices-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7342
RFC7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) J. Laganier F. Dupont September 2014 ASCII 28699 14 HIP HIPv2 ORCHID CGA API

This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.

The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.

draft-ietf-hip-rfc4843-bis-08 RFC4843 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC7343
RFC7344 Automating DNSSEC Delegation Trust Maintenance W. Kumari O. Gudmundsson G. Barwood September 2014 ASCII 39434 18 key roll trust anchor CDS CDNSKEY DNSSEC DNS

This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.

draft-ietf-dnsop-delegation-trust-maintainance-14 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7344
RFC7345 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) C. Holmberg I. Sedlacek G. Salgueiro August 2014 ASCII 42943 23 SDP SIP DTLS UDPTL fax transport

This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).

draft-ietf-mmusic-udptl-dtls-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7345
RFC7346 IPv6 Multicast Address Scopes R. Droms August 2014 ASCII 10831 6 IPv6 multicast address scopes

This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291.

draft-ietf-6man-multicast-scopes-07 RFC4007 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7346
RFC7347 Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP) H. van Helvoort Editor J. Ryoo Editor H. Zhang F. Huang H. Li A. D'Alessandro September 2014 ASCII 70158 32 PDF 394963

The IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324.

This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic.

The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by the MPLS-TP data plane and can work without any control plane.

draft-zulr-mpls-tp-linear-protection-switching-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7347
RFC7348 Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks M. Mahalingam D. Dutt K. Duda P. Agarwal L. Kreeger T. Sridhar M. Bursell C. Wright August 2014 ASCII 49406 22

This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.

draft-mahalingam-dutt-dcops-vxlan-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7348
RFC7349 LDP Hello Cryptographic Authentication L. Zheng M. Chen M. Bhatia August 2014 ASCII 32447 14

This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well-known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms.

draft-ietf-mpls-ldp-hello-crypto-auth-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7349
RFC7350 Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) M. Petit-Huguenin G. Salgueiro August 2014 ASCII 27599 16 Security Encryption

This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidance on when and how to use DTLS with the currently standardized STUN usages. It also specifies modifications to the STUN and Traversal Using Relay NAT (TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. This document updates RFCs 5389 and 5928.

draft-ietf-tram-stun-dtls-05 RFC5389 RFC5928 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC7350
RFC7351 A Media Type for XML Patch Operations E. Wilde August 2014 ASCII 27784 14 Media Type XML Patch Operations

The XML patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XML patch document format builds on the foundations defined in RFC 5261. This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML patch documents in, for example, HTTP conversations.

draft-wilde-xml-patch-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7351
RFC7352 Sieve Email Filtering: Detecting Duplicate Deliveries S. Bosch September 2014 ASCII 31191 15 sieve duplicate deliveries

This document defines a new test command, "duplicate", for the Sieve email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header field or other parts of the message.

draft-ietf-appsawg-sieve-duplicate-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7352
RFC7353 Security Requirements for BGP Path Validation S. Bellovin R. Bush D. Ward August 2014 ASCII 18148 9 Routing BGP Security AS_PATH and RPKI

This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin Autonomous System (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement.

draft-ietf-sidr-bgpsec-reqs-12 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC7353
RFC7354 Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace A. Adolf P. Siebert September 2014 ASCII 5052 3

RFC 5328 registered the Uniform Resource Name (URN) namespace "dvb" for the Digital Video Broadcasting Project. This document updates RFC 5328 with new registrant information.

draft-adolf-dvb-urn-upd-01 RFC5328 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7354
RFC7355 Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF) G. Salgueiro V. Pascual A. Roman S. Garcia September 2014 ASCII 16180 9

RFC 7118 specifies a WebSocket subprotocol as a reliable real-time transport mechanism between Session Initiation Protocol (SIP) entities to enable usage of SIP in web-oriented deployments. This document updates the SIP Common Log Format (CLF), defined in RFC 6873, with a new "Transport Flag" for such SIP WebSocket transport.

draft-salgueiro-dispatch-websocket-sipclf-02 RFC6873 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7355
RFC7356 IS-IS Flooding Scope Link State PDUs (LSPs) L. Ginsberg S. Previdi Y. Yang September 2014 ASCII 46089 23

Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.

The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.

draft-ietf-isis-fs-lsp-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7356
RFC7357 Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol H. Zhai F. Hu R. Perlman D. Eastlake 3rd O. Stokes September 2014 ASCII 72379 31 ESADI TRILL RBridge Address Learning Reachability MAC Addresses

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges).

ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label (VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible.

draft-ietf-trill-esadi-09 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7357
RFC7358 Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) K. Raza S. Boutros L. Martini N. Leymann October 2014 ASCII 15582 8

The label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types.

draft-ietf-mpls-ldp-applicability-label-adv-03 RFC3212 RFC4447 RFC5036 RFC5918 RFC6388 RFC7140 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7358
RFC7359 Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks F. Gont August 2014 ASCII 26506 12

The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue.

draft-ietf-opsec-vpn-leakages-06 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC7359
RFC7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS A. DeKok September 2014 ASCII 60007 27

The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems.

draft-ietf-radext-dtls-13 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7360
RFC7361 LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS) P. Dutta F. Balus O. Stokes G. Calvignac D. Fedyk September 2014 ASCII 62854 27 MAC flush message MAC Flush TLV MAC flushing

RFC 4762 describes a mechanism to remove or unlearn Media Access Control (MAC) addresses that have been dynamically learned in a Virtual Private LAN Service (VPLS) instance for faster convergence on topology changes. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology changes. This document defines an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762); this enhancement enables a Provider Edge (PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC 4762 MAC withdraw procedures are specified to provide an optimized MAC flushing for the Provider Backbone Bridging (PBB) VPLS specified in RFC 7041.

draft-ietf-l2vpn-vpls-ldp-mac-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7361 10.17487/RFC7361
RFC7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication E. Ivov H. Kaplan D. Wing September 2014 ASCII 39139 16 VoIP firewall traversal

This document describes the behavior of signaling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other.

This document is non-normative and is only written to explain HNT in order to provide a reference to the Internet community and an informative description to manufacturers and users.

Latching, which is one of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of the latching mechanism over the Internet and recommends other solutions, such as the Interactive Connectivity Establishment (ICE) protocol.

draft-ietf-mmusic-latching-08 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC7362
RFC7363 Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) J. Maenpaa G. Camarillo September 2014 ASCII 54308 22 P2PSIP P2P Chord

REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size.

draft-ietf-p2psip-self-tuning-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7363
RFC7364 Problem Statement: Overlays for Network Virtualization T. Narten Editor E. Gray Editor D. Black L. Fang L. Kreeger M. Napierala October 2014 ASCII 57831 23

This document describes issues associated with providing multi-tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant. Another requirement is address space isolation so that different tenants can use the same address space within different virtual networks. Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway). Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network and maintaining that association as the virtual machine is activated, migrated, and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures.

draft-ietf-nvo3-overlay-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC7364
RFC7365 Framework for Data Center (DC) Network Virtualization M. Lasserre F. Balus T. Morin N. Bitar Y. Rekhter October 2014 ASCII 57811 26 nvo3 network virtualization over layer 3

This document provides a framework for Data Center (DC) Network Virtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution.

draft-ietf-nvo3-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC7365
RFC7366 Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) P. Gutmann September 2014 ASCII 15775 7

This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.

draft-ietf-tls-encrypt-then-mac-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7366 10.17487/RFC7366
RFC7367 Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process R. Cole J. Macker B. Adamson October 2014 ASCII 135588 65 Network Management Management Information Base MIB SMIv2 Routing MANET Multicast

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad Hoc Networks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems.

draft-ietf-manet-smf-mib-13 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7367
RFC7368 IPv6 Home Networking Architecture Principles T. Chown Editor J. Arkko A. Brandt O. Troan J. Weil October 2014 ASCII 125402 49 IPv6

This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network.

draft-ietf-homenet-arch-17 INFORMATIONAL INFORMATIONAL IETF int homenet 10.17487/RFC7368
RFC7369 GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration A. Takacs B. Gero H. Long October 2014 ASCII 38843 18 GELS Ethernet Label Switching PBB-TE connectivity monitoring OAM configuration

The work related to GMPLS Ethernet Label Switching (GELS) extended GMPLS RSVP-TE to support the establishment of Ethernet Label Switching Paths (LSPs). IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct Operations, Administration, and Maintenance (OAM) flow to check connectivity in Ethernet networks. CFM can also be used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAM Configuration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms.

draft-ietf-ccamp-rsvp-te-eth-oam-ext-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7369
RFC7370 Updates to the IS-IS TLV Codepoints Registry L. Ginsberg September 2014 ASCII 12318 7 Codepoint

This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.

draft-ietf-isis-tlv-codepoints-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7370
RFC7371 Updates to the IPv6 Multicast Addressing Architecture M. Boucadair S. Venaas September 2014 ASCII 18327 10 IPv6 Multicast Flag Bits updated unicast-prefix-based address updated Embedded-RP

This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits.

This document updates RFCs 3956, 3306, and 4291.

draft-ietf-6man-multicast-addr-arch-update-08 RFC3306 RFC3956 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7371
RFC7372 Email Authentication Status Codes M. Kucherawy September 2014 ASCII 14224 8

This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures.

This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document.

draft-ietf-appsawg-email-auth-codes-07 RFC7208 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7372
RFC7373 Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types B. Trammell September 2014 ASCII 29054 14 information element unicode

This document defines UTF-8 representations for IP Flow Information Export (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings.

draft-ietf-ipfix-text-adt-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7373
RFC7374 Service Discovery Usage for REsource LOcation And Discovery (RELOAD) J. Maenpaa G. Camarillo October 2014 ASCII 45569 20 P2PSIP ReDiR P2P DHT

REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC 6940). This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism can be applied to RELOAD overlays to provide a generic service discovery mechanism.

draft-ietf-p2psip-service-discovery-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7374
RFC7375 Secure Telephone Identity Threat Model J. Peterson October 2014 ASCII 31067 13 SIP Secure Origin Identification Communication Security RTCWeb Threat Real-Time Communication

As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched.

draft-ietf-stir-threats-04 INFORMATIONAL INFORMATIONAL IETF rai stir 10.17487/RFC7375
RFC7376 Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) T. Reddy R. Ravindranath M. Perumal A. Yegin September 2014 ASCII 16447 8

This document discusses some of the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages.

draft-ietf-tram-auth-problems-05 INFORMATIONAL INFORMATIONAL IETF tsv tram 10.17487/RFC7376
RFC7377 IMAP4 Multimailbox SEARCH Extension B. Leiba A. Melnikov October 2014 ASCII 24711 11 IMAP email search multiple mailboxes imapext

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237.

draft-ietf-appsawg-multimailbox-search-04 RFC6237 RFC4466 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7377
RFC7378 Trustworthy Location H. Tschofenig H. Schulzrinne B. Aboba Editor December 2014 ASCII 75402 31

The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.

This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information.

draft-ietf-ecrit-trustworthy-location-14 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC7378
RFC7379 Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge Y. Li W. Hao R. Perlman J. Hudson H. Zhai October 2014 ASCII 26764 13

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus. This informational document discusses the high-level problems and goals when providing active-active connection at the TRILL edge.

draft-ietf-trill-active-active-connection-prob-07 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7379
RFC7380 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting J. Tong C. Bi Editor R. Even Q. Wu Editor R. Huang November 2014 ASCII 22440 11 TR 101 290

An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/multicast MPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR block are related to Program Specific Information (PSI) carried in MPEG TS.

draft-ietf-xrblock-rtcp-xr-psi-decodability-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7380
RFC7381 Enterprise IPv6 Deployment Guidelines K. Chittimaneni T. Chown L. Howard V. Kuarsingh Y. Pouffary E. Vyncke October 2014 ASCII 90299 34 IPV6 migration transition enterprise

Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.

draft-ietf-v6ops-enterprise-incremental-ipv6-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7381
RFC7382 Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) S. Kent D. Kong K. Seo April 2015 ASCII 82372 38

This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP.

draft-ietf-sidr-cps-04 BCP0173 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC7382
RFC7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation V. Smyslov November 2014 ASCII 47354 20 IP fragmentation NAT firewall PMTU discovery

This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.

draft-ietf-ipsecme-ikev2-fragmentation-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7383
RFC7384 Security Requirements of Time Protocols in Packet Switched Networks T. Mizrahi October 2014 ASCII 78942 36 ptp precision time protocol ntp network time protocol

As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.

draft-ietf-tictoc-security-requirements-12 INFORMATIONAL INFORMATIONAL IETF int tictoc 10.17487/RFC7384
RFC7385 IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points L. Andersson G. Swallow October 2014 ASCII 6690 4

RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". However, the RFC did not create a corresponding IANA registry.

There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose.

draft-ietf-l3vpn-pmsi-registry-07 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7385
RFC7386 JSON Merge Patch P. Hoffman J. Snell October 2014 ASCII 12930 9 http json patch merge

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.

draft-ietf-appsawg-json-merge-patch-07 RFC7396 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7386 10.17487/RFC7386
RFC7387 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network R. Key Editor L. Yong Editor S. Delord F. Jounay L. Jin October 2014 ASCII 28205 13 mef etherhet lan e-lan metro ethernet forum

This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network.

draft-ietf-l2vpn-etree-frwk-10 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7387
RFC7388 Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) J. Schoenwaelder A. Sehgal T. Tsou C. Zhou October 2014 ASCII 53451 27 Network Management Management Information Base MIB SMIv2

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs).

draft-ietf-6lo-lowpan-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7388
RFC7389 Separation of Control and User Plane for Proxy Mobile IPv6 R. Wakikawa R. Pazhyannur S. Gundavelli C. Perkins October 2014 ASCII 26217 12 Control and User Plane Split Control and User Plane Separation LMA User-Plane Address Mobility Option

This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy Mobile IPv6 (PMIPv6). Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA. With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane.

draft-ietf-netext-pmip-cp-up-separation-07 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7389
RFC7390 Group Communication for the Constrained Application Protocol (CoAP) A. Rahman Editor E. Dijk Editor October 2014 ASCII 106675 46 multicast IP multicast RESTful Internet of Things (IoT)

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.

draft-ietf-core-groupcomm-25 EXPERIMENTAL EXPERIMENTAL IETF app core 10.17487/RFC7390
RFC7391 Forwarding and Control Element Separation (ForCES) Protocol Extensions J. Hadi Salim October 2014 ASCII 49481 23 ForCES Protocol Extension

Experience in implementing and deploying the Forwarding and Control Element Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. The ForCES protocol is extended with a table range operation and a new extension for error handling. This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal.

draft-ietf-forces-protoextension-06 RFC5810 RFC7121 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC7391
RFC7392 Explicit Path Routing for Dynamic Multi-Segment Pseudowires P. Dutta M. Bocci L. Martini December 2014 ASCII 20846 10 Pseudowire MS-PW explicit route

When set up through an explicit path, dynamic Multi-Segment Pseudowires (MS-PWs) may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths.

draft-ietf-pwe3-mspw-er-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7392
RFC7393 Using the Port Control Protocol (PCP) to Update Dynamic DNS X. Deng M. Boucadair Q. Zhao J. Huang C. Zhou November 2014 ASCII 30130 14 address sharing CGN service continuity service availability user-generated content address-sharing issues DS-Lite service delivery in CGN contexts

This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo.

draft-deng-pcp-ddns-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7393
RFC7394 Definition of Time to Live TLV for LSP-Ping Mechanisms S. Boutros S. Sivabalan G. Swallow S. Saxena V. Manral S. Aldrin November 2014 ASCII 15120 8

LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment Pseudowire (MS-PW) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of the MS-PW and/or bidirectional co-routed LSP. This document defines a TLV to address this shortcoming.

draft-ietf-mpls-lsp-ping-ttl-tlv-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7394 10.17487/RFC7394
RFC7395 An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket L. Stout Editor J. Moffitt E. Cestari October 2014 ASCII 36795 18 WebSocket XMPP

This document defines a binding for the Extensible Messaging and Presence Protocol (XMPP) over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP.

draft-ietf-xmpp-websocket-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp 10.17487/RFC7395
RFC7396 JSON Merge Patch P. Hoffman J. Snell October 2014 ASCII 12791 9 http json patch merge

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.

draft-ietf-rfc7386bis-00 RFC7386 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7396
RFC7397 Report from the Smart Object Security Workshop J. Gilger H. Tschofenig December 2014 ASCII 51259 23 Smart Objects Internet of Things Workshop Security

This document provides a summary of a workshop on 'Smart Object Security' that took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects.

This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

draft-gilger-smart-object-security-workshop-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7397
RFC7398 A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance M. Bagnulo T. Burbridge S. Crawford P. Eardley A. Morton February 2015 ASCII 36938 17 LMAP performance metrics

This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location. The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement.

draft-ietf-ippm-lmap-path-07 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7398
RFC7399 Unanswered Questions in the Path Computation Element Architecture A. Farrel D. King October 2014 ASCII 70588 29 SDN Software Defined Networking H-PCE Hierarchical PCE VNTM Virtual Network Topology Manager ABNO Application-Based Network Operation TE Traffic Engineering

The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.

These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.

This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.

draft-ietf-pce-questions-08 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7399
RFC7400 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) C. Bormann November 2014 ASCII 47533 24 IoT Internet of Things Embedded Internet Sensor Network WSN Constrained node Constrained network Constrained-node network LLN LoWPAN packet encoding capability indication 6CIO LZ77 RFC 6282 RFC 4944 adaptation layer IEEE 802.15.4

RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload.

draft-ietf-6lo-ghc-05 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7400
RFC7401 Host Identity Protocol Version 2 (HIPv2) R. Moskowitz Editor T. Heer P. Jokela T. Henderson April 2015 ASCII 309319 128 HIP IP-layer state integrity protection optional encryption

This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.

This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.

draft-ietf-hip-rfc5201-bis-20 RFC5201 PROPOSED STANDARD PROPOSED STANDARD IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=7401 10.17487/RFC7401
RFC7402 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) P. Jokela R. Moskowitz J. Melen April 2015 ASCII 88644 40 encryption user data packets

This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202.

draft-ietf-hip-rfc5202-bis-07 RFC5202 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC7402
RFC7403 A Media-Based Traceroute Function for the Session Initiation Protocol (SIP) H. Kaplan November 2014 ASCII 15108 7

SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field to determine the reachability path of requests to a target. A mechanism for media-loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator. This document describes a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media-relaying back-to-back user agents (B2BUAs).

draft-ietf-straw-sip-traceroute-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai straw 10.17487/RFC7403
RFC7404 Using Only Link-Local Addressing inside an IPv6 Network M. Behringer E. Vyncke November 2014 ASCII 24444 10 IPv6 security routing Link-Local Routing Protocol Security

In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.

draft-ietf-opsec-lla-only-11 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=7404 10.17487/RFC7404
RFC7405 Case-Sensitive String Support in ABNF P. Kyzivat December 2014 ASCII 6668 4 BNF ABNF Syntax

This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.

draft-kyzivat-case-sensitive-abnf-02 RFC5234 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7405
RFC7406 Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices H. Schulzrinne S. McCann G. Bajko H. Tschofenig D. Kroeselberg December 2014 ASCII 52779 25

This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.

draft-ietf-ecrit-unauthenticated-access-10 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC7406
RFC7407 A YANG Data Model for SNMP Configuration M. Bjorklund J. Schoenwaelder December 2014 ASCII 155373 88

This document defines a collection of YANG definitions for configuring SNMP engines.

draft-ietf-netmod-snmp-cfg-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7407 10.17487/RFC7407
RFC7408 Forwarding and Control Element Separation (ForCES) Model Extension E. Haleplidis November 2014 ASCII 62348 31 ForCES Model Extension

This memo extends the Forwarding and Control Element Separation (ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures. It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties. The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models.

draft-ietf-forces-model-extension-05 RFC5812 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC7408
RFC7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization E. Haleplidis J. Halpern November 2014 ASCII 53906 27 ForCES Model Extension

Many network devices support parallel packet processing. This document describes how Forwarding and Control Element Separation (ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810).

draft-ietf-forces-packet-parallelization-03 EXPERIMENTAL EXPERIMENTAL IETF rtg forces 10.17487/RFC7409
RFC7410 A Property Types Registry for the Authentication-Results Header Field M. Kucherawy December 2014 ASCII 9957 5 Authentication-Results Reputation

This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values.

draft-ietf-appsawg-authres-ptypes-registry-04 RFC7001 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7410
RFC7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers T. Schmidt Editor M. Waehlisch R. Koodli G. Fairhurst D. Liu November 2014 ASCII 72298 30 Multicast Mobility IPv6 PIM MLD Group Communication

Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format.

This document updates RFC 5568, "Mobile IPv6 Fast Handovers".

draft-ietf-multimob-fmipv6-pfmipv6-multicast-10 RFC5568 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7411
RFC7412 Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection Y. Weingarten S. Aldrin P. Pan J. Ryoo G. Mirsky December 2014 ASCII 34117 16

This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLS Transport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP) Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.

draft-ietf-mpls-smp-requirements-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7412
RFC7413 TCP Fast Open Y. Cheng J. Chu S. Radhakrishnan A. Jain December 2014 ASCII 59945 26

This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.

draft-ietf-tcpm-fastopen-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=7413 10.17487/RFC7413
RFC7414 A Roadmap for Transmission Control Protocol (TCP) Specification Documents M. Duke R. Braden W. Eddy E. Blanton A. Zimmermann February 2015 ASCII 130622 57 TCP Roadmap

This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.

This document obsoletes RFC 4614.

draft-ietf-tcpm-tcp-rfc4614bis-08 RFC4614 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7414
RFC7415 Session Initiation Protocol (SIP) Rate Control E. Noel P. Williams February 2015 ASCII 30456 15

The prevalent use of the Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed. Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme.

draft-ietf-soc-overload-rate-control-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7415
RFC7416 A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) T. Tsao R. Alexander M. Dohler V. Daza A. Lozano M. Richardson Editor January 2015 ASCII 94452 40 LLN ROLL security

This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements.

draft-ietf-roll-security-threats-11 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7416
RFC7417 Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains G. Karagiannis A. Bhargava December 2014 ASCII 79227 36 generic aggregate rsvp

This document specifies extensions to Generic Aggregate RSVP (RFC 4860) for support of the Pre-Congestion Notification (PCN) Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN.

draft-ietf-tsvwg-rsvp-pcn-11 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC7417
RFC7418 An IRTF Primer for IETF Participants S. Dawkins Editor December 2014 ASCII 14467 7 Research Group

This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF). This document emphasizes differences in expectations between the two organizations.

draft-dawkins-irtf-newrg-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7418
RFC7419 Common Interval Support in Bidirectional Forwarding Detection N. Akiya M. Binderberger G. Mirsky December 2014 ASCII 16944 8 BFD hardware interval timer

Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions.

This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals.

draft-ietf-bfd-intervals-05 RFC5880 INFORMATIONAL INFORMATIONAL IETF rtg bfd 10.17487/RFC7419
RFC7420 Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module A. Koushik E. Stephan Q. Zhao D. King J. Hardwick December 2014 ASCII 130964 65 Network Management Management Information Base MIB SMIv2 PCE PCEP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.

draft-ietf-pce-pcep-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7420
RFC7421 Analysis of the 64-bit Boundary in IPv6 Addressing B. Carpenter Editor T. Chown F. Gont S. Jiang A. Petrescu A. Yourtchenko January 2015 ASCII 60469 24

The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary.

draft-ietf-6man-why64-08 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC7421
RFC7422 Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments C. Donley C. Grundemann V. Sarawat K. Sundaresan O. Vautrin December 2014 ASCII 33575 14

In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response). Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges. Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use.

draft-donley-behave-deterministic-cgn-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7422 10.17487/RFC7422
RFC7423 Diameter Applications Design Guidelines L. Morand Editor V. Fajardo H. Tschofenig November 2014 ASCII 67829 29 AAA Authentication Authorization Accounting

The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions.

draft-ietf-dime-app-design-guide-28 BCP0193 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dime 10.17487/RFC7423
RFC7424 Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks R. Krishnan L. Yong A. Ghanwani N. So B. Khasnabish January 2015 ASCII 60733 29

Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this.

draft-ietf-opsawg-large-flow-load-balancing-15 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7424
RFC7425 Adobe's RTMFP Profile for Flash Communication M. Thornburgh December 2014 ASCII 103979 49

This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication.

draft-thornburgh-rtmfp-flash-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7425
RFC7426 Software-Defined Networking (SDN): Layers and Architecture Terminology E. Haleplidis Editor K. Pentikousis Editor S. Denazis J. Hadi Salim D. Meyer O. Koufopavlou January 2015 ASCII 85111 35 Software-defined Networking SDN Programmable Networks Architecture Layer Terminology

Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.

draft-irtf-sdnrg-layer-terminology-04 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7426
RFC7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) T. Kivinen J. Snyder January 2015 ASCII 39041 18 IPsec IKE IKEv2 Signature Authentication RSA DSS DSA ECDSA SASSA-PSS PKIX

The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.

draft-kivinen-ipsecme-signature-auth-07 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7427 10.17487/RFC7427
RFC7428 Transmission of IPv6 Packets over ITU-T G.9959 Networks A. Brandt J. Buron February 2015 ASCII 42657 21

This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.

draft-ietf-6lo-lowpanz-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7428
RFC7429 Distributed Mobility Management: Current Practices and Gap Analysis D. Liu Editor JC. Zuniga Editor P. Seite H. Chan CJ. Bernardos January 2015 ASCII 80973 34 DMM Distributed Mobility Management anchor gap analysis best practices

This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution.

draft-ietf-dmm-best-practices-gap-analysis-09 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC7429
RFC7432 BGP MPLS-Based Ethernet VPN A. Sajassi Editor R. Aggarwal N. Bitar A. Isaac J. Uttaro J. Drake W. Henderickx February 2015 ASCII 134119 56

This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".

draft-ietf-l2vpn-evpn-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC7432
RFC7433 A Mechanism for Transporting User-to-User Call Control Information in SIP A. Johnston J. Rafferty January 2015 ASCII 45687 19 UUI Package Content Encoding Media

There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism.

draft-ietf-cuss-sip-uui-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai cuss 10.17487/RFC7433
RFC7434 Interworking ISDN Call Control User Information with SIP K. Drage Editor A. Johnston January 2015 ASCII 39276 17 UUS Supplementary Service

The motivation and use cases for interworking and transporting User- to-User Information (UUI) from the ITU-T Digital Subscriber Signalling System No. 1 (DSS1) User-user information element within SIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of the User-to-User header field to enable interworking with this ISDN service.

This document covers interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed.

The package is identified by the new value "isdn-uui" of the "purpose" header field parameter.

draft-ietf-cuss-sip-uui-isdn-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai cuss http://www.rfc-editor.org/errata_search.php?rfc=7434 10.17487/RFC7434
RFC7435 Opportunistic Security: Some Protection Most of the Time V. Dukhovni December 2014 ASCII 27451 11 authentication encryption

This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.

draft-dukhovni-opportunistic-security-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7435
RFC7436 IP-Only LAN Service (IPLS) H. Shah E. Rosen F. Le Faucheur G. Heron January 2015 ASCII 74340 32

A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination Media Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in the IEEE's "Media Access Control (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.

The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learning MAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.

draft-ietf-l2vpn-ipls-16 HISTORIC HISTORIC IETF rtg l2vpn 10.17487/RFC7436
RFC7437 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees M. Kucherawy Editor January 2015 ASCII 77786 35 Internet Architecture Board Engineering Steering Group nomcom IAOC

The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published.

draft-kucherawy-rfc3777bis-04 RFC3777 RFC5078 RFC5633 RFC5680 RFC6859 BCP0010 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7437
RFC7438 Multipoint LDP (mLDP) In-Band Signaling with Wildcards IJ. Wijnands Editor E. Rosen A. Gulko U. Joorde J. Tantsura January 2015 ASCII 36744 16 mpls multicast

There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label Switched Path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or Bidirectional Multicast trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP Any-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246.

draft-ietf-mpls-mldp-in-band-wildcard-encoding-03 RFC6826 RFC7246 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7438
RFC7439 Gap Analysis for Operating IPv6-Only MPLS Networks W. George Editor C. Pignataro Editor January 2015 ASCII 64087 28 MPLS LDP IPv6 RSVP L3VPN L2VPN

This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality.

In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols.

draft-ietf-mpls-ipv6-only-gap-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7439
RFC7440 TFTP Windowsize Option P. Masotta January 2015 ASCII 17710 9

The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.

This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension" (RFC 2347).

draft-masotta-tftpexts-windowsize-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7440
RFC7441 Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes IJ. Wijnands E. Rosen U. Joorde January 2015 ASCII 22839 10

Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514.

draft-ietf-l3vpn-mvpn-mldp-nlri-10 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7441
RFC7442 Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) Y. Rekhter R. Aggarwal N. Leymann W. Henderickx Q. Zhao R. Li February 2015 ASCII 24020 11

When IP multicast trees created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths (P2MP LSPs). This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions for P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).

draft-ietf-mpls-pim-sm-over-mldp-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7442
RFC7443 Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages P. Patil T. Reddy G. Salgueiro M. Petit-Huguenin January 2015 ASCII 9145 5

Application-Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) usages, such as Traversal Using Relays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and Datagram Transport Layer Security (DTLS).

draft-ietf-tram-alpn-08 INFORMATIONAL INFORMATIONAL IETF tsv tram 10.17487/RFC7443
RFC7444 Security Labels in Internet Email K. Zeilenga A. Melnikov February 2015 ASCII 32183 16 email header fields ESS Security Label Confidential Label Message Sensitivity

This document describes a header field, SIO-Label, for use in Internet email to convey the sensitivity of the message. This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label.

draft-zeilenga-email-seclabel-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7444
RFC7445 Analysis of Failure Cases in IPv6 Roaming Scenarios G. Chen H. Deng D. Michaud J. Korhonen M. Boucadair March 2015 ASCII 44466 19 Mobile Network Dual Stack IPv6-only

This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks.

draft-ietf-v6ops-ipv6-roaming-analysis-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7445
RFC7446 Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Y. Lee Editor G. Bernstein Editor D. Li W. Imajuku February 2015 ASCII 48370 23 WSON RWA

This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength Switched Optical Networks (WSONs). The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed.

draft-ietf-ccamp-rwa-info-24 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7446
RFC7447 Deprecation of BGP Entropy Label Capability Attribute J. Scudder K. Kompella February 2015 ASCII 7486 4

The BGP Entropy Label Capability attribute is defined in RFC 6790. Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice. This specification deprecates the attribute. A forthcoming document will propose a replacement.

draft-ietf-mpls-deprecate-bgp-entropy-label-02 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7447
RFC7448 MIB Transfer from the IETF to the IEEE 802.3 WG T. Taylor Editor D. Romascanu February 2015 ASCII 12501 7 Ethernet IEEE

This document records the transfer of responsibility for the Ethernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group (WG). This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG.

draft-ietf-opsawg-mibs-to-ieee80231-01 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7448
RFC7449 Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment Y. Lee Editor G. Bernstein Editor J. Martensson T. Takeda T. Tsuritani O. Gonzalez de Dios February 2015 ASCII 25117 12

This memo provides application-specific requirements for the Path Computation Element Communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSONs). Lightpath provisioning in WSONs requires a Routing and Wavelength Assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document.

draft-ietf-pce-wson-routing-wavelength-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7449
RFC7450 Automatic Multicast Tunneling G. Bumgardner February 2015 ASCII 188711 82 AMT IGMPv2 IGMPv3 MLDv1 MLDv2 ASM SSM amt gateway amt relay multicast replication multicast encapsulation

This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.

The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.

draft-ietf-mboned-auto-multicast-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC7450
RFC7451 Extension Registry for the Extensible Provisioning Protocol S. Hollenbeck February 2015 ASCII 20373 12 domain host contact

The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.

draft-ietf-eppext-reg-10 INFORMATIONAL INFORMATIONAL IETF app eppext 10.17487/RFC7451
RFC7452 Architectural Considerations in Smart Object Networking H. Tschofenig J. Arkko D. Thaler D. McPherson March 2015 ASCII 53504 24 IAB Statement Smart Objects

The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.

This document offers guidance to engineers designing Internet- connected smart objects.

draft-iab-smart-object-architecture-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7452
RFC7453 MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) V. Mahalingam K. Sampath S. Aldrin T. Nadeau February 2015 ASCII 117910 62

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks.

draft-ietf-mpls-tp-te-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7453
RFC7454 BGP Operations and Security J. Durand I. Pepelnjak G. Doering February 2015 ASCII 56946 26

The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.

This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.

draft-ietf-opsec-bgp-security-07 BCP0194 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC7454
RFC7455 Transparent Interconnection of Lots of Links (TRILL): Fault Management T. Senevirathne N. Finn S. Salam D. Kumar D. Eastlake 3rd S. Aldrin Y. Li March 2015 ASCII 126153 63 Fault Continuity Connectivity OAM CFM MEP CCM

This document specifies Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) fault management. Methods in this document follow the CFM (Connectivity Fault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL-specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1. This document updates RFC 6325.

draft-ietf-trill-oam-fm-11 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7455
RFC7456 Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) T. Mizrahi T. Senevirathne S. Salam D. Kumar D. Eastlake 3rd March 2015 ASCII 66752 32

Performance Monitoring (PM) is a key aspect of Operations, Administration, and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies. This document specifies mechanisms for Loss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks.

draft-ietf-trill-loss-delay-08 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7456
RFC7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) Y. Sheffer R. Holz P. Saint-Andre February 2015 ASCII 28614 13 Transport Layer Security TLS Datagram TLS DTLS Secure Sockets Layer SSL security attacks

Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS).

draft-ietf-uta-tls-attacks-05 INFORMATIONAL INFORMATIONAL IETF app uta http://www.rfc-editor.org/errata_search.php?rfc=7457 10.17487/RFC7457
RFC7458 Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core R. Valmikam R. Koodli February 2015 ASCII 38925 18 Mobile Networks 3GPP EAP EPC Handover Identity APN

With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks.

The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as a Mobile Node (MN)) and its network counterpart (such as an Authentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure.

draft-ietf-netext-wifi-epc-eap-attributes-16 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7458
RFC7459 Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO) M. Thomson J. Winterbottom February 2015 ASCII 80144 39

This document defines key concepts of uncertainty and confidence as they pertain to location information. Methods for the manipulation of location estimates that include uncertainty information are outlined.

This document normatively updates the definition of location information representations defined in RFCs 4119 and 5491. It also deprecates related terminology defined in RFC 3693.

draft-ietf-geopriv-uncertainty-04 RFC3693 RFC4119 RFC5491 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7459
RFC7460 Monitoring and Control MIB for Power and Energy M. Chandramouli B. Claise B. Schoening J. Quittek T. Dietz March 2015 ASCII 148167 69 management information base IANAPowerStateSet-MIB ENERGY-OBJECT-MIB POWER-ATTRIBUTES-MIB

This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices.

draft-ietf-eman-energy-monitoring-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7460
RFC7461 Energy Object Context MIB J. Parello B. Claise M. Chandramouli March 2015 ASCII 67077 32 management information base ENERGY-OBJECT-CONTEXT-MIB IANA-ENERGY-RELATION-MIB

This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the energy relationships between devices.

draft-ietf-eman-energy-aware-mib-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7461
RFC7462 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) L. Liess Editor R. Jesske A. Johnston D. Worley P. Kyzivat March 2015 ASCII 97730 46

The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the User Agent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.

This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.

draft-ietf-salud-alert-info-urns-14 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai salud 10.17487/RFC7462
RFC7463 Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) A. Johnston Editor M. Soroushnejad Editor V. Venkataramanan March 2015 ASCII 171979 72

This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP Private Branch Exchange (IPBX) offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements, and defines extensions to implement this feature. This specification updates RFCs 3261 and 4235.

draft-ietf-bliss-shared-appearances-15 RFC3261 RFC4235 PROPOSED STANDARD PROPOSED STANDARD IETF rai bliss 10.17487/RFC7463
RFC7464 JavaScript Object Notation (JSON) Text Sequences N. Williams February 2015 ASCII 16132 8 JSON sequence online streaming log file

This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).

draft-ietf-json-text-sequence-13 PROPOSED STANDARD PROPOSED STANDARD IETF app json 10.17487/RFC7464
RFC7465 Prohibiting RC4 Cipher Suites A. Popov February 2015 ASCII 8397 6 TLS transport layer security

This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246.

draft-ietf-tls-prohibiting-rc4-01 RFC5246 RFC4346 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7465
RFC7466 An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) C. Dearlove T. Clausen March 2015 ASCII 17949 9 MANET NHDP OLSRv2 link quality

The link quality mechanism of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.

NHDP also collects information about symmetric 2-hop neighbors. However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.

This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust".

draft-ietf-manet-nhdp-optimization-04 RFC6130 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7466
RFC7467 URN Namespace for the North Atlantic Treaty Organization (NATO) A. Murdock April 2015 ASCII 16675 8

This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization (NATO), as specified in RFC 3406. At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications.

draft-murdock-nato-nid-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7467
RFC7468 Textual Encodings of PKIX, PKCS, and CMS Structures S. Josefsson S. Leonard April 2015 ASCII 41594 20

This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.

draft-josefsson-pkix-textual-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7468
RFC7469 Public Key Pinning Extension for HTTP C. Evans C. Palmer R. Sleevi April 2015 ASCII 61619 28 pin

This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.

draft-ietf-websec-key-pinning-21 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=7469 10.17487/RFC7469
RFC7470 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol F. Zhang A. Farrel March 2015 ASCII 28647 14

The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.

This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.

This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object.

draft-ietf-pce-rfc7150bis-01 RFC7150 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7470
RFC7471 OSPF Traffic Engineering (TE) Metric Extensions S. Giacalone D. Ward J. Drake A. Atlas S. Previdi March 2015 ASCII 38803 19

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.

This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.

Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.

draft-ietf-ospf-te-metric-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7471
RFC7472 Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme I. McDonald M. Sweet March 2015 ASCII 37666 19

This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.

This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.

draft-mcdonald-ipps-uri-scheme-18 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7472
RFC7473 Controlling State Advertisements of Non-negotiated LDP Applications K. Raza S. Boutros March 2015 ASCII 36189 15

There is no capability negotiation done for Label Distribution Protocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session.

draft-ietf-mpls-ldp-ip-pw-capability-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7473
RFC7474 Security Extension for OSPFv2 When Using Manual Key Management M. Bhatia S. Hartman D. Zhang A. Lindem Editor April 2015 ASCII 31832 14 OSPF cryptographic authentication security replay attacks

The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.

This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.

draft-ietf-ospf-security-extension-manual-keying-11 RFC2328 RFC5709 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7474
RFC7475 Increasing the Number of Area Directors in an IETF Area S. Dawkins March 2015 ASCII 9350 5

This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).

draft-dawkins-iesg-one-or-more-05 RFC2026 RFC2418 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7475
RFC7476 Information-Centric Networking: Baseline Scenarios K. Pentikousis Editor B. Ohlman D. Corujo G. Boggia G. Tyson E. Davies A. Molinaro S. Eum March 2015 ASCII 120235 45

This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence.

This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

draft-irtf-icnrg-scenarios-03 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7476
RFC7477 Child-to-Parent Synchronization in DNS W. Hardaker March 2015 ASCII 34471 15

This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.

draft-ietf-dnsop-child-syncronization-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7477 10.17487/RFC7477
RFC7478 Web Real-Time Communication Use Cases and Requirements C. Holmberg S. Hakansson G. Eriksson March 2015 ASCII 64824 28 webrtc browser websocket real-time

This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases.

This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future.

draft-ietf-rtcweb-use-cases-and-requirements-16 INFORMATIONAL INFORMATIONAL IETF rai rtcweb 10.17487/RFC7478
RFC7479 Using Ed25519 in SSHFP Resource Records S. Moonesamy March 2015 ASCII 6440 4

The Ed25519 signature algorithm has been implemented in OpenSSH. This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519.

draft-moonesamy-sshfp-ed25519-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7479 10.17487/RFC7479
RFC7480 HTTP Usage in the Registration Data Access Protocol (RDAP) A. Newton B. Ellacott N. Kong March 2015 ASCII 34671 16 Registry WHOIS

This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.

draft-ietf-weirds-using-http-15 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7480
RFC7481 Security Services for the Registration Data Access Protocol (RDAP) S. Hollenbeck N. Kong March 2015 ASCII 29954 13 RDAP Security

The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.

draft-ietf-weirds-rdap-sec-12 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7481
RFC7482 Registration Data Access Protocol (RDAP) Query Format A. Newton S. Hollenbeck March 2015 ASCII 43429 20 WHOIS

This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP).

draft-ietf-weirds-rdap-query-18 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7482
RFC7483 JSON Responses for the Registration Data Access Protocol (RDAP) A. Newton S. Hollenbeck March 2015 ASCII 125362 78 WHOIS

This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses.

draft-ietf-weirds-json-response-14 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7483
RFC7484 Finding the Authoritative Registration Data (RDAP) Service M. Blanchet March 2015 ASCII 33947 17 whois bootstrap IDN AS IPv4 IPv6 JSON

This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers.

draft-ietf-weirds-bootstrap-11 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7484
RFC7485 Inventory and Analysis of WHOIS Registration Objects L. Zhou N. Kong S. Shen S. Sheng A. Servin March 2015 ASCII 74392 33 whois restful weirds response object inventory

WHOIS output objects from registries, including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs), were collected and analyzed. This document describes the process and results of the statistical analysis of existing WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses.

draft-ietf-weirds-object-inventory-06 INFORMATIONAL INFORMATIONAL IETF app weirds 10.17487/RFC7485
RFC7486 HTTP Origin-Bound Authentication (HOBA) S. Farrell P. Hoffman M. Thomas March 2015 ASCII 64868 28 Network Working Group http authentication origin-bound key

HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.

draft-ietf-httpauth-hoba-10 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC7486
RFC7487 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE E. Bellagamba A. Takacs G. Mirsky L. Andersson P. Skoldstrom D. Ward March 2015 ASCII 67217 32 RSVP-TE GMPLS MPLS MPLS-TP OAM

This specification describes the configuration of proactive MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE.

draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7487
RFC7488 Port Control Protocol (PCP) Server Selection M. Boucadair R. Penno D. Wing P. Patil T. Reddy March 2015 ASCII 22577 12 PCP Server discovery Port Mapping Shared Address Multiple PCP Servers

This document specifies the behavior to be followed by a Port Control Protocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured.

This document updates RFC 6887.

draft-ietf-pcp-server-selection-10 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7488
RFC7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC) M. Kucherawy Editor E. Zwicky Editor March 2015 ASCII 162707 73 domain email security messaging dkim spf authentication reporting conformance

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.

Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.

DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.

draft-kucherawy-dmarc-base-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7489
RFC7490 Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) S. Bryant C. Filsfils S. Previdi M. Shand N. So April 2015 ASCII 66207 29

This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.

draft-ietf-rtgwg-remote-lfa-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7490
RFC7491 A PCE-Based Architecture for Application-Based Network Operations D. King A. Farrel March 2015 ASCII 163636 71 Software-Defined Networking (SDN) Path Computation Element (PCE) Network management Network programming

Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.

This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.

draft-farrkingel-pce-abno-architecture-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7491
RFC7492 Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines M. Bhatia D. Zhang M. Jethanandani March 2015 ASCII 21689 9 BFD KARP replay attacks cryptographic authentication security DoS attacks

This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines".

draft-ietf-karp-bfd-analysis-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7492
RFC7493 The I-JSON Message Format T. Bray Editor March 2015 ASCII 12849 6 JSON Internet JSON

I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.

draft-ietf-json-i-json-06 PROPOSED STANDARD PROPOSED STANDARD IETF app json 10.17487/RFC7493
RFC7494 IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) C. Shao H. Deng R. Pazhyannur F. Bari R. Zhang S. Matsushima April 2015 ASCII 23378 13 CAPWAP MAC Profile Encryption IEEE 802.11

The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access Control (MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs): Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions is not clearly defined. In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either the Access Controller (AC) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11 MAC Profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC.

draft-ietf-opsawg-capwap-hybridmac-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7494
RFC7495 Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) A. Montville D. Black March 2015 ASCII 19891 10 IODEF Incident Reference Enumeration Format

The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEF Reference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.

This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not update IODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references.

draft-ietf-mile-enum-reference-format-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC7495
RFC7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension M. Tuexen R. Seggelmann R. Stewart S. Loreto April 2015 ASCII 21272 11

This document defines two additional policies for the Partially Reliable Stream Control Transmission Protocol (PR-SCTP) extension. These policies allow limitation of the number of retransmissions and prioritization of user messages for more efficient usage of the send buffer.

draft-ietf-tsvwg-sctp-prpolicies-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7496
RFC7497 Rate Measurement Test Protocol Problem Statement and Requirements A. Morton April 2015 ASCII 31281 14 Internet access Asymmetric Packet Size

This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.

draft-ietf-ippm-rate-problem-10 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7497
RFC7498 Problem Statement for Service Function Chaining P. Quinn Editor T. Nadeau Editor April 2015 ASCII 28970 13 service function chaining steering sfc

This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.

The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.

This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents.

draft-ietf-sfc-problem-statement-13 INFORMATIONAL INFORMATIONAL IETF rtg sfc 10.17487/RFC7498
RFC7499 Support of Fragmentation of RADIUS Packets A. Perez-Mendez Editor R. Marin-Lopez F. Pereniguez-Garcia G. Lopez-Millan D. Lopez A. DeKok April 2015 ASCII 83448 38 RADIUS attribute extension fragmentation chunk

The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.

draft-ietf-radext-radius-fragmentation-12 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7499
RFC7500 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries R. Housley Editor O. Kolkman Editor April 2015 ASCII 15720 7

This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.

draft-iab-iana-principles-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7500
RFC7501 Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration C. Davids V. Gurbani S. Poretsky April 2015 ASCII 36573 20

This document provides a terminology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Methodology related to benchmarking SIP devices is described in the companion methodology document (RFC 7502). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements. A standard terminology and methodology will ensure that benchmarks have consistent definitions and were obtained following the same procedures.

draft-ietf-bmwg-sip-bench-term-12 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7501
RFC7502 Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration C. Davids V. Gurbani S. Poretsky April 2015 ASCII 41281 21

This document provides a methodology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Terminology related to benchmarking SIP devices is described in the companion terminology document (RFC 7501). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.

draft-ietf-bmwg-sip-bench-meth-12 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7502
RFC7503 OSPFv3 Autoconfiguration A. Lindem J. Arkko April 2015 ASCII 33521 15

OSPFv3 is a candidate for deployments in environments where autoconfiguration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. This document updates RFC 5340 by relaxing the HelloInterval/ RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link State Advertisements (LSAs).

draft-ietf-ospf-ospfv3-autoconfig-15 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7503
RFC7504 SMTP 521 and 556 Reply Codes J. Klensin June 2015 ASCII 13936 7 Reply code Email Server No Mail

This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate that an Internet host does not accept incoming mail at all. This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.

draft-klensin-smtp-521code-07 RFC1846 RFC5321 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7504
RFC7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail J. Levine M. Delany June 2015 ASCII 12534 6 DNS e-mail

Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.

draft-ietf-appsawg-nullmx-10 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg 10.17487/RFC7505
RFC7506 IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) K. Raza N. Akiya C. Pignataro April 2015 ASCII 11322 6 IPv6 LSP Ping MPLS OAM

RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in the IP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on the Reply Mode used. While a generic "Router shall examine packet" Option Value is used for the IPv4 RAO, there is no generic RAO value defined for IPv6 that can be used. This document allocates a new, generic IPv6 RAO value that can be used by MPLS Operations, Administration, and Maintenance (OAM) tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS in IPv6 environments. Consequently, it updates RFC 4379.

The initial motivation to request an IPv6 RAO value for MPLS OAM comes from the MPLS LSP Ping/Traceroute. However, this value is applicable to all MPLS OAM and not limited to MPLS LSP Ping/ Traceroute.

draft-ietf-mpls-oam-ipv6-rao-03 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7506
RFC7507 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks B. Moeller A. Langley April 2015 ASCII 17165 8

This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included.

draft-ietf-tls-downgrade-scsv-05 RFC2246 RFC4346 RFC4347 RFC5246 RFC6347 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7507
RFC7508 Securing Header Fields with S/MIME L. Cailleux C. Bonatti April 2015 ASCII 39853 19 secure headers

This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322. This technology provides security services such as data integrity, non-repudiation, and confidentiality. This extension is referred to as 'Secure Headers'.

draft-cailleux-secure-headers-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7508
RFC7509 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics R. Huang V. Singh May 2015 ASCII 23350 11

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system.

draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7509
RFC7510 Encapsulating MPLS in UDP X. Xu N. Sheth L. Yong R. Callon D. Black April 2015 ASCII 43208 19 MPLS UDP Tunnel Checksum encapsulation multipath ECMP

This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.

draft-ietf-mpls-in-udp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7510 10.17487/RFC7510
RFC7511 Scenic Routing for IPv6 M. Wilhelm April 1 2015 ASCII 14715 8 green it

This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "Green IT", whereby packets will be routed to get as much fresh-air time as possible.

draft-scenig-routing INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7511 10.17487/RFC7511
RFC7512 The PKCS #11 URI Scheme J. Pechanec D. Moffat April 2015 ASCII 48759 20 PKCS11 PKCS-11 PKCS#11,

This memo specifies a PKCS #11 Uniform Resource Identifier (URI) Scheme for identifying PKCS #11 objects stored in PKCS #11 tokens and also for identifying PKCS #11 tokens, slots, or libraries. The URI scheme is based on how PKCS #11 objects, tokens, slots, and libraries are identified in "PKCS #11 v2.20: Cryptographic Token Interface Standard".

draft-pechanec-pkcs11uri-21 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7512
RFC7513 Source Address Validation Improvement (SAVI) Solution for DHCP J. Bi J. Wu G. Yao F. Baker May 2015 ASCII 123735 54 SAVI-DHCP

This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.

draft-ietf-savi-dhcp-34 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC7513
RFC7514 Really Explicit Congestion Notification (RECN) M. Luckie April 1 2015 ASCII 9776 5

This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).

draft-luckie-recn EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7514
RFC7515 JSON Web Signature (JWS) M. Jones J. Bradley N. Sakimura May 2015 ASCII 131110 59 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.

draft-ietf-jose-json-web-signature-41 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7515
RFC7516 JSON Web Encryption (JWE) M. Jones J. Hildebrand May 2015 ASCII 108322 51 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.

draft-ietf-jose-json-web-encryption-40 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7516
RFC7517 JSON Web Key (JWK) M. Jones May 2015 ASCII 93906 40 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.

draft-ietf-jose-json-web-key-41 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7517
RFC7518 JSON Web Algorithms (JWA) M. Jones May 2015 ASCII 155905 69

This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.

draft-ietf-jose-json-web-algorithms-40 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7518
RFC7519 JSON Web Token (JWT) M. Jones J. Bradley N. Sakimura May 2015 ASCII 63039 30 Assertion Claim Security Token JavaScript Object Notation JSON JSON Web Token JWT JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

draft-ietf-oauth-json-web-token-32 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7519
RFC7520 Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) M. Miller May 2015 ASCII 198174 120 JSON Object Signing and Encryption JOSE JavaScript Object Notation JSON JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA Cookbook

This document contains a set of examples using JSON Object Signing and Encryption (JOSE) technology to protect data. These examples present a representative sampling of JSON Web Key (JWK) objects as well as various JSON Web Signature (JWS) and JSON Web Encryption (JWE) results given similar inputs.

draft-ietf-jose-cookbook-08 INFORMATIONAL INFORMATIONAL IETF sec jose 10.17487/RFC7520
RFC7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants B. Campbell C. Mortimore M. Jones Y. Goland May 2015 ASCII 44458 20 OAuth SAML JWT Assertion

This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified.

The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.

Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.

draft-ietf-oauth-assertions-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7521
RFC7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants B. Campbell C. Mortimore M. Jones May 2015 ASCII 33890 15 OAuth SAML Assertion

This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication.

draft-ietf-oauth-saml2-bearer-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7522
RFC7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants M. Jones B. Campbell C. Mortimore May 2015 ASCII 26459 12 OAuth JWT Assertion Token Security Token

This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.

draft-ietf-oauth-jwt-bearer-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7523
RFC7524 Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) Y. Rekhter E. Rosen R. Aggarwal T. Morin I. Grosclaude N. Leymann S. Saad May 2015 ASCII 105804 42

This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS.

draft-ietf-mpls-seamless-mcast-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7524
RFC7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Y. Sheffer R. Holz P. Saint-Andre May 2015 ASCII 60283 27 Transport Layer Security TLS DTLS Secure Sockets Layer SSL

Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.

draft-ietf-uta-tls-bcp-11 BCP0195 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app uta http://www.rfc-editor.org/errata_search.php?rfc=7525 10.17487/RFC7525
RFC7526 Deprecating the Anycast Prefix for 6to4 Relay Routers O. Troan B. Carpenter Editor May 2015 ASCII 20894 10

Experience with the 6to4 transition mechanism defined in RFC 3056 ("Connection of IPv6 Domains via IPv4 Clouds") has shown that the mechanism is unsuitable for widespread deployment and use in the Internet when used in its anycast mode. Therefore, this document requests that RFC 3068 ("An Anycast Prefix for 6to4 Relay Routers") and RFC 6732 ("6to4 Provider Managed Tunnels") be made obsolete and moved to Historic status. It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343.

draft-ietf-v6ops-6to4-to-historic-11 RFC3068 RFC6732 BCP0196 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7526
RFC7527 Enhanced Duplicate Address Detection R. Asati H. Singh W. Beebee C. Pignataro E. Dart W. George April 2015 ASCII 24528 11 Automated DAD loopback detection

IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD. This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862.

draft-ietf-6man-enhanced-dad-15 RFC4429 RFC4861 RFC4862 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7527
RFC7528 A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association P. Higgs J. Piesing April 2015 ASCII 12921 7

This document describes a Uniform Resource Name (URN) namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association for naming persistent resources defined within HbbTV specifications. Example resources include technical documents and specifications, Extensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by HbbTV.

draft-higgs-hbbtv-urn-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7528
RFC7529 Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) C. Daboo G. Yakushev May 2015 ASCII 43124 21 calendaring iCalendar iTIP CalDAV

This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules.

draft-ietf-calext-rscale-04 RFC5545 RFC6321 RFC7265 PROPOSED STANDARD PROPOSED STANDARD IETF app calext 10.17487/RFC7529
RFC7530 Network File System (NFS) Version 4 Protocol T. Haynes Editor D. Noveck Editor March 2015 ASCII 724613 323

The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol.

draft-ietf-nfsv4-rfc3530bis-35 RFC3530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=7530 10.17487/RFC7530
RFC7531 Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description T. Haynes Editor D. Noveck Editor March 2015 ASCII 67541 39

The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its heritage to NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

RFC 7530 formally obsoletes RFC 3530. This document, together with RFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol.

draft-ietf-nfsv4-rfc3530bis-dot-x-24 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7531
RFC7532 Namespace Database (NSDB) Protocol for Federated File Systems J. Lentini R. Tewari C. Lever Editor March 2015 ASCII 127373 65 Federated File Systems

This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.

draft-ietf-nfsv4-federated-fs-protocol-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7532
RFC7533 Administration Protocol for Federated File Systems J. Lentini R. Tewari C. Lever Editor March 2015 ASCII 76429 37 Federated File Systems

This document describes the administration protocol for a federated file system (FedFS) that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.

draft-ietf-nfsv4-federated-fs-admin-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7533
RFC7534 AS112 Nameserver Operations J. Abley W. Sotomayor May 2015 ASCII 47269 24 AS112 DNS reverse DNS anycast

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.

This document obsoletes RFC 6304.

draft-ietf-dnsop-rfc6304bis-06 RFC6304 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7534
RFC7535 AS112 Redirection Using DNAME J. Abley B. Dickson W. Kumari G. Michaelson May 2015 ASCII 31730 16 DNS root server

AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.

This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.

draft-ietf-dnsop-as112-dname-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7535
RFC7536 Large-Scale Broadband Measurement Use Cases M. Linsner P. Eardley T. Burbridge F. Sorensen May 2015 ASCII 41039 17 lmap

Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scale Measurement of Broadband Performance (LMAP) framework, information model, and protocol. This document details two use cases that can assist in developing that framework. The details of the measurement metrics themselves are beyond the scope of this document.

draft-ietf-lmap-use-cases-06 INFORMATIONAL INFORMATIONAL IETF ops lmap 10.17487/RFC7536
RFC7537 IANA Registries for LSP Ping Code Points B. Decraene N. Akiya C. Pignataro L. Andersson S. Aldrin May 2015 ASCII 11895 7 MPLS OAM lsp ping LSP-Ping

RFCs 4379 and 6424 created name spaces for Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for Downstream Mapping object Flags (DS Flags), Multipath Types, Pad TLVs, and Interface and Label Stack Address Types.

There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose.

draft-ietf-mpls-lsp-ping-registry-03 RFC4379 RFC6424 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7537
RFC7538 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) J. Reschke April 2015 ASCII 11189 6 HTTP redirect status code

This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).

draft-ietf-httpbis-rfc7238bis-03 RFC7238 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7538
RFC7539 ChaCha20 and Poly1305 for IETF Protocols Y. Nir A. Langley May 2015 ASCII 88173 45 AEAD

This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.

This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG).

draft-irtf-cfrg-chacha20-poly1305-10 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7539 10.17487/RFC7539
RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2) M. Belshe R. Peon M. Thomson Editor May 2015 ASCII 209580 96 HTTP SPDY Web

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.

This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

draft-ietf-httpbis-http2-17 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7540
RFC7541 HPACK: Header Compression for HTTP/2 R. Peon H. Ruellan May 2015 ASCII 117827 55 HTTP Header

This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.

draft-ietf-httpbis-header-compression-12 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7541
RFC7542 The Network Access Identifier A. DeKok May 2015 ASCII 66596 30

In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282.

draft-ietf-radext-nai-15 RFC4282 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC7542
RFC7543 Covering Prefixes Outbound Route Filter for BGP-4 H. Jeng L. Jalil R. Bonica K. Patel L. Yong May 2015 ASCII 38583 21 ORF VPN

This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks.

draft-ietf-bess-orf-covering-prefixes-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=7543 10.17487/RFC7543
RFC7545 Protocol to Access White-Space (PAWS) Databases V. Chen Editor S. Das L. Zhu J. Malyar P. McCann May 2015 ASCII 188634 90 dynamic spectrum radio spectrum wireless spectrum spectrum spectrum database TV white space TVWS TVBD white space device WSD

Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "white space". Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization.

One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White-Space (PAWS) Databases".

draft-ietf-paws-protocol-20 PROPOSED STANDARD PROPOSED STANDARD IETF app paws 10.17487/RFC7545
RFC7546 Structure of the Generic Security Service (GSS) Negotiation Loop B. Kaduk May 2015 ASCII 50075 21 GSS-API security authentication

This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified.

draft-ietf-kitten-gss-loop-05 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC7546
RFC7547 Management of Networks with Constrained Devices: Problem Statement and Requirements M. Ersue Editor D. Romascanu J. Schoenwaelder U. Herberg May 2015 ASCII 87357 44 Constrained Management IoT M2M

This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved.

draft-ietf-opsawg-coman-probstate-reqs-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7547
RFC7548 Management of Networks with Constrained Devices: Use Cases M. Ersue Editor D. Romascanu J. Schoenwaelder A. Sehgal May 2015 ASCII 71103 26 Constrained Management IoT M2M

This document discusses use cases concerning the management of networks in which constrained devices are involved. A problem statement, deployment options, and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements" (RFC 7547).

draft-ietf-opsawg-coman-use-cases-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7548
RFC7549 3GPP SIP URI Inter-Operator Traffic Leg Parameter C. Holmberg J. Holm R. Jesske M. Dolly May 2015 ASCII 32607 17 3GPP IMS NNI IOTL CSCF RAVEL TRF operator transit

In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.

This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).

draft-holmberg-dispatch-iotl-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7549
RFC7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options O. Troan B. Volz M. Siodelski May 2015 ASCII 54206 24 CPE CER CE Customer Edge Router Prefix Delegation IPv6 Address Option Session State Machine Advertise Time Timer T1 T2 Renew Rebind Confirm Decline Provision

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options. DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed. This document updates RFCs 3315 and 3633 to address these issues.

draft-ietf-dhc-dhcpv6-stateful-issues-12 RFC3315 RFC3633 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7550
RFC7551 RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) F. Zhang Editor R. Jing R. Gandhi Editor May 2015 ASCII 43752 20

This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.

draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7551
RFC7552 Updates to LDP for IPv6 R. Asati C. Pignataro K. Raza V. Manral R. Papneja June 2015 ASCII 48801 24 Label Distribution Protocol

The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both. This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4). This document updates RFCs 5036 and 6720.

draft-ietf-mpls-ldp-ipv6-17 RFC5036 RFC6720 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7552
RFC7553 The Uniform Resource Identifier (URI) DNS Resource Record P. Faltstrom O. Kolkman June 2015 ASCII 28278 14 Operations DNS applications

This document describes the already registered DNS resource record (RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs.

draft-faltstrom-uri-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7553
RFC7554 Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement T. Watteyne Editor M. Palattella L. Grieco May 2015 ASCII 50706 23 6TiSCH

This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.

draft-ietf-6tisch-tsch-06 INFORMATIONAL INFORMATIONAL IETF int 6tisch 10.17487/RFC7554
RFC7555 Proxy MPLS Echo Request G. Swallow V. Lim S. Aldrin June 2015 ASCII 62109 28

This document defines a means of remotely initiating Multiprotocol Label Switched Protocol (MPLS) Pings on Label Switched Paths. An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root).

draft-ietf-mpls-proxy-lsp-ping-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7555 10.17487/RFC7555
RFC7556 Multiple Provisioning Domain Architecture D. Anipko Editor June 2015 ASCII 59307 25

This document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.

draft-ietf-mif-mpvd-arch-11 INFORMATIONAL INFORMATIONAL IETF int mif http://www.rfc-editor.org/errata_search.php?rfc=7556 10.17487/RFC7556
RFC7557 Extension Mechanism for the Babel Routing Protocol J. Chroboczek May 2015 ASCII 22626 11 Babel routing extension TLV sub-TLV

This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.

draft-chroboczek-babel-extension-mechanism-04 RFC6126 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7557
RFC7558 Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions K. Lynn S. Cheshire M. Blanchet D. Migault July 2015 ASCII 30291 14

DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements for scalable DNS-SD.

draft-ietf-dnssd-requirements-06 INFORMATIONAL INFORMATIONAL IETF int dnssd 10.17487/RFC7558
RFC7559 Packet-Loss Resiliency for Router Solicitations S. Krishnan D. Anipko D. Thaler May 2015 ASCII 11619 6

When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these Router Solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations.

draft-ietf-6man-resilient-rs-06 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7559
RFC7561 Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN J. Kaippallimalil R. Pazhyannur P. Yegani June 2015 ASCII 50348 23 PMIPv6 Wi-Fi QoS

This document provides guidelines for achieving end-to-end Quality of Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11 and Wi-Fi Multimedia - Admission Control (WMM-AC) describe methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters. This document is intended to be used as a companion document to RFC 7222 to enable implementation of end-to-end QoS.

draft-ietf-netext-pmip-qos-wifi-08 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7561
RFC7562 Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates D. Thakore July 2015 ASCII 32576 15 Transport Layer Security TLS SupplementalData DTCP

This document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol. This is in accordance with the guidelines for authorization extensions as specified in RFC 5878. As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680. This authorization data type extension is in support of devices containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).

draft-dthakore-tls-authz-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7562
RFC7563 Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option R. Pazhyannur S. Speicher S. Gundavelli J. Korhonen J. Kaippallimalil June 2015 ASCII 27982 12

The Access Network Identifier (ANI) mobility option was introduced in RFC 6757, "Access Network Identifier (ANI) Option for Proxy Mobile IPv6". This enables a Mobile Access Gateway (MAG) to convey identifiers like the network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub-options to carry the civic location and the MAG group identifier. This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated.

draft-ietf-netext-ani-location-09 RFC6757 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7563
RFC7564 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols P. Saint-Andre M. Blanchet May 2015 ASCII 93580 40 internationalization i18n Stringprep

Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454.

draft-ietf-precis-framework-23 RFC3454 PROPOSED STANDARD PROPOSED STANDARD IETF app precis 10.17487/RFC7564
RFC7565 The 'acct' URI Scheme P. Saint-Andre May 2015 ASCII 18244 8 Uniform Resource Identifier URI

This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.

draft-ietf-appsawg-acct-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7565
RFC7566 Enumservice Registration for 'acct' URI L. Goix K. Li June 2015 ASCII 16874 8 Reverse Phone Lookup Social Network Web

This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).

draft-goix-appsawg-enum-acct-uri-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7566
RFC7567 IETF Recommendations Regarding Active Queue Management F. Baker Editor G. Fairhurst Editor July 2015 ASCII 76832 31

This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.

Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.

draft-ietf-aqm-recommendation-11 RFC2309 BCP0197 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv aqm 10.17487/RFC7567
RFC7568 Deprecating Secure Sockets Layer Version 3.0 R. Barnes M. Thomson A. Pironti A. Langley June 2015 ASCII 13489 7 SSL TLS insecure diediedie

The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.

This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.

draft-ietf-tls-sslv3-diediedie-03 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7568
RFC7569 Registry Specification for Mandatory Access Control (MAC) Security Label Formats D. Quigley J. Lu T. Haynes July 2015 ASCII 22406 10 NFSv4

In the past, Mandatory Access Control (MAC) systems have used very rigid policies that were implemented in particular protocols and platforms. As MAC systems become more widely deployed, additional flexibility in mechanism and policy will be required. While traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include such technologies as type enforcement. Due to the wide range of policies and mechanisms that need to be accommodated, it is unlikely that the use of a single security label format and model will be viable.

To allow multiple MAC mechanisms and label formats to co-exist in a network, this document creates a registry of label format specifications. This registry contains label format identifiers and provides for the association of each such identifier with a corresponding extensive document outlining the exact syntax and use of the particular label format.

draft-ietf-nfsv4-lfs-registry-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7569
RFC7570 Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) C. Margaria Editor G. Martinelli S. Balls B. Wright July 2015 ASCII 34223 15 RSVP-TE GMPLS

RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop.

draft-ietf-teas-lsp-attribute-ro-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7570
RFC7571 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback J. Dong M. Chen Z. Li D. Ceccarelli July 2015 ASCII 19767 9 OAM

This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane.

draft-ietf-teas-rsvp-te-li-lb-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7571
RFC7572 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging P. Saint-Andre A. Houri J. Hildebrand June 2015 ASCII 29027 13 XMPP Jabber SIP SIMPLE IM Instant Message

This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).

draft-ietf-stox-im-13 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7572
RFC7573 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions P. Saint-Andre S. Loreto June 2015 ASCII 42607 20 Text Chat Instant Messaging Session Initiation Protocol SIP Message Sessions Relay Protocol MSRP Extensible Messaging and Presence Protocol XMPP

This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).

draft-ietf-stox-chat-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7573
RFC7574 Peer-to-Peer Streaming Peer Protocol (PPSPP) A. Bakker R. Petrocco V. Grishchenko July 2015 ASCII 208360 85 video on demand live streaming content integrity protection

The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on- demand) and live audio/video content. It is based on the peer-to- peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers. PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using Low Extra Delay Background Transport (LEDBAT) for congestion control.

draft-ietf-ppsp-peer-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ppsp 10.17487/RFC7574
RFC7575 Autonomic Networking: Definitions and Design Goals M. Behringer M. Pritikin S. Bjarnason A. Clemm B. Carpenter S. Jiang L. Ciavaglia June 2015 ASCII 36838 16 self-management self-chop autonomic secure by default simplification

Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements.

This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group.

draft-irtf-nmrg-autonomic-network-definitions-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7575
RFC7576 General Gap Analysis for Autonomic Networking S. Jiang B. Carpenter M. Behringer June 2015 ASCII 42472 17

This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.

This document is a product of the IRTF's Network Management Research Group.

draft-irtf-nmrg-an-gap-analysis-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7576
RFC7578 Returning Values from Forms: multipart/form-data L. Masinter July 2015 ASCII 30240 15 media-type multipurpose internet mail extensions

This specification defines the multipart/form-data media type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. This document obsoletes RFC 2388.

draft-ietf-appsawg-multipart-form-data-11 RFC2388 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg 10.17487/RFC7578
RFC7579 General Network Element Constraint Encoding for GMPLS-Controlled Networks G. Bernstein Editor Y. Lee Editor D. Li W. Imajuku J. Han June 2015 ASCII 62347 28 WSON Optical Network Control Protocol-agnostic encoding

Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links.

This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.

draft-ietf-ccamp-general-constraint-encode-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7579
RFC7580 OSPF-TE Extensions for General Network Element Constraints F. Zhang Y. Lee J. Han G. Bernstein Y. Xu June 2015 ASCII 25189 12 WSON Optical Routing

Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time division (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS.

draft-ietf-ccamp-gmpls-general-constraints-ospf-te-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7580
RFC7581 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks G. Bernstein Editor Y. Lee Editor D. Li W. Imajuku J. Han June 2015 ASCII 72511 37 Optical Networks GMPLS control plane Wavelength Assignment Optical LSP Optical Routing

A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs.

This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE).

draft-ietf-ccamp-rwa-wson-encode-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7581
RFC7582 Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels E. Rosen IJ. Wijnands Y. Cai A. Boers July 2015 ASCII 79244 34

A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513, 6514, and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels.

draft-ietf-bess-mvpn-bidir-04 RFC6513 RFC6514 RFC6625 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7582
RFC7584 Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs) R. Ravindranath T. Reddy G. Salgueiro July 2015 ASCII 32675 14

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing.

This document defines behavior for a B2BUA performing ICE processing. The goal of this document is to ensure that B2BUAs properly handle SIP messages that carry ICE semantics in Session Description Protocol (SDP) and STUN messages received as part of the ICE procedures for NAT and Firewall traversal of multimedia sessions.

draft-ietf-straw-b2bua-stun-08 PROPOSED STANDARD PROPOSED STANDARD IETF art straw http://www.rfc-editor.org/errata_search.php?rfc=7584 10.17487/RFC7584
RFC7586 The Scalable Address Resolution Protocol (SARP) for Large Data Centers Y. Nachum L. Dunbar I. Yerushalmi T. Mizrahi June 2015 ASCII 44538 21 ARP data center proxy

This document introduces the Scalable Address Resolution Protocol (SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.

draft-nachum-sarp-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7586
RFC7587 RTP Payload Format for the Opus Speech and Audio Codec J. Spittka K. Vos JM. Valin June 2015 ASCII 41770 18 audio codec

This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format.

draft-ietf-payload-rtp-opus-11 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7587
RFC7588 A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem R. Bonica C. Pignataro J. Touch July 2015 ASCII 24453 12 GRE MTU Fragmentation

This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration.

draft-ietf-intarea-gre-mtu-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC7588
RFC7589 Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication M. Badra A. Luchuk J. Schoenwaelder June 2015 ASCII 22727 11 NETCONF TLS

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.

draft-ietf-netconf-rfc5539bis-10 RFC5539 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC7589
RFC7590 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre T. Alkemade June 2015 ASCII 20393 9 Extensible Messaging and Presence Protocol XMPP Jabber Secure Sockets Layer SSL Transport Layer Security TLS instant messaging presence encryption authentication

This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120.

draft-ietf-uta-xmpp-07 RFC6120 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC7590
RFC7591 OAuth 2.0 Dynamic Client Registration Protocol J. Richer Editor M. Jones J. Bradley M. Machulak P. Hunt July 2015 ASCII 87811 39 OpenID Connect Dynamic Client Registration OpenID Connect oidc openid user managed access uma Dynamic Registration Dynamic Client Registration

This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

draft-ietf-oauth-dyn-reg-30 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7591
RFC7592 OAuth 2.0 Dynamic Client Registration Management Protocol J. Richer Editor M. Jones J. Bradley M. Machulak July 2015 ASCII 38044 18

This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods.

draft-ietf-oauth-dyn-reg-management-15 EXPERIMENTAL EXPERIMENTAL IETF sec oauth 10.17487/RFC7592
RFC7595 Guidelines and Registration Procedures for URI Schemes D. Thaler Editor T. Hansen T. Hardie June 2015 ASCII 42897 19 URI scheme IRI Internationalized Resource Identifier Uniform Resource Identifier URI registration

This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395.

draft-ietf-appsawg-uri-scheme-reg-06 RFC4395 BCP0035 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7595 10.17487/RFC7595
RFC7612 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services P. Fleming I. McDonald June 2015 ASCII 99282 54

This document defines a schema, object classes, and attributes, for Printers and print services, for use with directories that support the Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of "Internet Printing Protocol/1.1: Model and Semantics" (RFC 2911). Additional Printer attributes are based on definitions in "Printer MIB v2" (RFC 3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG 5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG 5100.13), and "IPP Everywhere" (PWG 5100.14).

This memo is an Independent Submission to the RFC Editor by the Internet Printing Protocol (IPP) Working Group of the IEEE-ISTO Printer Working Group (PWG), as part of their PWG "IPP Everywhere" (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software.

This document obsoletes RFC 3712.

draft-mcdonald-ldap-printer-schema-13 RFC3712 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7612
STD0001 [STD number 1 is retired. It was "Internet Official Protocol Standards". See BCP 9 / RFC 7100 for more information.] STD0002 [Reserved for Assigned Numbers. See RFC 1700 and RFC 3232.] STD0003 Requirements for Internet Hosts RFC1122 RFC1123 STD0004 [Reserved for Router Requirements. See RFC 1812.] STD0005 Internet Protocol RFC0791 RFC0792 RFC0919 RFC0922 RFC0950 RFC1112 STD0006 User Datagram Protocol RFC0768 STD0007 Transmission Control Protocol RFC0793 STD0008 Telnet Protocol RFC0854 RFC0855 STD0009 File Transfer Protocol RFC0959 STD0010 Simple Mail Transfer Protocol RFC0821 RFC0974 RFC1869 RFC1870 STD0011 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES RFC0822 STD0012 [Reserved for Network Time Protocol (NTP). See RFC 1305.] STD0013 Domain Name System RFC1034 RFC1035 STD0014 [Was Mail Routing and the Domain System. Now Historic.] STD0015 [Was Simple Network Management Protocol. Now Historic.] STD0016 Structure of Management Information RFC1155 RFC1212 STD0017 Management Information Base for Network Management of TCP/IP-based internets: MIB-II RFC1213 STD0018 [Was Exterior Gateway Protocol (RFC 904). Now Historic.] STD0019 NetBIOS Service Protocols RFC1001 RFC1002 STD0020 Echo Protocol RFC0862 STD0021 Discard Protocol RFC0863 STD0022 Character Generator Protocol RFC0864 STD0023 Quote of the Day Protocol RFC0865 STD0024 Active users RFC0866 STD0025 Daytime Protocol RFC0867 STD0026 Time Protocol RFC0868 STD0027 Telnet Binary Transmission RFC0856 STD0028 Telnet Echo Option RFC0857 STD0029 Telnet Suppress Go Ahead Option RFC0858 STD0030 Telnet Status Option RFC0859 STD0031 Telnet Timing Mark Option RFC0860 STD0032 Telnet Extended Options: List Option RFC0861 STD0033 The TFTP Protocol (Revision 2) RFC1350 STD0034 [Was Routing Information Protocol (RIP). Replaced by STD 56.] STD0035 ISO Transport Service on top of the TCP Version: 3 RFC1006 STD0036 Transmission of IP and ARP over FDDI Networks RFC1390 STD0037 Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware RFC0826 STD0038 A Reverse Address Resolution Protocol RFC0903 STD0039 [Was BBN Report 1822 (IMP/Host Interface). Now Historic.] STD0040 Host Access Protocol specification RFC0907 STD0041 A Standard for the Transmission of IP Datagrams over Ethernet Networks RFC0894 STD0042 Standard for the transmission of IP datagrams over experimental Ethernet networks RFC0895 STD0043 Standard for the transmission of IP datagrams over IEEE 802 networks RFC1042 STD0044 DCN Local-Network Protocols RFC0891 STD0045 Internet Protocol on Network System's HYPERchannel: Protocol Specification RFC1044 STD0046 Transmitting IP traffic over ARCNET networks RFC1201 STD0047 Nonstandard for transmission of IP datagrams over serial lines: SLIP RFC1055 STD0048 Standard for the transmission of IP datagrams over NetBIOS networks RFC1088 STD0049 Standard for the transmission of 802.2 packets over IPX networks RFC1132 STD0050 [Reserved for Definitions of Managed Objects for the Ethernet-like Interface Types. See RFC 3638.] STD0051 The Point-to-Point Protocol (PPP) RFC1661 RFC1662 STD0052 The Transmission of IP Datagrams over the SMDS Service RFC1209 STD0053 Post Office Protocol - Version 3 RFC1939 STD0054 OSPF Version 2 RFC2328 STD0055 Multiprotocol Interconnect over Frame Relay RFC2427 STD0056 RIP Version 2 RFC2453 STD0057 RIP Version 2 Protocol Applicability Statement RFC1722 STD0058 Structure of Management Information Version 2 (SMIv2) RFC2578 RFC2579 RFC2580 STD0059 Remote Network Monitoring Management Information Base RFC2819 STD0060 SMTP Service Extension for Command Pipelining RFC2920 STD0061 A One-Time Password System RFC2289 STD0062 Simple Network Management Protocol Version 3 (SNMPv3) RFC3411 RFC3412 RFC3413 RFC3414 RFC3415 RFC3416 RFC3417 RFC3418 STD0063 UTF-8, a transformation format of ISO 10646 RFC3629 STD0064 RTP: A Transport Protocol for Real-Time Applications RFC3550 STD0065 RTP Profile for Audio and Video Conferences with Minimal Control RFC3551 STD0066 Uniform Resource Identifier (URI): Generic Syntax RFC3986 STD0067 XDR: External Data Representation Standard RFC4506 STD0068 Augmented BNF for Syntax Specifications: ABNF RFC5234 STD0069 The Extensible Provisioning Protocol (EPP) RFC5730 RFC5731 RFC5732 RFC5733 RFC5734 STD0070 Cryptographic Message Syntax (CMS) RFC5652 STD0071 SMTP Service Extension for 8-bit MIME Transport RFC6152 STD0072 Message Submission for Mail RFC6409 STD0073 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages RFC6522 STD0074 Automated Updates of DNS Security (DNSSEC) Trust Anchors RFC5011 STD0075 Extension Mechanisms for DNS (EDNS(0)) RFC6891 STD0076 DomainKeys Identified Mail (DKIM) Signatures RFC6376 STD0077 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information RFC7011 STD0078 Simple Network Management Protocol (SNMP) Security RFC5343 RFC5590 RFC5591 RFC6353 STD0079 Internet Key Exchange Protocol Version 2 (IKEv2) RFC7296 STD0080 ASCII format for network interchange RFC0020