サービス名拡張用のインターネットX.509PKI（Public Key Infrastructure）所有者代替名の仕様がRFC 4985として勧告された。
　RFC 4985はX.509所有者代替名拡張に新しい名前を格納できるようにして、サービス名およびDNSのサービス資源レコードのドメイン名コンポーネントと証明書の所有者を関連付けられるようにする。

　DNSSECトラストアンカーロールオーバーに関する要件がRFC 4986として承認された。
　DNSセキュリティに対応するすべてのリゾルバーは、DNS署名ゾーンからの応答を検証するために、少なくとも1つのトラストアンカーを持たなければならない。また、さまざまな理由により、DNSセキュリティに対応したほとんどのリゾルバーは、複数のトラストアンカーを持つことになっている。
　運用形態によっては、トラストアンカーの手動による監視と更新も可能だが、多くの場合はDNSセキュリティに対応したリゾルバーによる自動化されたトラストアンカーの更新が必要である。そこでRFC 4986は、DNSセキュリティに対応したリゾルバー用に、DNSトラストアンカーのロールオーバーを自動化するための要件を述べている。

　IMAP COMPRESS拡張の仕様がRFC 4978として勧告された。
　COMPRESS拡張により、IMAP接続は効率的かつ効果的に圧縮される。

　デュアルスタックモビリティについての問題提起がRFC 4977として承認された。
　RFC 4977はデュアルスタック移動ノードのモビリティ管理に関する問題について議論している。現在、IPv4およびIPv6用に定義されている2つのモビリティ管理用プロトコルをデュアルスタック移動ノードに導入すると、いくつかの問題が生じる。普及上、運用上の問題が移動ノードにあれば、単一スタックのモビリティ管理プロトコルを使う人が多くなるだろう。そこでRFC 4977では、デュアルスタックモビリティを普及させる件について議論している。また、モバイルIPv4およびモバイルIPv6プロトコルがデュアルスタックノードに対応するための要件についても議論している。

　SIP（Session Initiation Protocol）PプロファイルキーPヘッダーに関する文書がRFC 5002として承認された。
　RFC 5002はSIPのPプロファイルキーPヘッダーの仕様を定めている。このヘッダーフィールドは、3GPP（3rd-Generation Partnership Project）のIMS（IP Multimedia Subsystem）で、SIPレジストラーとSIPプロキシーサーバーに、特定のSIP要求の宛先SIP URIに対応するプロファイルの鍵を提供するために使われる。

　CertIDアルゴリズムの追加に関するESS（Enhanced Security Services）の更新仕様がRFC 5035として勧告された。
　S/MIME用のESSのオリジナルの仕様書（RFC 2634）において、署名の有効性を確認する証明書を暗号的に保護してリンクする構造体（SHA-1を用いるようにハードウェアと一体になっている）が導入された。一方、RFC 5035はアルゴリズムの融通性を高めるために、構造体用に新しい属性を定義している。

　RSCN（Fibre Channel Registered State Change Notification）MIBの仕様がRFC 4983として勧告された。ネットワーク管理用のプロトコルとともに、MIBの一部として使われる。
　RFC 4983はRSCNに関連する情報用の管理オブジェクトについて述べている。

　輻輳制御アルゴリズムの新仕様に関する文書がRFC 5033として承認された。
　　RFC 5033の目的は、IETFで代替となる輻輳制御アルゴリズムを検討する際のガイダンスである。IETFの標準輻輳制御スキームには高速ネットワークなど、さまざまな環境で不十分であることが広く知られている。近年の研究には代替となる輻輳制御スキームがあるが、現在のIETFの輻輳制御原則からはかけ離れている。インターネット全体で新しい輻輳制御スキームを用いると、新しい輻輳制御スキームを使ったトラフィックと、現在の標準輻輳制御スキームを使ったトラフィックとが分離してしまうことも考えられる。したがって、代替となる輻輳制御案を扱うにあたっては、IETFは注意深く事を進めなければならない。

　ダブリンコアメタデータ要素集についての文書がRFC 5013として承認された。
　RFC 5013は多分野を貫く情報環境におけるリソース記述用の15のメタデータ要素を定義している。

　インターネットセキュリティ用語集第2版がRFC 4949として承認された。
　RFC 4949は情報システムのセキュリティ用語の定義や略語、説明を提供している。334ページに及ぶ本文は、インターネット標準化過程（RFC 2026）で生まれるささまざまな文書の理解を深めるために推奨される定義、説明である。
　RFC 4949で推奨される内容は、標準化過程で生まれる文書で、①同じ概念を扱う限り、同じ用語、定義を使うべきであること、②辞書通りの平易な意味で用語を使うべきであること、③すでに公開された文書で定着している用語を使うべきであること、④ある用語を用いることが、他の企業や技術（すでにあるものやこれから開発されるものを含む）にとって不利にならないようにすべきであること、という4つの原則に沿っている。

　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では、こうした機能を実現するためのプロトコル拡張を定義している。

