David McWalter（編集担当、Data Connection）
URI（Uniform Resource Identifier）用のMIB省略表記の仕様がRFC 5017として勧告された。
このMIBモジュールはURI（STD 66）を表現するための省略表記を定義している。独自の表記方法を持つMIBモジュールで導入される。
John Jason Brzozowski（Comcast Cable）、Kim Kinnear（シスコシステムズ）、Bernard Volz（シスコシステムズ）、Shengyou Zeng（シスコシステムズ）
Enke Chen（シスコシステムズ）、Srihari R. Sangli（シスコシステムズ）
Kim Kinnear（シスコシステムズ）、Marie Normoyle（シスコシステムズ）、Mark Stapp（シスコシステムズ）
DHCPv4（Dynamic Host Configuration Protocol version 4）リレーエージェントフラグサブオプションの仕様がRFC 5010として勧告された。
RFC 5010はDHCPリレーエージェント情報オプションの新しいサブオプションを定義して、DHCPリレーで転送されたパケット用に2つのフラグを付けられるようにする。
1つのフラグは、DHCPリレーがパケットをユニキャストパケットで受信したか、ブロードキャストパケットで受信したのかを示すためにある。DHCPサーバーがこのフラグを使って、クライアントからの要求が元々ブロードキャストなのかユニキャストなのかで扱いを変えられるようになる。
Eric W. Burger（編集担当、BEA Systems）
IMAPプロトコルのWITHIN検索拡張の仕様がRFC 5032として勧告された。
RFC 5032はIMAPのSEARCHコマンドに対するWITHIN拡張について述べている。IMAPのSEARCHは日時が指定された範囲内あるいは範囲外にあるメッセージを応答するコマンドである。SEARCHコマンドの既存のオプションであるBEFOREおよびSINCEでは、クライアントが指定した日時を基準に検索するのに対して、RFC 5032で定義されたOLDERおよびYOUNGERでは、クライアントが指定した間隔（秒）を基準にメッセージを検索する。
WITHIN拡張は常時検索するクライアントで、一定間隔で検索処理を実行する性能がなかったり、ネットワークの帯域幅が不足していたりして、何度も同じ要求を送りたくない場合や、同じ応答を受け取りたくない場合に有用である。
Michael StJohns
Luca Martini（シスコシステムズ）、Chris Metz（シスコシステムズ）、Florin Balus（アルカテル・ルーセント）、Jeff Sugimoto（ノーテルネットワークス）
集約用のAII（Attachment Individual Identifier）タイプの仕様がRFC 5003として勧告された。
AIIとは、疑似有線（Pseudowire）エンドポイントを識別するTLV（Type Length Value）フィールドを含むポイント間疑似有線を確立するために用いるシグナリングプロトコルのことである。RFC 5003は、AII TLVフィールドの新形態となるAII構造体を定義して、スケーラビリティを改善し、VPN（Virtual Private Network）の自動発見用のAII集約に対応する。
AII集約は、顧客のニーズに基づいて、選択されたローカルPE（Provider Edge）とリモートPE間で疑似有線が確立されている大規模なドメイン間の仮想専用線サービスネットワークで利用する場合に有用である。
Stefan Santesson（マイクロソフト）
IMAP COMPRESS拡張の仕様がRFC 4978として勧告された。
COMPRESS拡張により、IMAP接続は効率的かつ効果的に圧縮される。
Jim Schaad（Soaring Hawk Consulting）
Claudio DeSanti（シスコシステムズ）、H.K. Vivek（シスコシステムズ）、Keith McCloghrie（シスコシステムズ）Silvano Gai（Nuova Systems）
Vipin Jain（Riverstone Networks）、Paul W. Howard（ジュニパーネットワークス）、Sam Henderson（シスコシステムズ）、Keyur Parikh（Harris）
L2TP（Layer 2 Tunneling Protocol）用フェイルオーバー拡張「failover」の仕様がRFC 4951として勧告された。
L2TPは、ネットワークの両端で状態を共有するコネクション指向のプロトコルである。共有する状態には、L2TPの運用に不可欠でありながら、L2TP制御コネクションで使われるパケット連番のように、プロトコルの仕様上、同期が取りにくいものもある。
一方の側で制御コネクションにエラーが発生すると、L2TPは新たに制御コネクションを作り直し、既存のコネクションに関する情報をやりとりして、既存のコネクションと新たな制御コネクションを関連づける。ただし、こうしたメカニズムは、両端でコネクションの状態を同期してアクティブフェイルオーバー機能を果たすものではなく、元のコネクションに関する情報はすぐには取得できないため、手間を省いているだけである。
RFC 4951で定義されているプロトコル拡張では、状態の回復力やL2TPネットワークにおける障害回復力の強化、リモートシステムのレイヤー2接続の安定性の増進が図られている。
NSID（DNS Name Server Identifier：DNSネームサーバー識別子）オプションの仕様がRFC 5001として勧告された。
DNSエニキャスト通信や負荷分散など、複数のDNSネームサーバーが1つのIPアドレスを共有するようなメカニズムの利用が増えたため、あるDNSの問い合わせに対して、実際にはどのネームサーバーが応答したのかを知るのが難しくなっている。応急的なメカニズムとして、ネームサーバーの構成を調べる場合などに事後調査用の問い合わせを送る方法もあるが、完全に信頼できる方法で問い合わせに応答したネームサーバーを特定するには、DNSの応答情報にネームサーバーを識別するための情報を埋め込むしかない。そこでRFC 5001では、こうした機能を実現するためのプロトコル拡張を定義している。
Simon Josefsson（SJD）
Tobias Gondrom（Open Text）、Ralf Brandner（InterComponentWare）、Ulrich Pordesch（Fraunhofer Gesellschaft）
Brian Korver（Network Resonance）
IKEv1/ISAKMP、IKEv2およびPKIXのIPsec PKIプロファイルの仕様がRFC 4945として勧告された。
IKE（Internet Key Exchange）およびPKIX（Public Key Infrastructure for X.509）の証明書プロファイルはともに、与えられた用途でのみ利用しなければならないフレームワークを実現している。RFC 4945はIPsec用PKIの実装者向けの文書で、IKE/IPsecでPKI技術を用いる要件を定義するIKEおよびPKIXのプロファイルを提供している。RFC 4945はIKEv1やIKEv2といったプロトコル仕様（公開鍵証明書と関連する鍵の存在を前提にしながら、PKI問題について明確には触れていない）を補うものであり、公開鍵証明書と関連する鍵の問題について述べている。
Kurt D. Zeilenga（Isode Limited）
Andrew L. Newton（ベリサイン）
Andrew L. Newton（ベリサイン）
Andrew L. Newton（ベリサイン）
Alexander Mayrhofer（enum.at）
Paul Traina（Blissfully Retired）、Danny McPherson（Arbor Networks）、John G. Scudder（ジュニパーネットワークス）
BGP（Border Gateway Protocol）用自律システム（AS：Autonomous System）の連携の仕様がRFC 5065として勧告された。
BGPはTCP/IPネットワーク用に設計されたAS間用ルーティングプロトコルである。しかし、さまざまな文書でこれまで指摘されているように、BGPは同一ドメイン内のBGPスピーカーがフルメッシュ接続していなければならないという要件に代表される、スケーラビリティ上の深刻な問題がある。
RFC 5065が述べているのはBGPの拡張仕様であり、連携したASが外部からは単一のASとして見えるようにして、フルメッシュ接続の要件を不要にする。この拡張仕様の目的は、ポリシー管理をしやすくして、大規模なASを保守する管理上の煩雑さを解消することである。なお、RFC 5065によってRFC 3065は廃止される。
Mark Watson（Digital Fountain）、Michael Luby（Digital Fountain）、Lorenzo Vicisano（Digital Fountain）
FEC（Forward Error Correction：前方誤り訂正）ビルディングブロックの仕様がRFC 5052として勧告された。
RFC 5052はFEC符号を使って、どのようにIPマルチキャスト上のバルクデータ伝送の信頼性を実現し、増大させるのかについて述べている。バルクデータ伝送用のFEC符号、符号化されたデータの通信に必要な情報を定義するためのフレームワークを定義している。また、こうした情報のやりとりに用いるデータ形式やコードについても定義している。符号化されたデータとともに伝送される情報も、データとは別に伝送される情報のどちらも考慮されている。また、新たにFECコードの仕様を定めたり、コードに関連する情報通信の要件やIANA登録を定義したりするための手続きについても述べられている。さらに、このフレームワークで定義されているFECコードを用いるCDP（Content Delivery Protocol）の要件も定義されている。なお、関連文書である「信頼性のあるマルチキャストにおけるFECの利用」（RFC 3453）では、コンテンツ配信用のFECコードの応用例が述べられている。RFC 5052により、RFC 3452は廃止される。
Alexander Mayrhofer（enum.at）
John Drake（ボーイング衛星システム）、Deborah Brungard（AT&T）、Zafar Ali（シスコシステムズ）、Arthi Ayyangar（Nuova Systems）、Don Fedyk（Nortel Networks）
コール対応用のGMPLS RSVP-TE（Generalized MPLS Resource Reservation Protocol - Traffic Engineering）シグナリング拡張の仕様がRFC 4974として勧告された。
ある種のネットワークトポロジーでは、終点と上位ネットワークへの中継点との関係を維持しておくことが個々のサービスを提供する上でメリットになることがある。こうした関係は「コール」と呼ばれる。
コールそのものはユーザートラフィックを実際に伝送することはなく、その後のコネクションで使われる関係を構築するだけである。GMPLSの場合、こうしたコネクションのことをLSP（Label Switched Path）と呼ぶ。RFC 4974は、GMPLS RSVP-TEシグナリングをどのように用いれば、あるいは拡張すればコールに対応できるのかについて述べている。このメカニズムは、完全かつ論理コールとコネクションの分離を実現する。
RFC 4974が提示するメカニズムはマルチエリアを含むあらゆる環境、パケットやレイヤー2、時分割、ラムダ、ファイバースイッチなど、あらゆるインターフェイスに適用可能である。
Claudio DeSanti（シスコシステムズ）、H.K. Vivek（シスコシステムズ）、Keith McCloghrie（シスコシステムズ）、Silvano Gai（Nuova Systems）
Claudio DeSanti（シスコシステムズ）、H.K. Vivek（シスコシステムズ）、Keith McCloghrie（シスコシステムズ）、Silvano Gai（Nuova Systems）
Ronald P. Bonica（ジュニパーネットワークス）、Der-Hwa Gan（コンサルタント）、Daniel C. Tappan（コンサルタント）、Carlos Pignataro（シスコシステムズ）
Jean-Philippe Vasseur（シスコシステムズ）、Stefano Previdi（シスコシステムズ）、Mike Shand（シスコシステムズ）、Les Ginsberg（シスコシステムズ）、Acee Lindem（レッドバックネットワークス）、Naiming Shen（シスコシステムズ）、Rahul Aggarwal（ジュニパーネットワークス）、Scott Shaffer
JP Vasseur（編集担当、シスコシステムズ）、JL Le Roux（編集担当、フランステレコム）、安川正祥（NTT）、Stefano Previdi（シスコシステムズ）、Peter Psenak（シスコシステムズ）、Paul Mabbey（Comcast Cable）
MPLS LSR（Label Switch Router） -TEメッシュメンバーシップ用のルーティング拡張の仕様がRFC 4972として勧告された。
いくつかのLSR（Label Switch Router）内にあるMPLS TEやLSPのフルメッシュのセットアップは、帯域幅の最適化や帯域幅の保証、MPLS高速経路再選択のためのMPLSトラフィックエンジニアリングのよくある普及シナリオである。こうした普及過程では、潜在的に多数の（LSR数の二乗に比例する）TE LSPの構成を必要とする。
RFC 4972はIS-IS（Intermediate System-to-Intermediate System）およびOSPF用にIGP（Interior Gateway Protocol）ルーティングの拡張仕様を定義して、TE LSPの自動作成ができるようにメッシュ内のLSRメンバーの全体を自動的に発見できるようにする。
Acee Lindem（編集担当、レッドバックネットワークス）、Naiming Shen（シスコシステムズ）、Jean-Philippe Vasseur（シスコシステムズ）、Rahul Aggarwal（ジュニパーネットワークス）、Scott Shaffer（BridgePort Networks）
ルーター性能告知オプション用のOSPF拡張仕様がRFC 4970として勧告された。
OEPFv2やOEPFv3のルーティングドメインで、あるルーターが、近隣ルーターや他のルーティングドメインにあるルーターの性能がわかったら便利である。RFC 4970が提案しているのはルーター性能告知オプション用のOEPFv2およびOEPFv3用の拡張仕様である。この目的のため、新しいRI（Router Information）であるLSA（Link State Advertisement）が提案されている。OSPFv2では、RI LSAは新しい非透過型LSAタイプIDとして実装され、OSPFv3ではRI LSAは新しいLSAタイプファンクションコードとして実装される。どちらのプロトコルでも、RI LSAはリンク、エリア、ASなどの定義されたフラッディング範囲内に告知できる。
Robert Finking（シーメンス／ロケ・マナー・リサーチ）、Ghyslain Pelletier（エリクソン）
Ghyslain Pelletier（エリクソン）、Kristofer Sandlund（エリクソン）、Lars-Erik Jonsson（エリクソン）、Mark A West（シーメンス／ロケ・マナー・リサーチ）
ROHC-TCP（ROHC:A Profile for TCP/IP）の仕様がRFC 4996として勧告された。
RFC 4996はTCP/IPパケット圧縮用のROHCプロファイルの仕様を定義している。このプロファイルはROHC-TCPと呼ばれており、TCPヘッダーの効率的で頑強な圧縮を実現する。圧縮対象には、SACK（Selective Acknowledgments）やタイムスタンプのようなよく使われるTCPのオプションも含まれる。
多くの帯域が制限されたリンクは一般的に高エラーレートや長RTT（Round-Trip Time）という特徴がある。ROHC-TCPは、。ヘッダー圧縮が不可欠な狭い帯域で高エラーレートかつ長RTTのリンク上で威力を発揮する。
Lars-Erik Jonsson（エリクソン）、Ghyslain Pelletier（エリクソン）、Kristofer Sandlund（エリクソン）
ROHC（RObust Header Compression）フレームワークの仕様がRFC 4995として勧告された。
ROHCプロトコルは効率的で柔軟で将来にわたって利用できるヘッダー圧縮コンセプトを実現しており、さまざまな特性を持つさまざまなリンク技術上で効率的かつ頑強に運用できるように設計されている。
ROHCフレームワークは初めRFC 3095で定義された。一連の圧縮プロファイルとともに成り立っており、ROHCを改善し、シンプルな仕様にするために、RFC 4995はROHCフレームワークと非圧縮プロファイルを別に明確に定義している。さらに詳しくいえば、ROHCフレームワークはRFC 3095で定義された仕様を変更したり、更新したりしていない。
Brian Rosen（NeuStar）
SIP URI（Session Initiation Protocol Uniform Resource Identifier）用のダイヤル文字列パラメーターの仕様がRFC 4967として勧告された。
RFC 3966ははっきりと「tel」URIがダイヤル文字列ではないと述べており、ダイヤル文字列を指定する標準は存在しない。しかし、特にSIP URIパラメーターが「user=phone」 である場合、大きな誤解が生じている。そこでRFC 4967はユーザーパラメーターとして「dialstring」という新しいパラメーター用の値を用意し、「user=dialstring」 を指定して、SIPまたはSIPS URIとしてダイヤル文字列を符号化できるようにしている。
Robert Siemborski（グーグル）、Abhijit Menon-Sen（Oryx Mail Systems）
POP3（Post Office Protocol）SASL（Simple Authentication and Security Layer）認証メカニズムの仕様がRFC 5034として勧告された。
RFC 5034はPOP3用のSASLプロファイルを定義している。この拡張により、POP3クライアントがサーバーに対して認証メカニズムを指定したり、認証プロトコルをやりとりしたり、オプションとしてセッション中に下位プロトコルが用いるセキュリティ層をクライアント／サーバーで決定したりできるようになる。
RFC 5034はPOP3認証に関する情報を1つの文書にとりまとめようとしている。RFC 5034によってRFC 1734は置き換えられ、廃止される。また、RFC 2449の6.3節を更新する情報も含まれている。
Kevin Gibbons（2Wire）、G.D. Ramkumar（SnapTell）、Scott Kipp（Brocade）
Robert Siemborski（グーグル）、Alexey Melnikov（Isode Limited）
Marcelo Bagnulo（カルロス三世大学）、Jari Arkko（エリクソン）
Adrian Farrel（編集担当、Old Dog Consulting）、Arun Satyanarayana（シスコシステムズ）、岩田淳（NEC）、藤田範人（NEC）
MPLS（Multiprotocol Label Switching）およびGMPLS（Generalized MPLS） RSVP-TE用のクランクバックシグナリング拡張仕様がRFC 4920として勧告された。
経路情報が集中管理されておらず、コストなどの制約条件を満たすように経路を選択する環境では、経路を算出するための情報が期限切れになることがある。したがって、MPLSおよびGMPLS TEのLSP（Label Switched Path）セットアップ要求は、十分な帯域幅などを確保できずにリンクやノードによって遮断される可能性がある。
ATMで使われているクラックバックは、帯域幅などのリソースを確保できなかった箇所からセットアップの失敗情報を返すことで、リソース不足になる箇所を避けながら新たにセットアップ要求をやり直すためのスキームである。クラックバックはLSPの回復にも応用可能であり、エラーの起きるリンクやノードの箇所が判明する。
RFC 4920は「RSVP-TE: LSPトンネル用のRSVP拡張」（RFC 3209）として定義されているRSVP-TEと「GMPLSシグナリング機能の説明」（RFC 3473）として定義されているGMPLSシグナリングを用いて、MPLSシグナリングでクラックバックシグナリング拡張の仕様を定義している。拡張仕様によって、LSPのセットアップ要求はエラーのあったリンクやノードを迂回する別の経路を使うようにやり直せる。
この方式によって、LSPのセットアップの成功と回復の比率は、特に同時に大量のセットアップ要求が送信された場合に大幅に改善される。
Lior Khermosh（PMC-SIERRA）
Matt Squire（Hatteras Networks）
Ethernet的インターフェイス上のOAM（Operations, Administration, and Maintenance）機能用の管理オブジェクトの定義についての文書がRFC 4878として勧告された。
RFC 4878はEthernet規格のEFM（Ethernet in the First Mile）条項で定義されているEthernetのOAM機能に適合するEthernet的インターフェイスに関するOAM用の管理オブジェクトを定義している。
Ethernet OAM機能は、Ethernetインターフェイスに直接接続されたリンク固有の最小限の機能に絞って、SNMP（Simple Network Management Protocol）を補う。RFC 4878は、リンクのOAM機能を制御したり、管理エンティティに対してOAM機能の結果や状態を提供したりするための管理オブジェクトを定義している。
Lisa Dusseault（編集担当、CommerceNet）
Peter Psenak（シスコシステムズ）、Sina Mirtorabi（Force10 Networks）、Abhay Roy（シスコシステムズ）、Liem Nguyen（シスコシステムズ）、Padma Pillay-Esnault（シスコシステムズ）
Venkateshwara Sastry（サムスンエレクトロニクス）、Kent Leung（シスコシステムズ）Alpesh Patel（シスコシステムズ）
John Elwell（シーメンス・エンタープライズ・コミュニケーションズ）
SIP（Session Initiation Protocol）における接続IDに関する文書がRFC 4916として勧告された。
RFC 4916は対話要求を受け取ったSIP UA（User Agent）が、対話相手のUAに要求メッセージを送り返すことによってID情報を送信したり、認証サービスによってID情報に署名する手段を実現する。要求URIを換えて対話要求メッセージを送り返すことになるため、送り返された要求メッセージを受け取ったUA（UAS：User Agent Server）は、対話要求を送信したときのSIPのTo:ヘッダーフィールドとは異なるID情報を持つこともある。ゲートウェイ側にあるPSTN（Public Switched Telephone Network：公衆回線網）による処理などよる対話中のID情報の変更にも同じメカニズムが利用できる。RFC 4916によってRFC 3261は更新される。
Jerry Ash（AT&T）、Andrew G. Malis（Verizon Communications）
MPLS（Multi-Protocol Label Switching）上のヘッダー圧縮用のプロトコル拡張に関する仕様がRFC 4901として勧告された。
RFC 4901はMPLSのラベル交換経路上にHC（Header-Compressed）パケットをMPLSでどのように転送するかについて述べている。HCはパケットヘッダーのオーバーヘッドを大幅に減らせる技術で、MPLSと併用することで、バンド幅の効率を高め、それぞれのルーターでHCを使った同時最大圧縮フロー数に関して、処理能力のスケーラビリティを向上させる。RFC 4901では、MPLSの疑似有線を使って、どのようにHCのデータと制御メッセージをMPLSラベル交換の入り口ルーターと出口ルーター間で伝送するのかについて定義している。
RFC 4901で定義されているのはたとえばVoIPに利用可能な既存のHCメカニズム用の仕様だが、将来のまだ定義されていないHCプロトコル用の拡張メカニズムについても述べられている。RFC 4901では、それぞれのHCプロトコルの操作は単一の疑似有線上で、まさしく単一の拠点間リンクであるかのように独立している。
Abigail Surtees（Roke Manor Research Siemens/Roke Manor Research）、Mark A. West（Roke Manor Research Siemens/Roke Manor Research）Adam Roach（Estacado Systems）
Vijay K. Gurbani（アルカテル・ルーセント ベル研究所）、Cullen Jennings（シスコシステムズ）
Gregory A. White、Gregory M. Vaudreuil（アルカテル・ルーセント）
Scott Hollenbeck（ベリサイン）
Scott Hollenbeck（ベリサイン）
Scott Hollenbeck（ベリサイン）
Matt Mathis（ピッツバーグ・スーパーコンピューターセンター）、John Heffner（ピッツバーグ・スーパーコンピューターセンター）、Rajiv Raghunarayan（シスコシステムズ）
Eric Allman（センドメール）、Jon Callas（PGP）、Mark Delany（Yahoo!）、Miles Libbey（Yahoo!）、Jim Fenton（シスコシステムズ）、Michael Thomas（シスコシステムズ）
DKIM（DomainKeys Identified Mail）署名の仕様がRFC 4871として勧告された。
DKIMは公開鍵と鍵サーバー技術を用いたドメインレベルのメール用認証フレームワークを定義しており、DKIMによってMTA（Mail Transfer Agent）やMUA（Mail User Agent）がメッセージの送信者や内容を確認できるようになる。DKIMの最終目的はあるメッセージの配信に関する責任が署名ドメインにあることを明確にすることであり、スパムメールによって蝕まれた現在のインターネットメールの機能を維持しつつ、メッセージへの署名者やメッセージ内容の改ざんを防ぐことである。また電子メールの改ざんを防止することは、インターネットメール全体のスパムやフィッシング対策につながる。
Markus Isomaki（ノキア）、Eva Leppanen（ノキア）
プレゼンス文書の内容操作用のXCAP（XML Configuration Access Protocol）の利用に関する文書がRFC 4827として勧告された。
RFC 4827はXCAPを使ってPIDF（Presence Information Data Format）ベースのプレゼンス文書の内容を操作する方法について述べている。SIP（Session Initiation Protocol）ベースのプレゼンスシステムにおいて、ESC（Event State Compositor）がXCAP方式のプレゼンス文書に対応しており、プレゼンス機能が把握するプレゼンスの全体の状態をXCAP方式のプレゼンス文書で構築する場合を想定している。
Jonathan Rosenberg（シスコシステムズ）
リソースリスト表記用のXML形式の仕様がRFC 4826として勧告された。
マルチメディア通信やプレゼンス、インスタントメッセージングシステムでは、ユーザーのグループに関連するサービスを表記するためのURIを定義するニーズがある。その一例として、ユーザーがリソースリストサービスを表すURIにSIP（Session Initiation Protocol）のSUBSCRIBEメッセージを送信し、サーバーが関連するグループに所属するユーザーの状態を取得し、送信者にその情報を提供するようなリソースリストサービスがある。
こうしたサービスの仕様を定義するため、RFC 4826は2つのXML文書を定義している。1つめは、サービスURIを含むXML文書で、関連するユーザーグループにアクセスするためのサービスの定義とサービスのアドレスが記述される。2つめは、1つめの文書から参照される、ユーザーリストを含むXML文書である。このユーザーリストは、他のアプリケーションやサービスからも使われることがある。どちらの文書もXCAP（XML Configuration Access Protocol）によって作成、管理される。
Jonathan Rosenberg（シスコシステムズ）
Quaizar Vohra（ジュニパーネットワークス）、Enke Chen（シスコシステムズ）
Rahul Aggarwal（ジュニパーネットワークス）、安川正祥（NTT）、Dimitri Papadimitriou（アルカテル）
P2MP（Point-to-Multipoint）型TE LSP（Label Switched Path）用RSVP-TE（Resource Reservation Protocol - Traffic Engineering）の拡張仕様がRFC 4875として勧告された。
RFC 4875はMPLS（Multi-Protocol Label Switching）およびGMPLS（Generalized MPLS）ネットワークにおいて、TEによるP2MP型のLSPを設定するためのRSVP-TEの拡張仕様について述べている。RFC 4875がプロトコル要素と手続きを述べてソリューションはRSVP-TEに依存しており、通信事業者側のコアネットワークでマルチキャストルーティングプロトコルが稼働している必要はない。
P2MP TE LSPは、IPマルチキャストのようなさまざまな応用が考えられる。ただし、こうした応用がP2MP TE LSPをどのように用いるのかの仕様は、RFC 4875の埒外である。
Jari Arkko（エリクソン研究所ノマディックラボ）、Christian Vogt（カールスルーエ大学テレマティクス研究所）、Wassim Haddad（エリクソン研究所）
Luca Martini（シスコシステムズ）、George Swallow（シスコシステムズ）
ワイルドカード疑似有線タイプの仕様がRFC 4863として勧告された。
疑似有線のシグナリングでは、PWタイプ（Pseudowire Type）が両端で同じである必要がある。しかし、ある種のアプリケーションでは、PWタイプの構成は一方の終端で情報を設定すれば済むのに対して、LDPベースのシグナリングの場合、それぞれのPW終端が単一方向のLSPの作成から始めなければならない。2つのLSPをそれぞれ別個に作成することから開始するには、相手のPWタイプを事前に知らないPW終端でもLSPの作成から始められるような方法が必要である。RFC 4863は、この条件を満たすワイルドカード疑似有線タイプについて定義している。
Lou Berger（LabN Consulting）、Igor Bryskin（ADVA Optical）、Dimitri Papadimitriou（アルカテル）、Adrian Farrel（Old Dog Consulting）
Jonathan P. Lang（Sonos）、Yakov Rekhter（ジュニパーネットワークス）、Dimitri Papadimitriou（アルカテル）
エンドトゥエンドGMPLS（Generalized Multi-Protocol Label Switching）回復機能に対応するためのRSVP-TE（Resource ReSerVation Protocol - Traffic Engineering）拡張仕様がRFC 4872として勧告された。
RFC 4872はGMPLSのRSVP-TEシグナリング用にプロトコル固有の手続きと拡張仕様を述べて、保護と拡張機能を実現するエンドトゥエンドのLSP（Label Switched Path）の保護に対応する。GMPLS回復機能の一般的な機能説明については、対になる文書であるRFC 4426で述べている。
Francois Le Faucheur（シスコシステムズ）、Bruce Davie（シスコシステムズ）、Pratik Bose（ロッキードマーチン）、Chris Christou（Booz Allen Hamilton）、Michael Davenport（Booz Allen Hamilton）
汎用RSVP（Resource ReSerVation Protocol）帯域予約の仕様がRFC 4860として勧告された。
RFC 3175が定義しているRSVPによる帯域予約により、DiffservネットワークではPHB（Per Hop Behavior）と呼ばれるパケット転送ポリシーに応じて、送信元から宛先までのリソースを予約できる。また、RFC 3175はDiffservネットワークにおいて、エンドトゥエンドのRSVP予約を、集約された帯域予約にさらにどのように集約するかについても定義している。
こうした複数の帯域予約の集約が、同じ送信元IPアドレスと宛先IPアドレス、PHB（単一でも複数でも）に対しても必要になる場合がある。しかし、RFC 3175は同一条件の場合の帯域予約の集約に対応していない。そこで、より柔軟なRSVPによる帯域予約の集約タイプを「汎用帯域予約集約」として定義し、同一条件の場合に対応するのがRFC 4860である。
こうした複数の汎用帯域予約集約は、送信元IPアドレスから宛先IPアドレスまでのPHB（単一でも複数でも）で確立できる。また、汎用帯域予約集約は、エンドトゥエンドのRSVP予約を集約する目的でも使える。RFC 4860はこうした汎用帯域予約集約の手続きについても定義しており、Diffservネットワークに接続されたエンドシステムが汎用帯域予約集約の仕組みを直接にも利用できる。
Scott G. Kelly（Aruba Networks）、Sheila Frankel（NIST）
IPsecにおけるHMAC-SHA-256、HMAC-SHA-384,、HMAC-SHA-512の使用に関する文書がRFC 4868として勧告された。
RFC 4868はIPsecのHMAC（Hashed Message Authentication Mode）でSHA-256、SHA-384、SHA-512を使うことについて述べている。3つのアルゴリズムはAH（Authentication Header）やESP（Encapsulating Security Payload）、IKE（Internet Key Exchange Protocol）、IKEv2およびIKE、IKEv2用のPRF（Pseudo-Random Function：疑似乱数関数）用に、データの送信元認証と完全性の確認に用いられる。
また、認証関連の変形版として、出力サイズの切り詰めについての仕様もHMAC-SHA-256-128、HMAC-SHA-384-192、HMAC-SHA-512-256として定められている。また、PRF用の変形版であるPRF-HMAC-SHA-256、PRF-HMAC-SHA-384、PRF-HMAC-SHA-512は長さを切り詰めない。
Kevin Lingle（シスコシステムズ）、Jean-Francois Mule（CableLabs）、Joon Maeng、Dave Walker
Paul Congdon（ヒューレットパッカード）、Mauricio Sanchez（ヒューレットパッカード）、Bernard Aboba（マイクロソフト）
RADIUSフィルタールール属性の仕様がRFC 4849として勧告された。
RFC 2865で定義されているRADIUSのFilter-Id属性では、NAS（Network Access Server）が目的のフィルターに事前に登録されている必要がある。しかし、どのフィルターに登録されているのかをサーバーオペレーターが知らない場合、フィルタールールを明確に指定できた方が便利である。そこでRFC 4849は、RADIUSによるNAS-Filter-Rule属性を定義している。NAS-Filter-Rule属性は、RFC 4005およびRFC 3588のIPFilterRule文法で定義されているDiameterのNAS-Filter-Rule AVP（Attribute Value Pair）に基づいている。
Ronald P. Bonica（ジュニパーネットワークス）、Der-Hwa Gan（コンサルタント）、Carlos Pignataro（シスコシステムズ）
ICMPのマルチパートメッセージへの対応がRFC 4884として勧告された。
RFC 4884はマルチパート運用に対応するように、特定のICMPメッセージを再定義している。マルチパートICMPメッセージは、従来のICMPメッセージが伝送できたすべての情報に加えて、アプリケーションが必要とする追加情報を伝送できる。
マルチパートメッセージは、ICMPの拡張構造によって対応する。拡張構造はICMPメッセージの最後に置かれ、拡張ヘッダと、1つ以上の拡張オブジェクトが続く。それぞれの拡張オブジェクトはオブジェクトヘッダーとオブジェクトペイロードを含み、すべてのオブジェクトヘッダーは共通のフォーマットを用いる。
RFC 4884は長さフィールドを指定することでICMPメッセージ形式を再定義している。拡張構造が追加可能な現行のすべてのICMPメッセージには、「オリジナルデータグラム」というフィールドがある。「オリジナルデータグラム」フィールドには、ICMPエラーメッセージを引き出すための、データグラムの開始位置が格納されている。「オリジナルデータグラム」フィールドの長さは可変だが、ICMPメッセージは長さを格納するためのフィールドがない。したがって、メッセージを構文解析するに、RFC 4884は「オリジナルデータグラム」フィールドの長さを、これまで予約されていた8ビット分に割り当てている。
提案された変更は、ICMP互換の要件を変えるため、この変更が実装の互換性に与える影響や、将来の実装に関する新しい要件についても議論されている。RFC 4884はRFC 792とRFC 4443を更新する。
Leslie L. Daigle（シスコシステムズ）
Edward Beili（Actelis Networks）
Dave Wysochanski
iSCSI（Internet Small Computer Systems Interface）ノードアーキテクチャ用の共用拡張の仕様がRFC 4850として勧告された。
RFC 3720で定義されているiSCSIは、私用または共用の拡張キーの形式でプロトコルで拡張項目を使えるようにしている。RFC 4850はiSCSIの対応を拡張するために共用の拡張キーについて述べている。iSCSIノードがiSCSIログインシーケンス中にアークテクチャの詳細をやりとりできるようにすることで、この目的を達成する。受信側ノードはこの情報を拡張ログの対応に使う。RFC 4850はRFC 3720を改訂し、iSCSIの拡張項目が標準化過程または実験仕様のRFCとして定義できるようにする。
Russell Housley（Vigil Security）
Eliot Lear（シスコシステムズ）、Paul Eggert（UCLAコンピュータサイエンス学部）
Joe Salowey（シスコシステムズ）、Ralph Droms（シスコシステムズ）
Vishwas Manral（IP Infusion）
ESP（Encapsulating Security Payload）およびAH（Authentication Header）用の暗号アルゴリズム実装要件の仕様がRFC 4835として勧告された。
IPsecと総称されるプロトコル群は、セキュリティサービスを実現するためにさまざまな暗号アルゴリズムを利用している。ESPとAHという2つのメカニズムが、IPsecのSA（Security Association）上のデータ送信を保護する目的で使われているが、異なる実装間の相互運用性を確保するには、必須となるアルゴリズムの仕様を定めて、少なくとも1つのアルゴリズムはすべての実装で利用可能になるようにしなければならない。
そこでRFC 4835では、現行のESPとAH用に実装が必須のアルゴリズムを定めるとともに、将来必須となるべきアルゴリズムの仕様も定めている。
Andrew G. Malis（Verizon Communications）、Prayson Pate（Overture Networks）、Ron Cohen（編集担当、Resolute Networks）、David Zelig（Corrigent Systems）
Vijay Devarapalli（Azaire Networks）、Francis Dupont（CELAR）
Cheng-Yin Lee、Adrian Farrel（Old Dog Consulting）、Stefaan De Cnodder（アルカテル・ルーセント）
排他的経路に関するRSVP-TEの拡張仕様がRFC 4874として勧告された。
RFC 4874はRSVP-TEの経路セットアップ時に経路の排他利用についてやりとりするための仕様を定めている。
RSVP-TEの仕様である「RSVP-TE：LSP用のRSVP拡張」（RFC 3209）およびGMPLSの拡張仕様である「GMPLSシグナリングRSVP-TE拡張」（RFC 3473）は、抽象ノードおよびリソースが経路セットアップに含まれるべきであると明示しているが、排除してはならないとは明示していない。
ゲートウェイ装置などによって正確な明示的経路が算出されていないネットワークでは、経路から抽象ノードおよびリソースを除外されるべきであることを示せた方が有用である。経路からの除外は、すべての経路に及ぶこともあるし、明示的経路を定めた2つの抽象ノード間で部分的に適用されることもある。RFC 4874は、SRLG（Shared Risk Link Group：リスク共有リンクグループ）をどのように除外するかについても述べている。
Johan Sjoberg（エリクソン）、Magnus Westerlund（エリクソン研究所）、Ari Lakaniemi（ノキア研究センター）、Qiaobing Xie（モトローラ）
AMRおよびAMR-WB音声コーデックのRTPペイロード形式およびファイル保存形式の仕様がRFC 4867として勧告された。
RFC 4867はAMR（Adaptive Multi-Rate）およびAMR-WB（Adaptive Multi-Rate Wideband）でエンコードされた音声信号用のRTPペイロード形式の仕様を定めている。ペイロード形式は既存の非IPネットワーク上のAMRおよびAMR-WB伝送形式とも相互に利用できるように設計されている。また、電子メールのような保存モードアプリケーションでAMRおよびAMR-WB音声データを伝送するためのファイル形式の仕様も定められている。
また、RFC 4867には、RTPペイロード形式およびファイル保存形式を使った、AMRとAMR-WB用の2つの別々のメディアタイプが含まれている。RFC 4867によってRFC 3267は更新される。
Matt Mathis（ピッツバーグスーパーコンピューティングセンター）、John W. Heffner（ピッツバーグスーパーコンピューティングセンター）
Michael Tuexen（ミュンスター大学応用科学学部）、Randall R. Stewart（シスコシステムズ）、Peter Lei（シスコシステムズ）
W. Mark Townsley（シスコシステムズ）、Carlos Pignataro（シスコシステムズ）、Scott Wainner（シスコシステムズ）、Ted Seely（Sprint Nextel）、Jeff Young
Chris Newman（サンマイクロシステムズ）、Martin Duerst（青山学院大学）、Arnt Gulbrandsen（Oryx Mail Systems）
Cyrus Daboo（アップル）、Bernard Desruisseaux（オラクル）、Lisa Dusseault（CommerceNet）
Joseph Galbraith（VanDyke Software）、Jeff P. Van Dyke（VanDyke Software）、Jon Bright（Silicon Circus）
SSH（Secure Shell）公開鍵サブシステムの仕様RFC 4819として勧告された。
SSHは公開鍵ベースのユーザー認証メカニズムを定義している。しかし、鍵配布のメカニズムは何も定義されておらず、現在、それぞれの実装で共通して利用できる鍵管理ソリューションは存在しない。そこでRFC 4819は、クライアントソフトウェアが公開鍵の構成を担当する、実装に依存しない公開鍵の構成用プロトコルについて述べている。
公開鍵サブシステムは、公開鍵の追加や削除、サーバ側にとってある公開鍵のリストを、サーバとは独立してクライアントが処理できるメカニズムを実現する。また公開鍵は、SSHの必須コマンドやサブシステムを含む、さまざまな制約とも関連付けられる。
Orly Nicklass, Editor（RAD Data Communications）
DS1、J1、E1、DS2、E2インターフェイス型用管理オブジェクトの定義に関する文書がRFC 4805として勧告された。ネットワーク管理用のプロトコルとともにMIBの一部として使われる。
RFC 4805はDS1、J1、E1、DS2、E2インターフェイス型用管理オブジェクトについて述べている。RFC 4805は、DS0、DS3/E3、SONET/SDH（Synchronous Optical Network/Synchronous Digital Hierarchy）インターフェイス型用管理オブジェクトについて述べているRFC 2494、RFC 3896、RFC 3592の姉妹版であり、DS1、J1、E1、DS2、E2インターフェイス型用管理オブジェクトについて述べているRFC 3895は廃止される。
Michael Baer（Sparta）、Ricky Charlet（自営）、Wes Hardaker（Sparta）、Robert Story（Revelstone Software）、Cliff Wang（ARO）
IPsecセキュリティポリシーデータベース構成MIBの仕様がRFC 4807として勧告された。
RFC 4807はSMIv2（Structure of Management Information Version 2）のMIB（Management Information Base）モジュールを定めて、IPsecを実装する装置のセキュリティポリシーデータベースを構成できるようにする。ただし、RFC 4807で述べているポリシーベースのパケットフィルタリングや対応する処置は、ファイアウォールの構成など、IPsecの構成そのものよりもより一般的な性質がある。そのため、MIBモジュールは他の企業および標準準拠のパケットフィルタリングや対応処置でも利用可能なように拡張できるように設計されている。
R. Atkinson（エクストリームネットワークス）、M. Fanto（米国標準技術研究所）
RIPv2暗号認証の仕様がRFC 4822として勧告された。
RFC 4822は、元々RFC 2082で仕様が定められているRIPv2暗号認証メカニズムの改訂版について述べている。RFC 4822によってRFC 2082は廃止され、RFC 2453は更新される。RFC 2082では鍵付きMD5の利用だけが仕様になっているのに対して、RFC 4822ではSHA系のハッシュアルゴリズムがどのようにRIPv2の暗号認証で利用できるかについての詳細を書き加えている。また、RFC 4822はこのメカニズムに対する能動的攻撃の潜在的問題についても明らかにし、安全上の考慮についての項目で、かなりの紙幅をさいている。
Thomas D. Nadeau（シスコシステムズ）、Adrian Farrel（Old Dog Consulting）、Cheenu Srinivasan（Bloomberg）、Tim Hall（Data Connection）、Ed Harrison（Data Connection）
Thomas D. Nadeau（シスコシステムズ）、Cheenu Srinivasan（Bloomberg）、Adrian Farrel（Old Dog Consulting）、Tim Hall（Data Connection）、Ed Harrison（Data Connection）
Thomas D. Nadeau（シスコシステムズ）、Adrian Farrel（Old Dog Consulting）、Cheenu Srinivasan（Bloomberg）、Tim Hall（Data Connection）、Ed Harrison（Data Connection）
Stephen L. Casner（Packet Design）
Stephen L. Casner（Packet Design）
Michael Myers（TraceRoute Security）、Hannes Tschofenig（シーメンスネットワークス）
IKEv2（Internet Key Exchange Protocol version 2）用のOCSP（Online Certificate Status Protocol）拡張の仕様がRFC 4806として勧告された。
IKEv2は公開鍵ベースの認証に対応しているが、IKEv2の通信でCRL（Certificate Revocation List：証明書失効リスト）を取得して証明書の有効性を確認するのは、CRLのサイズに上限がないため、大量のリストを取得せざるを得ない場合があり、問題の多い方法である。
一方、OSCP（Online Certificate Status Protocol）の応答には上限があり、サイズも小さい。そこでRFC 4806はIKEv2を拡張し、「OCSP Content」を定義する。具体的には、「OCSP Content」を伴うCERTREQ（証明書要求）ペイロードを送信することで、信頼されたOCSPの応答側を指定し、IKEv2のハンドシェイク時にOCSP応答を含めるように要求する。OCSP拡張に対応する応答側がこの要求を受け取ると、適切なOCSP応答を含むCERT（証明書）ペイロードを応答する。この内容は、「OCSP Content」識別子によって、どの要求に対応するのかを認識できる。IKEv2で証明書が使われるとき、通信相手は一方の証明書の無効状態を判断するメカニズムが必要になるが、OCSPはこうしたメカニズムの1つである。
RFC 4806は、OCSPが必要だが、セキュリティポリシーのせいでIKEv2の通信相手が関係するOCSPの応答側に直接アクセスできない場合に適用される。ファイアウォールによって、企業ネットワークの外にあるIKEv2の通信相手がそうしたアクセスができなくなることはよくあることだ。
Michael DiBiasio（シスコシステムズ）、Bruce Davie（シスコシステムズ）、Christou Christou（Booz Allen Hamilton）、Michael Davenport（Booz Allen Hamilton）、Jerry Ash（AT&T）、Bur Goode（AT&T）、Francois Le Faucheur（編集担当、シスコシステムズ）
MPLS TE（Traffic Engineering）/DS-TE（Diffserv-aware MPLS
Traffic Engineering）トンネル上のRSVP（Resource ReSerVation Protocol）予約に関する仕様がRFC 4804として勧告された。
RFC 3175は集合RSVP予約上のRSVPのエンドトゥエンド予約を集約する仕様を定めている。RFC 4804は、MPLS TEトンネルまたはDS-TEトンネル上のRSVPエンドトゥエンド予約を集約する仕様を定めている。このアプローチは、RFC 3175に基づいており、RSVP予約を集約する代わりにMPLS TEトンネル上の対応する手続きを単に変更している。コアネットワーク内の装置数はエンドトゥエンドのRSVP予約に関係せず、MPLS TEトンネルだけが関わるため、非常にたくさんのフローをスケーラビリティを保ちつつ管理制御するために利用できる。
Andrew G. Malis（ベライゾン・コミュニケーションズ）、Luca Martini（シスコシステムズ）、Jeremy Brayley（Omega Corporate Center, ECI Telecom）、Tom Walsh（ジュニパーネットワークス）
Lars-Erik Jonsson、Kristofer Sandlund（エリクソン）、Ghyslain Pelletier（エリクソン）、Peter Kremer（エリクソン・ハンガリー 適合性ソフトウェアテスト研究所）
ROHC（RObust Header Compression：頑強なヘッダー圧縮）について述べているRFC 3095の訂正と解説に関する文書がRFC 4815として勧告された。
RFC 3095はROHCの枠組みとIP（Internet Protocol）やUDP（User Datagram Protocol）、RTP（Real-Time Transport Protocol）、ESP（Encapsulating Security Payload）用のプロファイルを定義している。しかし、仕様のある部分は不明確な点あるいは間違いを含んでおり、異なる実装同士の相互接続を妨げるような誤った実装を引き起こしかねない。そこでRFC 4815はRFC 3095の訂正と追加、解説情報を提供し、RFC 3095の内容を更新する。加えて、ROHC over PPP（RFC 3241）、ROHC IP profile（RFC 3843）、ROHC UDP-Lite profiles（RFC 4109）の解説もされている。
Henning Schulzrinne（コロンビア大学コンピュータサイエンス学部）、Hannes Tschofenig（シーメンスネットワークス）、John B. Morris, Jr.（Center for Democracy and Technology）、Jorge R. Cuellar（シーメンス）、James Polk（シスコシステムズ）、Jonathan Rosenberg（シスコシステムズ）
Jani Hautakorpi（エリクソン）、Gonzalo Camarillo（エリクソン）
Jeremy De Clercq（アルカテル・ルーセント）、Dirk Ooms（OneSparrow）、Stuart Prevost（BT）、Francois Le Faucheur（シスコシステムズ）
6PE（Provider Edge Router）によるIPv4 MPLS（Multiprotocol Label Switching）上のIPv6ネットワークの接続の仕様がRFC 4798として勧告された。
RFC 4798は、MPLS上のIPv4ネットワークにあるIPv6ネットワークをどのように相互接続するのかについて述べている。この方法は、個々のIPv6ネットワークをIPv4 MPLSを動作させるためだけに必要なMPLSコアに接続するためのデュアルスタック構成を持つ6PEに依拠する。6PEルーターはMP-BGP（Multiprotocol Border Gateway Protocol） over IPv4を用いるコア上で透過的にIPv6の到達性情報を交換する。このようにすることで、動的に確立されたIPv4でシグナルを受けたMPLSのLSP（Label Switched Path）が明確なトンネルの構成をせずに使えるように、BGPのNext Hopフィールドは6PEルーターのIPv4アドレスを伝送するために使われる。
Charles E. Perkins（ノキア研究センター）、Pat R. Calhoun（シスコシステムズ）、Jayshree Bharatia（ノーテルネットワークス）
モバイルIPv4のチャレンジ／レスポンス拡張（改訂）の仕様がRFC 4721として勧告された。
モバイルIPは元々の仕様で、移動ノードが外部エージェントに対して自身を認証する認証拡張の仕様（移動－外部認証拡張）を定めている。しかし、この拡張は外部エージェントに対して再送信攻撃からプロトコルが保護されているという直接の保証を与えておらず、携帯コンピュータ機器にCHAP（Challenge
Handshake Authentication Protocol）など、既存のテクニックの利用も認めていない。
そこでRFC 4721は、モバイルIPエージェントの広告メッセージおよび登録要求メッセージを拡張して、外部エージェントがCHAPを使って移動ノードを認証できるようにしている。
さらに、RFC4721はRFC 3344を拡張し、モバイルAAA（Authentication, Authorization, and Accounting）認証拡張を導入した。この新しい拡張は、一般に利用可能なAAA基盤の要素技術を用いて、移動ノードが信用情報を提供できるように用意された。また、認証を可能にした拡張はRFC 3344で定義された登録要求の拡張仕様と共存できる。
RFC 4721によって、RFC 3012は廃止される。
Joerg Ott（ヘルシンキ工科大学ネットワーク研究所）、Carsten Bormann（Universitaet Bremen TZI）、Gary Sullivan（マイクロソフト）、Stephan Wenger（ノキア研究センター）、Roni Even（編集担当、Polycom）
ITU-T Rec. H.263ビデオ用のRTP（Real-time Transport Protocol）ペイロード形式の仕様がRFC 4629として勧告された。
RFC 4629は、H.263ビデオストリームをパケット化して、RTPで伝送するためのスキームについて述べている。RTPを伝送する下位プロトコルは問わない。また、RFC 4629はH.263ビデオコーデックに対応するために必要なSDP（Session Description Protocol）パラメーターの文法および意味についても述べている。
RFC 4629によって、RFC 2429は廃止される。また、RFC 3555で述べているH263-1998およびH263-2000のMIMEメディアタイプの定義は更新される。
Uri Blumenthal（インテル）、Purushottam Goel（インテル）
Dr. Steven Legg（eB2Bcom）
Vesa Lehtovirta（エリクソン研究所）、Mats Naslund（エリクソン研究所）、Karl Norrman（エリクソン研究所）
SRTP（Secure Real-time Transport Protocol）用のROC（Roll-Over Counter）を伝送するインテグリティ・トランスフォームに関する仕様がRFC 4771として勧告された。
RFC 4771はSRTP（RFC 3711）用のインテグリティ・トランスフォームを定義し、認証タグの一部としてROCをSRTPで伝送できるようにしている。SRTPパケットによるROCの送信は、受信者が進行中のSRTPセッションに加わり、迅速かつ頑強に同期する必要がある状況で求められる。また、このメカニズムは送信者と受信者の同期がとれなくなる可能性がある場合のSRTPの運用を拡張する。
David E. Fu（米国国家安全保障局国家情報保証研究所）、Jerome A. Solinas（米国国家安全保障局国家情報保証研究所）
ECDSA（Elliptic Curve Digital Signature Algorithm：楕円デジタル署名アルゴリズム）を使ったIKE（Internet Key Exchange）およびIKEv2（Internet Key Exchange version 2）認証の仕様がRFC 4754として勧告された。
RFC 4754はIKEおよびIKEv2においてECDSAがどのように認証方法として使われるのかについて述べている。ECDSAには計算の効率性や短い署名サイズ、他の署名方式に比べた場合により少ない帯域幅でも利用可能などの長所がある。RFC 4754は、既存のIKEの運用に何らの変更を加えることなく、IKEおよびIKEv2においてECDSAを利用できるようにする。
Yakov Rekhter（ジュニパーネットワークス）、Rahul Aggarwal（ジュニパーネットワークス）
MPLSを用いるBGPの段階的再起動の仕様がRFC 4781として勧告された。
BGPの再起動によるルーティングへの悪影響をなるべく少なくするBGP用のメカニズムはすでに開発されており、「BGPの段階的再起動」（RFC 4724）で説明されている。RFC 4781はこのメカニズムを拡張し、LSR（Label Switching Router：ラベル交換ルーター）の制御プレーンの再起動、BGPがMPLSラベルを伝送するために使われており、再起動時にLSRがMPLSの転送状態を保存できる場合に、BGPの再起動によるMPLS転送への悪影響をなるべく少なくする。
なお、このメカニズムはBGPのNLRI（Network Layer Reachability Information）フィールド中のアドレス型には関知しない。したがってこのメカニズムはIPv4やIPv6のようなBGPで伝送できる一連のアドレスとともに使う場合に有効である。
Marc Lasserre（アルカテル・ルーセント）、Vach Kompella（アルカテル・ルーセント）
LDP（Label Distribution Protocol：ラベル配布プロトコル）シグナリングを用いたVPLS（Virtual Private LAN Service：仮想専用LANサービス）の仕様がRFC 4762として勧告された。
RFC 4762は疑似有線（pseudowires：PW）やTLS（Transparent LAN Service）として知られる他のトンネリング技術上に実装された従来のサービスを用いたVPLSソリューションについて述べている。VPLSが構築するのはエミュレートされたLANセグメントである。たとえば設定されたユーザーだけが使えるレイヤー2のブロードキャストドメイン（EthernetのMACアドレスを学習したり転送できる）を構築できる。また、PE（Provider Edge）ノードと呼ばれる通信事業者側の１か所の接続点から、複数のVPLSサービスを利用できる。
RFC 4762はRFC 4447を拡張し、LDPを用いて疑似有線ラベルをシグナリングする制御プレーン機能について述べている。発見プロトコルは問わない。また、伝送に関するデータプレーン機能についても述べているが、MACアドレスの学習に特に絞って述べている。VPLSパケットのカプセル化についてはRFC 4448で述べられている。
Srihari R. Sangli（シスコシステムズ）、Yakov Rekhter（ジュニパーネットワークス）、Rex Fernando（ジュニパーネットワークス）、John G. Scudder（ジュニパーネットワークス）、Enke Chen（シスコシステムズ）
BGPの段階的再起動の仕様がRFC 4724として勧告された。
RFC 4724は、BGPの再起動によって起きるルーティングへの悪影響をなるべく減らすのに役立つBGP用のメカニズムについて述べている。End-of-RIBマーカーの仕様を定めて、ルーティングの収束情報を伝達するために用いる。また、「段階的再起動」と呼ばれる新しいBGPの機能を定義し、BGPスピーカーが、BGP再起動時に転送状態を保存できることを表明できるようにしている。また、TCPセッションの切断と再確立があっても、ルーティング情報を一時的に保つための手続きの概要も示されている。
RFC 4724で述べられているメカニズムはすべてのルーターで利用可能である。BGP再起動時に転送状態を保存する機能があるかないかは問わない（もちろん、RFC 4724で述べられている機能を部分的に実装する必要はある）。
Kireeti Kompella（ジュニパーネットワークス）、Yakov Rekhter（ジュニパーネットワークス）
自動検出およびシグナリング用のBGPを用いたVPLS（Virtual Private LAN Service）の仕様がRFC 4761として勧告された。
透過型LANサービスや仮想専用交換ネットワークサービスとしても知られるVPLSは、通信事業者にとって利便性が高い。VPLSが提供するのはレイヤー2VPNだが、レイヤー2のVPNは拠点間で接続されるのに対して、VPLSのユーザーは複数の拠点間をEthernet LANで接続される。
RFC 4761は、VPLSを提供するために必要な機能やVPLSをシグナリングするためのメカニズム、パケット交換ネットワークでVPLSフレームを転送するためのルールについて述べている。
Tony Bates（シスコシステムズ）、Ravi Chandra（Sonoa Systems）、Dave Katz（ジュニパーネットワークス）、Yakov Rekhter（ジュニパーネットワークス）
Qiaobing Xie（クアルコム）、Rohit Kapoor（クアルコム）
EVRC（Enhanced Variable Rate Codec）ファミリーコーデック用のRTPペイロード形式の拡張仕様がRFC 4788として勧告された。
RFC 4788はRFC 3558で定義されたEVRC RTPペイロード形式をいくつかの点で強化し、拡張する。特に、RFC 4788はヘッダーの省略やEVRCコーデック用のインターリーブ／バンドルパケット形式、EVRCおよびEVRC-Bコーデックの新しいコンパクトなバンドル形式に対応する。また、EVRCおよびEVRC-Bで符号化されたRTPによる音声伝送用のDTX（Discontinuous Transmission）にも対応する。狭帯域幅のダイヤルアップまたは無線ネットワーク上のVoIPアプリケーションの運用は、帯域幅を有効に利用するためにこうした拡張が必須である。
Cullen Jennings（シスコシステムズ）、Julian F. Reschke（編集担当、greenbytes GmbH）
Eugene Nechamkin（Broadcom）、Jean-Francois Mule（Cable Television Laboratories）
Richard Woundy（Comcast Cable）、Kevin Marez（モトローラ）
DOCSIS（Cable Device Management Information Base for Data-Over-Cable Service Interface Specification）互換のケーブルモデムとケーブルモデム終端システムMIBの仕様がRFC 4639として勧告された。インターネットにおけるネットワーク管理のためにMIBの一部として利用される。
RFC 4639はDOCSIS互換のケーブルモデムおよびケーブルモデム終端システムのSNMP（Simple Network Management Protocol）ベースの管理オブジェクトを定義している。RFC 4639によってRFC 2669は廃止される。
Luca Martini（シスコシステムズ）、Jayakumar Jayakumar（シスコシステムズ）、Matthew Bocci（アルカテル）、Nasser El-Aawar（Level 3 Communications）、Jeremy Brayley（ECI Telecom）、Ghassem Koleyni（ノーテルネットワークス）
Eliot Lear（シスコシステムズ）、Ken Crozier
Ted Goddard（ICEsoft Technologies）
NETCONF over SOAP（NETCONF over the Simple Object Access Protocol）の仕様がRFC 4743として勧告された。
NETCONFはさまざまな環境の幅広い機器で利用できる。Webサービスもそうした環境の1つであり、今のところはSOAPと併用することで多くのメリットがもたらされる。つまり、SOAPという既存という標準技術を再利用することで、ソフトウェア開発が容易になり、運用中のシステムとも統合しやすくなる。RFC 4743では、SOAP over HTTPおよびSOAP over BEEPとNETCONFを組み合わせる方式について述べている。
Margaret Wasserman（ThingMagic）、Ted Goddard（ICEsoft Technologies）
Henning Schulzrinne（コロンビア大学コンピュータサイエンス学部）、Tom Taylor（ノーテル）
Henning Schulzrinne（コロンビア大学コンピュータサイエンス学部）、Tom Taylor（ノーテル）
DTMF（Dual-Tone Multi Frequency）ディジット、通話トーン、通話シグナル用のRTPペイロード形式の仕様がRFC 4733として勧告された。
RFC 4733はDTMFシグナリング、他のトーンシグナル、通話イベントをRTPパケットでどのように伝送するかについて述べている。
RFC 4733はRFC 2833で定義されている基本的なフレームワークを元に拡張しているが、もっとも基本的なイベントコードしか互換性を維持しておらず、他のイベントコード割り当てが追加できるようにIANA割り当てを用意している。モデム、FAX、テキスト通話、チャンネル関連のシグナリングイベントに関する登録はRFC 4734でイベントコードが追加される。RFC 2833で定義されている残りのコードは、他の文書で再び利用するまで、条件付きで予約される。
RFC 4733は、オリジナル文書であるRFC 2833をより明確にした点がいくつもある。ただし、すべての互換実装はDTMFイベントに対応すべきであるとした要件を削除した点は特に異なっており、その代わりに互換実装は対応するイベントを示すメディアストリームコンテントのネゴシエーションを別に利用する。また、RFC 4733はRFC 2833のフレームワークに、長いイベントのセグメント分割、単一パケットへの複数イベントのレポート、状態イベントの概念とレポートという3つの新しい手続きを追加している。
Dan Joyal（編集担当、ノーテル）、Piotr Galecki（編集担当、Airvana）、Spencer Giacalone（編集担当、CSFB）、Fred Baker（シスコシステムズ）、Rob Coltun（Touch Acoustra）
OSPFv2（Open Shortest Path First version 2） MIB（Management Information Base）の仕様がRFC 4750として勧告された。インターネットにおけるネットワーク管理用に、MIBの一部として使われる。
RFC 4750は、OSPFv2ルーティングプロトコルの管理オブジェクトを定義している。OSPFv2はIPv4アドレスに特化しており、IPv6アドレスに特化しているのはOSPFv3である。
なお、RFC 4750によってRFC 1850は廃止されるが、後方互換性は保たれている。また、RFC 4750とRFC 1850の機能的な違いは、Appendix Bで説明されている。
Richard Stastny（Oefeg）、Richard Shockey（Neustar）、Lawrence Conroy（Roke Manor Research, Roke Manor）
「tel」URI（Uniform Resource Identifier）用のENUM Dip指標パラメーターの仕様がRFC 4759として勧告された。
RFC 4759はVoIP（Voice over Internet Protocol）ネットワークのノードがENUM問い合わせの処理に対応するために、「tel」URI用の新しいパラメーターとして「enumdi」を定義している。VoIPネットワークのノードは、E.164番号を含む「enumdi」パラメーター付きのURIを受信することがある。このとき、「enumdi」パラメーターの存在は、E.164番号に関するENUM問い合わせが、直前のVoIPネットワークノードによってすでに処理されたことを示す。同様に、VoIPネットワークノードが「enumdi」パラメーター付きのURIを送信することは、E.164番号に関するENUM問い合わせが実行されたことを意味する。
Jason Livingood（Comcast Cable Communications）、Richard Shockey（NeuStar）
Bill Fenner（AT&T研究所）
Juergen Schoenwaelder（International University Bremen）、Tony Jeffree（コンサルタント）
Moti Morgenstern（ECI Telecom）、Menachem Dodge（ECI Telecom）、Scott Baillie（NECオーストラリア）、Umberto Bonollo（NECオーストラリア）
Adam H. Li（HyerVision）
Al Morton（AT&T研究所）、Len Ciavattone（AT&T研究所）、Gomathi Ramachandran（AT&T研究所）、Stanislav Shalunov（インターネット2）、Jerry Perser（Veriwave）
パケット再配置の指標に関する仕様がRFC 4737として勧告された。
RFC 4737は、ネットワークがパケットの順序を「パケット・バイ・パケット」の原則通りに維持しているかを評価するための指標を定義し、新しい指標の必要性を示して、あるパケットが全体構造のどのような部分に相当するのかを示す情報といった計測に関する諸問題について議論している。そこでRFC 4737は、まず再配置されたパケットの基準を定義し、ネットワークの性質や受信側の状態により、再配置が基準と比較してどの程度の大きさなのかを計測できるようにした。また、再配置の時間的頻度や再配置が量的頻度を計測する追加的な指標も定義している。
なお、RFC 4737の執筆者は再配置がTCPに及ぼす影響について評価するための指標も定義している。さまざまなサンプル指標を使った評価例が示されており、追補にはパケットの断片化を伴う順序を評価するための追加的な定義も収録されている。
Alexey Melnikov（Isode Limited）
Kerberos V5（GSS-API）のSASL（Simple Authentication and Security Layer）メカニズムの仕様がRFC 4752として勧告された。
SASLはコネクションベースのプロトコルに認証機能を追加するための枠組みである。RFC 4752はGSS-API（Generic Security Service Application Program Interface）を用いて、SASLにおいてKerberos V5を利用する方法について述べている。
なお、RFC 4752によって、GSS-APIのSASLメカニズムについて述べているRFC 2222のセクション7.2は置き換えられる。また、RFC 4752とRFC 4422によってRFC 2222は廃止される。
Scott Kipp（McDATA）、G D Ramkumar（SnapTell）、Keith McCloghrie（シスコシステムズ）
Miguel A. Garcia-Martin（編集担当、ノキア）、Maria-Carmen Belinchon（エリクソン）、Miguel A. Pallares-Lopez（エリクソン）、Carolina Canales-Valenzuela（エリクソン）、Kalle Tammi（ノキア）
Gonzalo Camarillo（エリクソン）
Gonzalo Camarillo（エリクソン）、Joerg Ott（ヘルシンキ工科大学電気通信工学部ネットワーク研究所）、Keith Drage（ルーセントテクノロジー）
BFCP（Binary Floor Control Protocol：バイナリ会場管理プロトコル）の仕様がRFC 4582として勧告された。
会場管理とは、いくつかのグループからなるカンファレンス環境において、共有リソースを同時にまたは排他的に利用するための管理方式のことである。つまり会場管理は、カンファレンスやメディアセッションの確立、カンファレンスポリシーの設定変更、メディア制御といった、他のプロトコルによって実現される諸機能を補うものである。
RFC 4582はBFCPの仕様を定めており、会場内の参加者クライアントと会場管理サーバー、会場責任者（モデレーター）と会場管理サーバーの間で使われる。
Henning Schulzrinne（コロンビア大学コンピュータサイエンス学部）
Dragan Ignjatic（Polycom）、Lakshminath Dondeti（QUALCOMM）、Francois Audet（ノーテル）、Ping Lin（ノーテル）
「MIKEY-RSA-R」と呼ばれるMIKEY（Multimedia Internet KEYing）における鍵配布の追加モードの仕様がRFC 4738として勧告された。
MIKEYの仕様は、事前共有鍵（PSK：Pre-Shared Key）と公開鍵、オプションとしてディフィ・ヘルマン方式の鍵交換を使ったマルチメディア通信、たとえばSIPによる呼（こ）とRTSP（Real Time Streaming Protocol）を組み合わせた場合に用いるいくつかの鍵配布モードについて述べている。
しかし、公開鍵モードにおいて、 発呼側はランダム鍵を着呼側の公開鍵で暗号化してから着呼側に送信するため、多くの通信シナリオでは、発呼側は着呼側の公開鍵、あるいは着呼側のID（呼の転送時など）を事前に知っている。RFC 4738で提案されているのは、こうした場合に適合するMIKEYの新しいモードである。
また、既存のグループ管理者がグループ鍵をすべてのメンバーに配布するのに対して、メンバー側の要求によって鍵をダウンロードできるようにして、MIKEYにおけるグループ鍵の管理の仕様も拡張している。なお、RFC 4738はRFC 3830で述べられているRSA-Rの仕様を更新する。
Andrew G. Malis（Tellabs）、David Allan（ノーテルネットワークス）、Nick Del Regno（MCI）
Pedro Marques（ジュニパーネットワークス）、Ronald Bonica（ジュニパーネットワークス）、Luyuan Fang（シスコシステムズ）、Luca Martini（シスコシステムズ）、Robert Raszuk（シスコシステムズ）、Keyur Patel（シスコシステムズ）、Jim Guichard（シスコシステムズ）
BGP/MPLS（Border Gateway Protocol/MultiProtocol Label Switching） IP（Internet Protcol） VPN（Virtual Private Network）用の制限付き経路配布の仕様がRFC 4684として勧告された。
RFC 4684は、MP-BGP（Multi-Protocol BGP）の手続きを定めて、BGPスピーカーが経路ターゲットの到達性情報をやりとりできるようにする。到達性情報は、経路配布グラフを構築して、VPNのLNRI（Network Layer Reachability Information）が異なるASやAS内の別のクラスターには伝わらないように制限することに利用できる。なお、RFC 4684によって、RFC 4364の内容は更新される。
Alexey Melnikov（Isode Limited）、Dave A. Cridland（Inventure Systems Limited）
Eric Burger（Cantata Technology）、Martin Dolly（AT&T研究所）
KPML（Key Press Stimulus）用のSIP（Session Initiation Protocol：セッション開始プロトコル）イベントパッケージの仕様がRFC 4730として勧告された。
RFC 4730は、SIPイベントパッケージの「KPML」について述べている。KPMLはKPMLと呼ばれるマークアップ言語を用いたXML（Extensible Markup Language）文書を用いて、DTMF（Dual Tone Multi-Frequency）を監視するための技術である。KPMLイベントパッケージを用いると、「A Framework for Application Interaction in the Session Initiation Protocol (SIP)」で定義された諸原則に合致したアプリケーションに対応できる。また、イベントパッケージではSIPのSUBSCRIBEメッセージを用いて、SIPユーザーエージェントの画面表示なしのユーザーインターフェイスで押されたキー（DTMFトーン）のキャプチャ用にフィルター仕様をXML文書で定義して記述できる。さらに、イベントパッケージはNOTIFYメッセージを用いて、キャプチャされたフィルター仕様に沿ったキーの押下（DTMFトーン）をアプリケーションサーバーに対してXML文書で報告できるようにする。このイベントパッケージの適用範囲は、補足的なキーの押下または通話の引き継ぎ機能を呼び出すようなキーの押下を収集することである。
Rahul Aggarwal（ジュピターネットワークス）、W. Mark Townsley（シスコシステムズ）、Maria Alice Dos（シスコシステムズ）