David McWalter（編集担当、Data Connection）
URI（Uniform Resource Identifier）用のMIB省略表記の仕様がRFC 5017として勧告された。
このMIBモジュールはURI（STD 66）を表現するための省略表記を定義している。独自の表記方法を持つMIBモジュールで導入される。
Russell Housley（Vigil Security）、Jerome A. Solinas（米国家安全保障局国家情報保障研究所）
John Jason Brzozowski（Comcast Cable）、Kim Kinnear（シスコシステムズ）、Bernard Volz（シスコシステムズ）、Shengyou Zeng（シスコシステムズ）
Enke Chen（シスコシステムズ）、Srihari R. Sangli（シスコシステムズ）
Jeff Van Dyke（Cantata Technology）、Eric Burger（編集担当、BEA Systems）、Andy Spitzer（Bluesocket）
MSCML（Media Server Control Markup Language）とプロトコルについての文書がRFC 5022として承認された。
MSCMLとは、SIPとともに用いて、先進的なカンファレンスとIVR（Interactive Voice Response：音声自動応答）を実現するためのマークアップ言語である。MSCMLが表現するのは装置レベルの制御モデルではなく、アプリケーションレベルの制御モデルであり、IETFのSIPカンファレンスフレームワークにおいて、カンファレンスフォーカスとミキサー間の通信を実現するために利用できる。
Kim Kinnear（シスコシステムズ）、Marie Normoyle（シスコシステムズ）、Mark Stapp（シスコシステムズ）
DHCPv4（Dynamic Host Configuration Protocol version 4）リレーエージェントフラグサブオプションの仕様がRFC 5010として勧告された。
RFC 5010はDHCPリレーエージェント情報オプションの新しいサブオプションを定義して、DHCPリレーで転送されたパケット用に2つのフラグを付けられるようにする。
1つのフラグは、DHCPリレーがパケットをユニキャストパケットで受信したか、ブロードキャストパケットで受信したのかを示すためにある。DHCPサーバーがこのフラグを使って、クライアントからの要求が元々ブロードキャストなのかユニキャストなのかで扱いを変えられるようになる。
John Risson（ニューサウスウェールズ大学電子工学通信学部）、Tim Moors（ニューサウスウェールズ大学電子工学通信学部）
検索方式に関する頑強なP2P（Peer-To-Peer）ネットワークに対する研究の調査についての文書がRFC 4981として承認された。
最近5年間のP2Pネットワークに関する研究の進歩は、P2Pを重要視した調査が真実であったことがわかる。P2Pは破壊的な技術となる可能性を秘めており、導入コストや拡大コストをなるべく抑えながら、膨大な量のストレージや処理能力を集約しうる。ただ、従来型アーキテクチャに比べれば個々のエラーの影響はずっと少ないとはいえ、分散された膨大な数のピア間ではエラーが日常茶飯事であり、すでにあるファイル共有以上のアプリケーションをP2Pで実現する鍵となるのは頑強さである。
RFC 4981ではまず、P2Pに分類されるあらゆる技術における検索方式を調べている。Plaxtonツリーやリング、tori、バタフライ、de Bruijnダイグラフ、スキップグラフに基づく、簡単なキー検索用P2Pインデックスを評価し、同様にキーワード検索や情報取得、データ管理用のP2Pインデックスについても調べている。最後に、検索範囲の最適化やマルチ属性、参加、P2Pインデックスの問い合わせの集約に関する初期の模索についても評価している。
検索方式について基本文献で言及されている限りにおいて、RFC 4981では頑強さのメカニズムとその指標に重きを置いているが、文献中では頑強さにもっとも影響を与える低レベルメカニズムが上位のメカニズムきちんと分離していない。RFC 4981には将来の研究用の推奨仕様も含まれる。
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間で疑似有線が確立されている大規模なドメイン間の仮想専用線サービスネットワークで利用する場合に有用である。
塩本公平（NTTネットワークサービスシステム研究所）、Richard Rabbat（グーグル）、Rajiv Papneja（Isocore）
GMPLS（Generalized Multiprotocol Label Switching）ネットワークにおけるアドレスの使用についての文書がRFC 4990として承認された。
RFC 4990はGMPLSネットワークにおけるアドレスの使用について明らかにし、GMPLS対応のLSR（Label Switching Router）の互換性を高めることが目的である。RFC 4990は、実装や互換性のテスト、実運用での経験に基づいている。
RFC 4990はGMPLSプロトコルでアドレスや識別子フィールドをどのように解釈すべきか、また、どのアドレスを特定の制御プレーンユーゼージモデルに当てはめるかについても述べている。さらに、IPv6の送信元と宛先アドレスをMPLS/GMPLSのトラフィックエンジニアリングMIB（Management Information Base）でどのように扱うかについても議論している。
なお、RFC 4990は新しい手続きや処理は定義していない。要件の提示や推奨を示している部分は、規範となる参照先RFCから引用されたものである。
Andrew Allen（編集担当、RIM）、Jan Holm（エリクソン）、Tom Hallin（モトローラ）
Stefan Santesson（マイクロソフト）
Howard Eland（Afilias Limited）、Russ Mundy（SPARTA）、Steve Crocker（Shinkuro）、Suresh Krishnaswamy（SPARTA）
DNSSECトラストアンカーロールオーバーに関する要件がRFC 4986として承認された。
DNSセキュリティに対応するすべてのリゾルバーは、DNS署名ゾーンからの応答を検証するために、少なくとも1つのトラストアンカーを持たなければならない。また、さまざまな理由により、DNSセキュリティに対応したほとんどのリゾルバーは、複数のトラストアンカーを持つことになっている。
運用形態によっては、トラストアンカーの手動による監視と更新も可能だが、多くの場合はDNSセキュリティに対応したリゾルバーによる自動化されたトラストアンカーの更新が必要である。そこでRFC 4986は、DNSセキュリティに対応したリゾルバー用に、DNSトラストアンカーのロールオーバーを自動化するための要件を述べている。
IMAP COMPRESS拡張の仕様がRFC 4978として勧告された。
COMPRESS拡張により、IMAP接続は効率的かつ効果的に圧縮される。
George Tsirtsis（クアルコム）、Hesham Soliman（Elevate Technologies）
デュアルスタックモビリティについての問題提起がRFC 4977として承認された。
RFC 4977はデュアルスタック移動ノードのモビリティ管理に関する問題について議論している。現在、IPv4およびIPv6用に定義されている2つのモビリティ管理用プロトコルをデュアルスタック移動ノードに導入すると、いくつかの問題が生じる。普及上、運用上の問題が移動ノードにあれば、単一スタックのモビリティ管理プロトコルを使う人が多くなるだろう。そこでRFC 4977では、デュアルスタックモビリティを普及させる件について議論している。また、モバイルIPv4およびモバイルIPv6プロトコルがデュアルスタックノードに対応するための要件についても議論している。
Gonzalo Camarillo（エリクソン）、German Blanco（エリクソン）
Jim Schaad（Soaring Hawk Consulting）
Claudio DeSanti（シスコシステムズ）、H.K. Vivek（シスコシステムズ）、Keith McCloghrie（シスコシステムズ）Silvano Gai（Nuova Systems）
Sally Floyd（ICIR）、Mark Allman（ICIR）
輻輳制御アルゴリズムの新仕様に関する文書がRFC 5033として承認された。
RFC 5033の目的は、IETFで代替となる輻輳制御アルゴリズムを検討する際のガイダンスである。IETFの標準輻輳制御スキームには高速ネットワークなど、さまざまな環境で不十分であることが広く知られている。近年の研究には代替となる輻輳制御スキームがあるが、現在のIETFの輻輳制御原則からはかけ離れている。インターネット全体で新しい輻輳制御スキームを用いると、新しい輻輳制御スキームを使ったトラフィックと、現在の標準輻輳制御スキームを使ったトラフィックとが分離してしまうことも考えられる。したがって、代替となる輻輳制御案を扱うにあたっては、IETFは注意深く事を進めなければならない。
John A. Kunze（カリフォルニア大学カリフォルニアデジタルライブラリー）、Thomas Baker（ダブリンコアメタデータイニシアチブ）
Dr. Robert W. Shirey
インターネットセキュリティ用語集第2版がRFC 4949として承認された。
RFC 4949は情報システムのセキュリティ用語の定義や略語、説明を提供している。334ページに及ぶ本文は、インターネット標準化過程（RFC 2026）で生まれるささまざまな文書の理解を深めるために推奨される定義、説明である。
RFC 4949で推奨される内容は、標準化過程で生まれる文書で、①同じ概念を扱う限り、同じ用語、定義を使うべきであること、②辞書通りの平易な意味で用語を使うべきであること、③すでに公開された文書で定着している用語を使うべきであること、④ある用語を用いることが、他の企業や技術（すでにあるものやこれから開発されるものを含む）にとって不利にならないようにすべきであること、という4つの原則に沿っている。
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）
Wesley M. Eddy（NASAグレン研究センター ベライゾン連邦ネットワークシステム）
Nandakishore Kushalnagar（インテル）、Gabriel Montenegro（マイクロソフト）、Christian Peter Pii Schumacher（Danfoss）
Fred Baker（シスコシステムズ）、Pratik Bose（ロッキード・マーチン）
Loa Andersson（Acreo AB）、Elwyn Davies（Folly Consulting）、Lixia Zhang（UCLA）
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、ネットワークの研究開発コミュニティ全体が不要なトラフィックに対抗する効果的な対策を開発しうるかについて、工学的および研究上の話題を見定めることもワークショップの目的である。
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（ベリサイン）
Suresh Krishnan（編集担当、エリクソン研究所）、Nicolas Montavont（GET ENST Bretagne）、Eric Njedjou（フランステレコム）、Siva Veerepalli（クアルコム）、Alper E. Yegin（編集担当、サムスン）
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）
Syam Madanapalli（編集担当、Ordyn Technologies）
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
Pyda Srisuresh（Kazeon Systems）、Paul Joseph（コンサルタント）
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）や光ネットワークのような非パケット型のネットワークにも拡張可能である。
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などの定義されたフラッディング範囲内に告知できる。
Dan Wing（シスコシステムズ）
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で定義された仕様を変更したり、更新したりしていない。
偽造攻撃からTCPを守ることについての文書がRFC 4953として承認された。
インターネット基盤の中心部分への攻撃の可能性に関する最近の分析は、偽造された送信元IPアドレスで送信される偽造されたリセットフラグ（RST）に関するTCPコネクションの脆弱性を狙った攻撃が増えていることを示している。
TCPはこれまでもこうしたRSTフラグの偽造攻撃にさらされやすく、RSTフラグがオンのパケットの連番が受信側ウィンドウサイズよりも小さいかどうかを検査したり、TCPパケットの送信元アドレスやポート番号に矛盾がないかなどを調べて、間接的に偽造がどうかを見抜いていた。
しかし、BGPルーターやWebサーバーと大規模キャッシュサーバー間のように、トラフィックの多いホストは両端で予測可能なポート番号を用いることがしばしばあり、コネクションの経路のBDP（Bandwidth-Delay Product：帯域幅遅延積）の増分は、経路外の第三者がRSTフラグがオンに偽造したパケットの連番を総当たり式に生成できるほど十分に増加していく。パケットの連番が力ずくで見破られる可能性は帯域幅の二乗で増えることになり、現在の高速ネットワークでは見過ごせない脆弱性になっている。
RFC 4953はこうした脆弱性があることを示し、トランスポート層での解決案とその課題、既存のネットワーク層での解決策と普及の可能性について議論している。RFC 4953が主に扱っているのは偽造されたTCPセグメントによって起きる脆弱性だが、関連するTCPコネクションに関するICMPの偽造についても議論している。
John W. Heffner（ピッツバーグ・スーパーコンピューターセンター）、Matt Mathis（ピッツバーグ・スーパーコンピューターセンター）、Ben Chandler（ピッツバーグ・スーパーコンピューターセンター）
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としてダイヤル文字列を符号化できるようにしている。
Roy Arends（Nominet）、Mark Kosters（ベリサイン）、David Blacka（ベリサイン）
Xing Li（編集担当、CERNET）、Spencer Dawkins（編集担当、Huawei Technologies）、David Ward（編集担当、シスコシステムズ）、Alain Durand（編集担当、Comcast）
Softwireの問題を提起刷る文書がRFC 4925として承認された。
RFC 4925はSoftwire作業部会用に問題提起をとりまとめている。Softwire作業部会では、IPv6のみのネットワーク内のIPv4ネットワークやIPv4のみのネットワーク内のIPv6ネットワークを接続するための発見と制御、カプセル化手法の標準技術を開発中である。Softwire技術は、IPv4/IPv6およびIPv6/IPv4トランザクションの問題を解決するために、既存の標準プロトコルについて明らかにし、必要に応じては拡張することで、複数ベンダー間で相互利用可能な実装を促すことになる。RFC 4925は「ハブとスポーク」「メッシュ」と呼ばれる特定の問題と、Softwire作業部会で開発中の技術でどのように解決されるかについて述べている。また、問題範囲をより特定して述べるために、いくつかの要件と、要件にならない事項についても明らかにしている。
John C Klensin、YangWoo Ko（ICU）
Cedric Aoun（Energize Urnet）、Elwyn B. Davies（Folly Consulting）
Bernard Aboba（マイクロソフト）、Elwyn B. Davies
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節を更新する情報も含まれている。
Gabor Feher（ブダペスト技術経済大学通信メディアインフォマティクス学部）、Krisztian Nemeth（ブダペスト技術経済大学通信メディアインフォマティクス学部）、Andras Korn（ブダペスト技術経済大学通信メディアインフォマティクス学部）、Istvan Cselenyi（TeliaSonera International Carrier）
Kevin Gibbons（2Wire）、G.D. Ramkumar（SnapTell）、Scott Kipp（Brocade）
Russell Housley（Vigil Security）、Bernard Aboba（マイクロソフト）
AAA（Authentication, Authorization, and Accounting）鍵管理のガイダンスがRFC 4962として承認された。
RFC 4962はAAA鍵管理プロトコルの設計者用ガイダンスである。また、AAA鍵管理プロトコルを含むシステムやソリューションの設計者にも便利な内容になっている。セキュアな設計における複雑性と困難性や長期間使える鍵管理アルゴリズム、専門知識を持つセキュリティ分野の専門家が開発したプロトコルがなければ、IETF作業部会がAAAに基づく独自の鍵管理アルゴリズムとプロトコルを設計することは非常に難しい。RFC 4962におけるガイドラインはIETFのRFCとして発行される他の文書にも適用される。また、こうしたガイドラインは他のSDO（Standards Development Organization：標準化団体）がAAAに基づく鍵管理技術を標準化する際にも有用である。
Robert Siemborski（グーグル）、Alexey Melnikov（Isode Limited）
Marcelo Bagnulo（カルロス三世大学）、Jari Arkko（エリクソン）
Godred Fairhurst（アバディーン大学工学部）、Marie-Jose Montpetit（モトローラ）
MPEG-2ネットワーク上のIPデータグラム用のアドレス解決メカニズムに関する文書がRFC 4947として承認された。
RFC 4947はIPv4/IPv6アドレスとMPEG-2伝送システム（TS：Transport Streams）をバインディングおよび関連づける処理について述べている。アドレス解決の手続きにはAR（Address Resolution：アドレス解決）またはND（Neighbor Discovery：近隣探索）が知られており、IPセッション用広告に使われる上位層のリソース発見ツールを補うものである。
MPEG-2ネットワークでは、IPアドレスはPID（Packet ID）および特定の伝送多重化方式と関連づけられていなければない。RFC 4947は、DVB（Digital Video Broadcasting）やATSC（Advanced Television Systems Committee）、DOCSIS（Data-Over-Cable Service Interface Specifications）といった技術に適合する現行方式について評価し、DHCPやARP、NDプロトコルを含むアドレス管理用のプロトコルとの関係について述べている。
Chan-Wah Ng（パナソニックシンガポール研究所）、Fan Zhao（カリフォルニア大学デービス校）、渡里雅史（KDDI R&D研究所）、Pascal Thubert（シスコシステムズ）
NEMO（Network Mobility）経路最適化ソリューションスペース分析に関する文書がRFC 4889として承認された。
現行のNEMO基本対応では、モバイルネットワークが外部にある場合、モバイルネットワークノードとのすべての通信はモバイルルーターとホームエージェント間（MRHA：Mobile Router and Home Agent）トンネルを通らなければならない。そのため、ほとんどの場合、パケットの経路が長くなったり、遅延を引き起こしたりする。こうした制限を乗り越えるには、NEMOの経路最適化（RO：Route Optimization）を使うことになる。RFC 4889はNEMOにおけるさまざまな経路最適化タイプについてまとめており、長所と、NEMO経路最適化とは異なる面でのトレードオフについて述べている。
Chan-Wah Ng（パナソニックシンガポール研究所）、Pascal Thubert（シスコシステムズ）、渡里雅史（KDDI R&D研究所）、Fan Zhao（UC Davis）
NEMO（Network Mobility）経路最適化に関する問題を提起する文書がRFC 4888として承認された。
現行のNEMO基本対応には、モバイルネットワークが移動先にある場合、モバイルネットワークノードとの通信はすべて、モバイルルーターとホームエージェント間で確立される双方向のトンネルを通らなければならない。この最適とはいえないルーティングは、遅延の増大とトラフィックの輻輳につながるボトルネックリンクといったパケットの遅延に起因するさまざまな不効率を引き起こし、ついにはモバイルネットワークノードとのすべての通信が妨害されかねない。さらに、モバイルネットワークをつなぎ合わせた環境では、こうした不効率が複合し、特定の構成ではトラフィックの膠着状態を引き起こしかねない。RFC 4888はこうした問題を捉えて、NEMO用の経路最適化の必要性を説いている。
Pascal Thubert（シスコシステムズ）、湧川隆次（慶應義塾大学環境情報学部）、Vijay Devarapalli（Azaire Networks）
Thierry Ernst（INRIA）
NEMO（Network Mobility）対応の目標と要件についての文書がRFC 4886として承認された。
NEMOでいう移動ネットワークとは、あるネットワークをインターネットに接続するルーターがインターネットへの接続点を順次切り替えることであり、固定ネットワークと移動ネットワークの接続が順次切り替わるために、接続上の問題が起きる。こうしたタイプのネットワークを移動ネットワークと呼び、適切なメカニズムがあれば、移動ネットワーク内のノード間のセッションは維持され、移動ルーターがインターネットへの接続点を変えても、インターネット全体では接続が維持される。RFC 4886はNEMO対応に期待される目標を概観し、NEMO対応から見積もった目標を定め、NEMO基本対応ソリューションに適合するはずの要件を定義している。
Thierry Ernst（INRIA）、Hong-Yon Lach（モトローラ）
Kireeti Kompella（ジュニパーネットワークス）、Bill Fenner（AT&T研究所）
John C Klensin（編集担当）、Dave Thaler（編集担当、マイクロソフト）
RFC編集者への独自提出についての文書がRFC 4846として承認された。
インターネットの技術コミュニティには、IETF（Internet Engineering Task Force）が設立される以前から、IETFの標準化過程およびその査読と承認メカニズムに根ざさない文書をRFCとして発行する伝統がある。「独自提出」と呼ばれるこうした文書はインターネットの技術コミュニティ（IETFで活動中の提出者である場合とそうでない場合がある）に対して、いくつもの重要な機能を担っている。
RFC 4846は独自提出モデルとその重要性について議論している。その上で、IETFの技術コミュニティと独自提出文書の発行者との新しい関係が前進するように、独自提出文書で用いられる編集上および発行までの工程上の規範について述べている。
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のセットアップの成功と回復の比率は、特に同時に大量のセットアップ要求が送信された場合に大幅に改善される。
Dr. Steven Legg（eB2Bcom）
RXER（Robust XML Encoding Rules）用符号化手順の実験的仕様がRFC 4911として承認された。
RFC 4911はASN.1（Abstract Syntax Notation One）仕様で、ASN.1の値をXML（Extensible Markup Language）の子要素よりはXMLの属性として符号化するといったように、RXERおよびCRXER（Canonical Robust XML Encoding Rules）でASN.1の値をどのように符号化するかを変更するための仕様を定めている。符号化手順のいくつかはASN.1仕様をどのようにASN.X（Abstract Syntax Notation X）に変換するのかに影響を与える。また、XMLスキーマ言語においてASN.1仕様を参照定義とする符号化手順も定義されている。
Dr. Steven Legg（eB2Bcom）
Dr. Steven Legg（eB2Bcom）
Dr. Steven Legg（eB2Bcom）
ASN.X（Abstract Syntax Notation X）の実験的仕様がRFC 4912として承認された。
ASN.Xは、ASN.1言語にある数々の曖昧性を排除している。したがって、ASN.Xで記述された仕様は、元のASN.1で記述された仕様よりも構文解析がしやすく、たやすく管理できる。また、RXERと併用することで、ASN.XはXML文書用のスキーマ言語として利用でき、他のASN.1符号化規則を適用することで実際のXML文書をバイナリ符号化するコンパクトな代替形式にもなる。
T. Kalin（DANTE）、Maurizio Molina（DANTE）
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機能の結果や状態を提供したりするための管理オブジェクトを定義している。
Karim El Malki（Athonet）
モバイルIPv4における低レイテンシーハンドオフに関する実験的仕様がRFC 4881として承認された。
異なるフォーリンエージェントによるサブネット間でモバイルノードがどのようにIPv4レイヤーをハンドオフするかについてはモバイルIPv4の仕様で述べられている。しかしある種の場合、ハンドオフ時のレイテンシーが、遅延に弱かったり、リアルタイムのサービスに対応するために、許容値を超えてしまうことがある。
RFC 4881の目的は、低レイテンシーのモバイルIPv4ハンドオフの2つの手法を示すことである。また、2つの手法を組み合わせる方法についても述べている。この手法によって、モバイルIPv4の登録手続きに遅延が生じることでモバイルノードがIPv4パケットを送受信できなくなる時間をなるべく短くし、リアルタイムサービスにより対応できるようになる。
Lisa Dusseault（編集担当、CommerceNet）
Peter Psenak（シスコシステムズ）、Sina Mirtorabi（Force10 Networks）、Abhay Roy（シスコシステムズ）、Liem Nguyen（シスコシステムズ）、Padma Pillay-Esnault（シスコシステムズ）
Bo Berry（シスコシステムズ）、Howard Holgate（シスコシステムズ）
Peter Arberg（レッドバックネットワークス）、Vince Mammoliti（シスコシステムズ）
Loa Andersson（Acreo）、Stewart Bryant（シスコシステムズ）、George Swallow（シスコシステムズ）
MPLSネットワークにおける同コストの複数経路の取り扱いの回避に関する文書がRFC 4928として承認された。
RFC 4928は現在利用されているMPLSネットワークのECMP（Equal Cost Multipath）の振る舞いについて述べている。RFC 4928は、MPLSネットワーク上でアプリケーションを実行するとき、同コストの複数経路上の同じフローの異なるパケットの伝送によって引き起こされる再構成をIPパケットのバージョン番号フィールドの監視によって避けるための、現状の最善の慣行による推奨仕様である。推奨仕様は、発見的手法を採っているにも関わらず、MPLSネットワークの運用において比較的安定した効果がある。
Lakshminath Dondeti（編集担当、クアルコム）、David Castleford（フランステレコム）、Frank Hartung（エリクソン研究所）
Jean-Louis Le Roux（編集担当、フランステレコム）、Dean Cheng（シスコシステムズ）、熊木健二（KDDI）、大木英司（NTT）、Raymond Zhang（BT）、Renhai Zhang（ファーウェイ・テクノロジー）
エリア間MPLSおよびGMPLSトラフィックエンジニアリング用のPCECP（Path Computation Element Communication Protocol）仕様の要件に関する文書がRFC 4927として承認された。
スケーラビリティのため、ネットワークを複数のIGP（Interior Gateway Protocol）エリアに分割することがある。その際、1つのエリア間TE-LSP（Traffic Engineered Label Switched Path）が少なくとも2つのIGPエリアを結ぶLSPとなる。複数のエリアからなるネットワークでは、ネットワークトポロジーの全貌はそれぞれのエリア内でしか把握できず、全体を管理すべきヘッドエンドLSR（Label Switching Router）には、エリア間の最短経路を算出できない。PCE（Path Computation Element）アーキテクチャに基づくアプリケーションが鍵となり、エリア間のTE-LSP経路を算出する。PCECP（Path Computation Element Communication Protocol）によってPCC（Path Computation Client）からPCEへの経路算出要求を送信し、算出した経路を応答する。
RFC 4927では、エリア間TE-LSP経路の算出に対応するPCECP仕様の要件を列挙し、一般的なPCE通信プロトコルの要件を補っている。
永見健一（インテック・ネットコア）、宇田聡（北陸先端科学技術大学院大学）、 小柏伸夫（ネットワークソフトウェア研究所）、江崎浩（東京大学）、湧川隆次（慶應義塾大学環境情報学部）、大西浩行（NTT）
モバイルIPおよびNEMOを用いた小規模固定ネットワーク用のマルチホーミングに関する実験的仕様がRFC 4908として承認された。
マルチホーミング技術はホストとネットワークの接続の稼働率を改善する。しかし、固定ネットワークとモバイルネットワークの振る舞いの違いにより、それぞれ異なるアーキテクチャが議論され、提案されている。RFC 4908はモバイルIP（RFC 3775）とNEMO（Network Mobility、RFC 3963）を用いて、モバイルおよび固定ネットワーク環境のどちらでも利用できる共通のアーキテクチャを提案している。複数の気付アドレス（CoAs：Care-of Addresses）が使えるように、RFC 4908のアーキテクチャはモバイルIPとNEMOの変更が必須である。また、冗長化のために、異なる場所にある複数のホームエージェント（HA：Home Agent）も必要である。
George Swallow（シスコシステムズ）、Deborah Brungard（AT&T）、Bill Fenner（AT&T）、Ross Callon（ジュニパーネットワークス）、Kireeti Kompella（ジュニパーネットワークス）、Alex Zinin（アルカテル）、Scott Bradner（ハーバード大学）、Loa Andersson（編集担当、Acreo）
MPLS（Multiprotocol Label Switching）およびGMPLS（Generalized MPLS）のプロトコルと手続きの変更処理に関する文書がRFC 4929として承認された。
RFC 4929はMPLSおよびGMPLSプロトコルスイートの仕様に適用されるか、MPLSおよびGMPLSプロトコルスイートの仕様を拡張し、IETFのMPLSおよびGMPLS作業部会のMPLSおよびGMPLSプロトコルスイートに関する責任を明確にするためのガイドラインである。RFC 4929はベンダー同士の協議の場や、標準化団体（SDO：Standards Development Organization）に対して、IETFにおけるMPLSおよびGMPLSの標準化作業の概要を示し、MPLSおよびGMPLSのアプリケーションやプロトコルを拡張する際のIETFの査読手続きの必要性を示している。
Venkateshwara Sastry（サムスンエレクトロニクス）、Kent Leung（シスコシステムズ）Alpesh Patel（シスコシステムズ）
Suzanne Woolf（Internet Systems Consortium）、David Conrad（ICANN）
ネームサーバーインスタンス識別メカニズムの要件がRFC 4892として承認された。
DNSエニーキャストや負荷分散その他のメカニズムにより、1つのIPアドレスを複数のDNSサーバーで共有できるようになったため、ある問い合わせに対して、一群のDNSサーバーのうちのどれが応答したのかを特定するのが困難になっている。特に管理者がネットワークの障害を診断するような場合、ある問い合わせに対して、どのネームサーバーが応答したのかを識別するメカニズムが標準化されているのは有用である。しかし、こうした必要性から生じた既存のメカニズムは間に合わせであり、いくつかの欠点がある。しかも、この問題に関する従来の分析には、ネームサーバーインスタンスの識別メカニズムがどのように設計され、どのように適用するのかという視点が欠けている。そこでRFC 4892はDNSプロトコルの広く普及した実装に見られる既存の方法について、その長所と短所を述べ、改良方法の属性について議論している。
Luca Martini（シスコシステムズ）、Nasser El-Aawar（Level 3 Communications）、Eric Rosen（シスコシステムズ）
MPLS上のレイヤー2フレームの伝送に関する歴史文書がRFC 4906として承認された。
RFC 4906はフレームリレーやATM（Asynchronous Transfer Mode） AAL5（ATM Adaption Layer 5）、イーサーネットといったレイヤー2のPDU（Protocol Data Unit）のMPLSネットワーク上での伝送、SONET（Synchronized Optical Network）回線のMPLSネットワーク上でのエミュレーションサービスについて述べている。RFC 4906が述べているのはいわゆる「draft-martini」プロトコルであり、エッジ間疑似有線エミュレーション作業部によるRFC 4447その他の関連仕様によって置き換えられている。
Luca Martini（シスコシステムズ）、Nasser El-Aawar（Level 3 Communications）、Eric Rosen（シスコシステムズ）
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は更新される。
Christopher Carroll（Ropes & Gray LLP）、Frank Quick（クアルコム）
CDMA2000ネットワーク用のベライゾンワイヤレス動的モバイルIP鍵の更新に関する文書がRFC 4784として承認された。
ベライゾンワイヤレス動的モバイルIP鍵の更新手続きはCDMA2000ネットワーク（「1xEV-DO」として知られる高レートパケットデータを含む）におけるモバイルIP暗号鍵の鍵交換と更新用メカニズムである。DMU（Dynamic Mobile IP Key Update）の手続きはモバイルIPのモバイルノード（MN：Mobile Node）とRADIUS AAA（Authentication, Authorization and Accounting）サーバー間でモバイルIPの外部エージェント（FA：Foreign Agent）として動作するCDMA2000のPDSN（Packet Data Serving Node）経由で実行される。
Bernard Aboba（編集担当、マイクロソフト）
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）
Eva Fogelstroem（エリクソン）、Annika Jonsson（エリクソン）、Charles E. Perkins（ノキア・シーメンスネットワークス）
モバイルIPv4の地域登録に関する実験的仕様がRFC 4857として承認された。
モバイルIPを使う場合、モバイルノードは気付アドレスの変更のたびにホームエージェントに気付アドレスを登録し直す。RFC 4857は新たな種類である「地域登録」について述べている。この場合の登録手続きはホームエージェントではなく、訪問先のドメインである。
地域登録はGFA（Gateway Foreign Agent）と呼ばれる新しいネットワーク機器を通して実行され、このために訪問先ドメインのネットワーク階層に新たな層を加える。地域登録によってホームエージェントへのシグナリング回数が減り、訪問先ドメインが同じであればある移動先エージェントから別の移動先エージェンにモバイルノードが移動した場合のシグナリングの遅延も減らせる。地域登録はモバイルIPv4のオプション拡張である。
Vijay K. Gurbani（アルカテル・ルーセント ベル研究所）、Cullen Jennings（シスコシステムズ）
John C Klensin、Sam Hartman（マサチューセッツ工科大学）
標準化過程文書に対する規範的参照の取り扱いに関する文書がRFC 4897として承認された。
IETF（The Internet Engineering Task Force）とRFC（Request for Comments）編集者は、長期にわたって、参照先のすべての文書の成熟度が参照元の文書の標準化過程における成熟度と同じがそれ以上でない限り、文書を発行しないというルールに基づいてきた。しかし、このルールはしばしば文書の公開に遅れを来すほか、標準化過程文書の成熟度を進行させる上での障害になっているとの指摘もあるほどである。IETFはRFC 3967によってこのルールを迂回する場合があるが、RFC 4897は、参照先の標準化過程またはBCP（Best Current Practice）文書の成熟度が参照元よりも低い場合のより簡単な手続きについて述べている。つまり、「メモって前に進め！」というわけである。
なお、RFC 3967に定められた手続きは参照先が標準化過程またはBCPではない場合には引き続き適用される。いずれにしても、参照先についての注釈は加えられるべきである。
Gregory A. White、Gregory M. Vaudreuil（アルカテル・ルーセント）
Paul Hoffman（VPNコンソーシアム）
Scott Hollenbeck（ベリサイン）
Scott Hollenbeck（ベリサイン）
Scott Hollenbeck（ベリサイン）
Matt Mathis（ピッツバーグ・スーパーコンピューターセンター）、John Heffner（ピッツバーグ・スーパーコンピューターセンター）、Rajiv Raghunarayan（シスコシステムズ）
Martin Stecher（Secure Computing）
SMTP用OPES（Open Pluggable Edge Services）の完全性とプライバシーとセキュリティに関する文書がRFC 4902として承認された。
アプリケーション層からはOPESフレームワークの存在はわからない。しかし、アプリケーション固有の追加機能によってフレームを拡張させる作業がHTTPについては終わっており、SMTPについては検討中である。しかし、HTTPやSMTPに適合させたOPESは、OPES本来のデータのやりとりの仕方と根本的に異なり、既存のOPESに関する要件やOPESに対するIABの検討事項が、SMTPの適合に関して相応しいか再検討すべきであるということになった。そこでRFC 4902はSMTPとOPESシステムに適合させたメッセージの完全性、OPESフレームワークをSMTPに適合させた場合のプライバシーとセキュリティに関する問題について分析している。また、OPESのSMTP適合に関する文書を作成する場合に検討されるべき要件についても列挙している。
RFC 4902の目的は現行のOPES作業部会が解散する前にこうした情報を収集することである。今後、OPESのSMTP適合に関する後継の作業部会や個別の開発者のとっかかりとなる。
Rajeev Koodli（ノキアシーメンスネットワークス）
Mark Delany（Yahoo!）
DomainKeysに関する歴史的文書がRFC 4870として承認された。
DomainKeysは電子メール公開鍵技術とDNSを用いた電子メール用のドメインレベル認証フレームワークであり、DomainKeysによって送信元と内容を探査できるようになる。RFC 4870はドメインごとに電子メールをデジタル署名するためのフレームワークについて定義している。
DomainKeysフレームワークの最終目的は現在の電子メールのデータ形式やプロトコルの解釈方式に変更を加えることなく、電子メールの送信元と内容がデジタル署名されてから改ざんされないようにし、また改ざんされていないことを確認できるようにすることである。電子メールの改ざんを防止したり、改ざんを検出したりできれば、インターネットメール全体のスパムやフィッシング対策にもなる。
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（シスコシステムズ）
Gunter Van de Velde（シスコシステムズ）、Tony Hain（シスコシステムズ）、Ralph Droms（シスコシステムズ）、Brian Carpenter（IBM）、Eric Klein（テルアビブ大学）
IPv6用のローカルネットワーク保護に関する文書がRFC 4864として承認された。
NAT（Network Address Translation）には多くのメリットがあるが、その最大のメリットである利用可能なアドレス空間の拡大は、IPv6では不要である。しかし、深刻なデメリットが多い一方で、インターネットプロトコルスイートの利便性を高めるような管理やセキュリティ上のさまざまなメリットもある。とはいえ、そもそもIPv6の設計意図にはNATを不要にすることが含まれているのであり、RFC 4864ではIPv6を使ったLNP（Local Network Protection）が、NATと同等かそれ以上のメリットをアドレス変換をせずにどのように実現するのかを示している。
Bob Neal-Joslin（編集担当、ヒューレットパッカード）、Luke Howard（PADL Software Pty）、Morteza Ansari（Infoblox）
LDAP（Lightweight Directory Access Protocol）ベースエージェント用のプロファイルスキーマ設定に関する文書がRFC 4876として承認された。
RFC 4876は大きく2つの部分に分けられる。1つはLDAPを用いたエージェント用のスキーマ、もう1つは同様のディレクトリユーザーエージェント用の、スキーマの使用例である。
属性タイプとオブジェクトクラスの仕様が提示されており、使用例では、DUA（Drectory User Agent）がスキーマを使ってディレクトリデータの位置を判断し、対応する特定のサービス用のパラメータにアクセスしている。さらに使用例では、属性とオブジェクトクラスの対応付けにより、DUAがエンドユーザーの環境に合わせて想定される（デフォルトの）スキーマを再構成できるようにしている。なお、RFC 4876は特定のDUAサービスの構成について述べる将来の文書の骨子となる。
Richard Graveman（RFG Security）、Mohan Parthasarathy（ノキア）、Pekka Savola（CSC/FUNET）、Hannes Tschofenig（ノキアシーメンスネットワークス）
Elwyn B. Davies（コンサルタント）、Janos Mohacsi（NIIF/HUNGARNET）
ファイアウォールにおけるICMPv6（Control Message Protocol version 6）メッセージフィルタリング用の推奨仕様がRFC 4890として承認された。
IPv6に対応するネットワークでは、ICMPv6が幅広い基本的機能を担うため、それぞれの機能を実現するICMPv6のメッセージタイプとオプションも数多く存在する。ICMPv6はIPv6に機能に欠かせない存在だが、ICMPv6メッセージの転送を制御しないことによるセキュリティ上のリスクもいくつか存在する。また、IPv4におけるICMP用のフィルタリング戦略は、規格通りに機能するためには必要ではない、ICMPの補助的な使い道を考慮しているため、そのままでは適用できない。
RFC 4890は、ICMPv6のファイアウォールフィルター構成用の推奨仕様を提供して、ネットワーク機能を維持するためには必要だが、セキュリティ上のリスクがあるために、破棄すべきICMPv6メッセージを伝播できるようにする。
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は、この条件を満たすワイルドカード疑似有線タイプについて定義している。
Henrik Levkowetz、David Meyer、Lars Eggert（ノキア研究センター）、Allison Mankin
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で述べている。
Laurie E. Law（米国家安全保障局国家情報保障研究所）、Jerome A. Solinas（米国家安全保障局国家情報保障研究所）
Nancy Cam-Winget（シスコシステムズ）、David McGrew（シスコシステムズ）、Joseph Salowey（シスコシステムズ）、Hao Zhou（シスコシステムズ）
EAP-FAST（Extensible Authentication Protocol based Flexible Authentication via Secure Tunneling）に関する文書がRFC 4851として承認された。
EAP-FASTとは、TLS（Transport Layer Security ）を使って相互に認証されたトンネルを用いることでピアとサーバー間の安全な通信を確立するためのEAPの1方式である。トンネル内では、TLV（Type-Length-Value）オブジェクトを使ってピアとEAPサーバー間の認証情報を伝送する。
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
Raymond Aubin（ノーテルネットワークス）、Marco Carugi（ノーテルネットワークス）、Ichiro Inoue（NTTネットワークサービスシステム研究所）、Hamid Ould-Brahim（ノーテルネットワークス）、Tomonori Takeda（編集担当、NTTネットワークサービスシステム研究所）
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（シスコシステムズ）
Peter Saint-Andre（XMPP Standards Foundation）
Edward Beili（Actelis Networks）
Adrian Farrel（Old Dog Consulting）