　TCP上の拡張ケルベロスバージョン5KDC（Key Distribution Center）交換に関する仕様がRFC 5021として勧告された。
　RFC 5021はTCP上でケルベロスバージョン5プロトコルを伝送する場合の拡張メカニズムについて述べている。拡張メカニズムは、長さフィールドの予約済み上位ビットを使って、TCP固有のケルベロス拡張をネゴシエートする。

　ERS（Evidence Record Syntax：証拠保全文法）の仕様がRFC 4998として勧告された。
　ユーザーが長期かつおそらく期間を定めない時間を経て、データ（デジタル署名されたデータを含む）が存在し、改ざんされていないことを共通の再現可能なやり方で証明しなければならないような事態は、さまざまな状況で起こりうる。RFC 4998は証拠保全の文法と過程についての仕様、既存データの否認を長期渡ってできなくする構造について定めている。

　TCPのSYNフラッド攻撃と一般的な対抗策に関する文書がRFC 4987として承認された。
　RFC 4987は数年前からよく知られている、TCPのSYNフラッド攻撃について、さまざまな対抗策と、それぞれの長所と短所を述べている。RFC 4987は攻撃の説明と、TCPの実装者やTCPサーバーやネットワーク管理者の役に立つような一般的な防御手法についてまとめている。ただし、TCP標準についての推奨などはしていない。

　6LoWPAN（IPv6 over Low-Power Wireless Personal Area Network）の概要と前提、問題提起、目標についての文書がRFC 4919として承認された。
　RFC 4919はIP over IEEE 802.15.4ネットワーク上のIP伝送の前提、問題提起、目標について述べている。RFC 4919で挙げてる一連の目標は当初のものだけを含んでいる。

　VPNが入り組んでいる場合のQoSシグナリングについての文書がRFC 4923として承認された。
　ネットワークの内部にあるVPNと外部にあるVPN間の通信や、そうしたネットワークが結合してVPNが入り組んでいる通信が発生するネットワークでは、特に異なる優先順位が設定された通信のQoS情報を提示するような場合、VPNと非VPNの境界でどんな情報がやりとりされているかについて慎重に扱うべきである。RFC 4923はこの問題と、Diffservネットワーク（RFC 2998）上の統合サービス運用のためのフレームワークに基づくソリューション提案の概要を述べようとしている。

　2006年5月10日に開催された「不要なトラフィックに関するIABワークショップ」からの報告書がRFC 4948として承認された。
　RFC 4948はIAB（Internet Architecture Board）が主催した不要なトラフィックに関するワークショップの成果についての報告書である。このワークショップは2006年5月9～10日にかけて米国カリフォルニア州マリナ・デル・レイにある南カリフォルニア大学情報科学研究所（USC/ISI）で開催された。
　ワークショップの第一の目的は、不要なトラフィックを話題に、運用者、標準化団体、研究者のコミュニティの交流を図ることである。この場合の不要なトラフィックとは、たとえばDDoS（Distributed Denial of Service）攻撃やスパムメール、フィッシング詐欺のことであり、こうした不要なトラフィックがいったいどこから発生するのかの根本的理解と、既存のソリューションに与える直接の影響と効果について話し合われた。また、IABやIETF、IRTF、ネットワークの研究開発コミュニティ全体が不要なトラフィックに対抗する効果的な対策を開発しうるかについて、工学的および研究上の話題を見定めることもワークショップの目的である。

　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問題について明確には触れていない）を補うものであり、公開鍵証明書と関連する鍵の問題について述べている。

　LDAP（Lightweight Directory Access Protocol） entryDN操作属性の仕様がRFC 5020として勧告された。
　RFC 5020はLDAP/X.500の「entryDN」運用属性について述べている。entryDN属性は、属性値の確認時にエントリーの識別名のコピーとして用いる。

　IRIS（Internet Registry Information Service）用の軽量UDP伝送プロトコルの仕様がRFC 4993として勧告された。
　RFC 4993はIRIS用の軽量UDP伝送プロトコルについて述べている。この伝送プロトコルはそれぞれの要求と応答に単一のパケットを用いる。また、パケットの内容を圧縮するオプションもある。

　チャンクを用いたIRIS（Internet Registry Information Service）用のXMLパイプラインの仕様がRFC 4992として勧告された。
　RFC 4992はIRIS用の簡単なTCP伝送プロトコルについて述べている。パイプラインの実現のために、クライアントとサーバー間でデータがチャンクを使って伝送される。

　IRIS（Internet Registry Information Service）伝送プロトコル用共通スキーマの仕様がRFC 4991として勧告された。
　RFC 4991はIRISアプリケーションとして共通の特徴を持つ伝送プロトコル用のXMLスキーマについて述べている。バージョン、対応する拡張やセキュリティメカニズムといった伝送プロトコルに関する共通の情報について述べている。

　ネットワーク接続検出用のリンク層イベント通知に関する文書がRFC 4957として承認された。
　ある種のネットワークアクセス技術では、IPに対してさまざまな種類のリンク層状態の情報を提供できる。リンク層イベント通知は、IPが構成の変更を即座に検出できるようにする技術である。RFC 4957は、既知のアクセス技術からリンク層イベント通知についての技術を大まかにまとめている。

　vCard ENUMサービス用のIANA登録に関する文書がRFC 4969として承認された。
　RFC 4969によって、URIスキーム「http」および「https」を用いたENUMサービス「vCard」が登録される。このENUMサービスは、ENUMドメイン名から、利用者各自のE.164番号を記述するvCardデータを参照するために使われる。
　vCardから集められる情報は、通話前、通話中、通話後に利用できる。たとえば、着呼側で受話器をとる前に、発呼側の名前や所属が電話機に表示される、といった使い方ができる。

　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は廃止される。
　

　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は廃止される。

　ENUMサービス「XMPP」のIANA登録に関する仕様がRFC 4979として勧告された。
　RFC 4979はIANAに対してENUMサービス「XMPP（Extensible Messaging and Presence Protocol）」の登録を求めている。XMPP ENUMサービスは、ENUM（E.164 Number Mapping）における「xmpp」URIの利用について定めている。

　コール対応用の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、時分割、ラムダ、ファイバースイッチなど、あらゆるインターフェイスに適用可能である。

　ファイバーチャネル・ゾーンサーバーMIBの仕様がRFC 4936として勧告された。ネットワーク管理用のプロトコルとともに、MIBの一部として使われる。
　RFC 4936はファイバーチャネル・ゾーンサーバーに関連する情報用の管理オブジェクトについて述べている。

　ファイバーチャネル・ファブリック構成サーバーMIBの仕様がRFC 4935として勧告された。ネットワーク管理用のプロトコルとともに、MIBの一部として使われる。
　RFC 4935はファイバーチャネルネットワークのファブリック構成サーバー機能に関連する情報用の管理オブジェクトについて述べている。

　802.16ベースのネットワーク用IPv6リンクモデルを分析した文書がRFC 4968として承認された。
　RFC 4968はIEEE 802.16ベースのネットワークに適した別々のIPv6リンクモデルを示して、それぞれのリンクモデルごとのさまざまな検討事項に関する分析と、別々の普及シナリオに沿って、それぞれのリンクモデルの適用性を示している。
　RFC 4968は、IEEE 802.16ベースのネットワーク用のIPv6リンクの分析のために結成された設計チームの成果物である。

　MPLS（Multiprotocol Label Switching）用ICMP拡張の仕様がRFC 4950として勧告された。
　RFC 4950は選択されたマルチパートICMPメッセージに追加できる拡張オブジェクトを定義している。この拡張はすでに広く普及しており、LSR（Label Switching Router）はICMPメッセージにMPLS情報を追加できるようになる。

　広告ルーター情報用のIS-IS（Intermediate System to Intermediate System）拡張の仕様がRFC 4971として勧告された。
　RFC 4971はCAPABILITYと名付けられたIS-IS TLVオプションを新しく定義している。CAPABILITYは複数の下位TLVから成り、ルーターがIS-ISレベルまたはルーティングドメイン全体で自身の性能について通知できるようにする情報を格納している。

　OSPF-xTE（Experimental Extension to OSPF for Traffic Engineering）の実験的仕様がRFC 4973として承認された。
　RFC 4973はOSPF-xTEと呼ばれる、リンク状態ルーティングプロトコルであるOSPFへのトラフィックエンジニアリング拡張技術を定義している。OSPF-xTEが定義しているのはAS（Autonomous System：自律システム）内のTEの計測値を広めるための新しいTE LSA（Link State Advertisement：リンク状態広告）である。（ASは複数のエリアから成り立っていてもよい）
　ASがTEと非TEノードから成り立っている場合、OSPF-xTEは非TEノードがTE LSA から影響を受けないことを保証している。OSPF-xTEはTEのサーキット経路を算出するために、元々のOSPF LSDB（Link State Database）とは区別される、独立したTE-LSDB（TE Link State Database）を生成する。OSPF-xTEは多くの用途に利用でき、SONET/TDM（Synchronous Optical Network/Time Division Multiplexing）や光ネットワークのような非パケット型のネットワークにも拡張可能である。

　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メンバーの全体を自動的に発見できるようにする。
　

　ルーター性能告知オプション用の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などの定義されたフラッディング範囲内に告知できる。

　対称的なRTP/RTCP（）についての文書がRFC 4961として承認された。
　RFC 4961は両方向のRTP（Real Time Protocol）およびRTCP（RTP Control Protocol）セッションでは、通信方向の双方で1つのUDPポートを用いることを推奨している。この仕様は一般的には「対称的RTP」や「対称的RTCP」と呼ばれている。