S/MIME（Secure/Multipurpose Internet Mail Extensions）におけるスイートB暗号に関する文書がRFC 5008として承認された。
　RFC 5008は、RFC 3851で定義されているS/MIMEにおける米国国家安全保障庁のスイートBアルゴリズムを使うための方法について定義している。

　MSCML（Media Server Control Markup Language）とプロトコルについての文書がRFC 5022として承認された。
　MSCMLとは、SIPとともに用いて、先進的なカンファレンスとIVR（Interactive Voice Response：音声自動応答）を実現するためのマークアップ言語である。MSCMLが表現するのは装置レベルの制御モデルではなく、アプリケーションレベルの制御モデルであり、IETFのSIPカンファレンスフレームワークにおいて、カンファレンスフォーカスとミキサー間の通信を実現するために利用できる。

　検索方式に関する頑強な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には将来の研究用の推奨仕様も含まれる。

　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から引用されたものである。

　OMA PoC（Open Mobile Alliance Push to Talk over Cellular）用のSIP（Session Initiation Protocol）のPアンサー状態ヘッダー拡張の仕様がRFC 4964として承認された。
　RFC 4964はOMAのPoCアプリケーションに限定される、SIPのプライベートヘッダー（Pヘッダー）について述べている。Pアンサー状態ヘッダーは特定のPoCアプリケーションがハンドセットの応答モードを示すために用いる。

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

　デュアルスタックモビリティについての問題提起が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に対応するプロファイルの鍵を提供するために使われる。

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

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

　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、ネットワークの研究開発コミュニティ全体が不要なトラフィックに対抗する効果的な対策を開発しうるかについて、工学的および研究上の話題を見定めることもワークショップの目的である。

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

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

　偽造攻撃からTCPを守ることについての文書がRFC 4953として承認された。
　インターネット基盤の中心部分への攻撃の可能性に関する最近の分析は、偽造された送信元IPアドレスで送信される偽造されたリセットフラグ（RST）に関するTCPコネクションの脆弱性を狙った攻撃が増えていることを示している。
　TCPはこれまでもこうしたRSTフラグの偽造攻撃にさらされやすく、RSTフラグがオンのパケットの連番が受信側ウィンドウサイズよりも小さいかどうかを検査したり、TCPパケットの送信元アドレスやポート番号に矛盾がないかなどを調べて、間接的に偽造がどうかを見抜いていた。
　しかし、BGPルーターやWebサーバーと大規模キャッシュサーバー間のように、トラフィックの多いホストは両端で予測可能なポート番号を用いることがしばしばあり、コネクションの経路のBDP（Bandwidth-Delay Product：帯域幅遅延積）の増分は、経路外の第三者がRSTフラグがオンに偽造したパケットの連番を総当たり式に生成できるほど十分に増加していく。パケットの連番が力ずくで見破られる可能性は帯域幅の二乗で増えることになり、現在の高速ネットワークでは見過ごせない脆弱性になっている。
　RFC 4953はこうした脆弱性があることを示し、トランスポート層での解決案とその課題、既存のネットワーク層での解決策と普及の可能性について議論している。RFC 4953が主に扱っているのは偽造されたTCPセグメントによって起きる脆弱性だが、関連するTCPコネクションに関するICMPの偽造についても議論している。

　高データレート時のIPv4再構築エラーに関する文書がRFC 4963として承認された。
　IPの断片化は現在のインターネットの諸条件下では十分に頑強とはいえない。たとえば高データレートでは、断片化したIPデータグラムの間違った再構築がしばしば起きる場合には、16ビットのIP識別フィールドは十分な長さがあるとはいえない。また、TCPとUDPのチェックサムも、IP層から受け取った壊れたデータグラムを上位層に受け渡すのを防ぐのに十分とはいえない。RFC 4963はこの問題を簡単に再現できるいくつかの実験について述べ、観察から得られた運用上の背景について議論している。

　Softwireの問題を提起刷る文書がRFC 4925として承認された。
　RFC 4925はSoftwire作業部会用に問題提起をとりまとめている。Softwire作業部会では、IPv6のみのネットワーク内のIPv4ネットワークやIPv4のみのネットワーク内のIPv6ネットワークを接続するための発見と制御、カプセル化手法の標準技術を開発中である。Softwire技術は、IPv4/IPv6およびIPv6/IPv4トランザクションの問題を解決するために、既存の標準プロトコルについて明らかにし、必要に応じては拡張することで、複数ベンダー間で相互利用可能な実装を促すことになる。RFC 4925は「ハブとスポーク」「メッシュ」と呼ばれる特定の問題と、Softwire作業部会で開発中の技術でどのように解決されるかについて述べている。また、問題範囲をより特定して述べるために、いくつかの要件と、要件にならない事項についても明らかにしている。

　国際化電子メールの概要とフレームワークの文書がRFC 4952として承認された。
　世界中の人々が電子メールを使えるようになるには、各自の名前がそれぞれの言語と文字でメールアドレス中のメールボックス名として正しく表記される必要がある。RFC 4952は国際化メールアドレスに完全対応させるのに必要なメカニズムとプロトコル拡張を定義している一連の仕様をひとまとめにしている。こうした変更には、UTF-8データに適応させるSMTP拡張およびメールヘッダーの文法の拡張も含まれる。またRFC 4952は国際化電子メールを普及させる際の大前提や問題についても述べている。

　NAT-PT（Network Address Translator - Protocol Translator）のステータスを歴史的に変更する理由についての文書がRFC 4966として承認された。
　RFC 4966はRFC 2766で定義されたNAT-PTで実装されたある種のIPv6-IPv4プロトコルの変換メカニズムに固有の問題について議論している。この問題は十分に申告であり、RFC 2766はもはや汎用的変換メカニズムとしては相応しくなく、RFC 4966はRFC 2766のステータスを標準化過程から歴史的に変更するように推奨している。

　インターネットの透過性に関して検討した文書がRFC 4924として承認された。
　RFC 4924はインターネットの透過性に関するIABの以前の声明と、新たになされた透過性に関する問題についての再検討である。ネットワークの透過性を意図的にあるいは意図せず妨げることと、インターネットのイノベーションへの対応や全地球的通信機能を専門的に検討すると、両者は無関係どころか、透過性を妨げることが重要な役割を果たしていることがわかる。RFC 4924はインターネットの透過性の原則が破られることが影響を与えそうないくつかの特徴的事例を示している。

　リソース予約対応ルーター用ベンチマーク用語についての文書がRFC 4883として承認された。
　RFC 4883の最大の目的はIntServ（Integrated Services）IPルーターのリソース予約シグナリングのベンチマークに固有の用語を定義することである。IntServ IPルーターのベンチマーク用語は、リソース予約やベンチマーク指標のレポート形式に対応するルーター用ベンチマーク方法を定義する別の文書でも用いられる。

　単一管理ドメインにおけるETS（Emergency Telecommunications Services：緊急時通信サービス）用のフレームワークについての文書がRFC 4958として承認された。
　RFC 4958は単一管理ドメインにおけるETS対応の候補技術と考えられるさあざまなプロトコルやメカニズムの役割について議論するフレームワークを示している。読者に対して、どのような使い方が可能なのかと実際の使われ方について解説していおり、特定のソリューションを示しているわけではない。

　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プロトコルを含むアドレス管理用のプロトコルとの関係について述べている。

　NEMO（Network Mobility）経路最適化ソリューションスペース分析に関する文書がRFC 4889として承認された。
　現行のNEMO基本対応では、モバイルネットワークが外部にある場合、モバイルネットワークノードとのすべての通信はモバイルルーターとホームエージェント間（MRHA：Mobile Router and Home Agent）トンネルを通らなければならない。そのため、ほとんどの場合、パケットの経路が長くなったり、遅延を引き起こしたりする。こうした制限を乗り越えるには、NEMOの経路最適化（RO：Route Optimization）を使うことになる。RFC 4889はNEMOにおけるさまざまな経路最適化タイプについてまとめており、長所と、NEMO経路最適化とは異なる面でのトレードオフについて述べている。

　NEMO（Network Mobility）経路最適化に関する問題を提起する文書がRFC 4888として承認された。
　現行のNEMO基本対応には、モバイルネットワークが移動先にある場合、モバイルネットワークノードとの通信はすべて、モバイルルーターとホームエージェント間で確立される双方向のトンネルを通らなければならない。この最適とはいえないルーティングは、遅延の増大とトラフィックの輻輳につながるボトルネックリンクといったパケットの遅延に起因するさまざまな不効率を引き起こし、ついにはモバイルネットワークノードとのすべての通信が妨害されかねない。さらに、モバイルネットワークをつなぎ合わせた環境では、こうした不効率が複合し、特定の構成ではトラフィックの膠着状態を引き起こしかねない。RFC 4888はこうした問題を捉えて、NEMO用の経路最適化の必要性を説いている。

　NEMO（Network Mobility）ホームネットワークモデルについての文書がRFC 4887として承認された。
　RFC 4887はNEMO基本対応に適合する、NEMO対応モバイルルーター向けのホームネットワークを普及させる際の利用パターンや付随する諸問題を文書にまとめている。また、NEMO関連のメーリングリストで議論された、ホームネットワークの構成例を提供することもRFC 4887の目的である。

　NEMO（Network Mobility）対応の目標と要件についての文書がRFC 4886として承認された。
　NEMOでいう移動ネットワークとは、あるネットワークをインターネットに接続するルーターがインターネットへの接続点を順次切り替えることであり、固定ネットワークと移動ネットワークの接続が順次切り替わるために、接続上の問題が起きる。こうしたタイプのネットワークを移動ネットワークと呼び、適切なメカニズムがあれば、移動ネットワーク内のノード間のセッションは維持され、移動ルーターがインターネットへの接続点を変えても、インターネット全体では接続が維持される。RFC 4886はNEMO対応に期待される目標を概観し、NEMO対応から見積もった目標を定め、NEMO基本対応ソリューションに適合するはずの要件を定義している。

　NEMO（Network Mobility）対応用語の文書がRFC 4885として承認された。
　RFC 4885はNEMOに関する問題と解決策の要件について議論する際の用語を定義している。

　RFC編集者への独自提出についての文書がRFC 4846として承認された。
　インターネットの技術コミュニティには、IETF（Internet Engineering Task Force）が設立される以前から、IETFの標準化過程およびその査読と承認メカニズムに根ざさない文書をRFCとして発行する伝統がある。「独自提出」と呼ばれるこうした文書はインターネットの技術コミュニティ（IETFで活動中の提出者である場合とそうでない場合がある）に対して、いくつもの重要な機能を担っている。
　RFC 4846は独自提出モデルとその重要性について議論している。その上で、IETFの技術コミュニティと独自提出文書の発行者との新しい関係が前進するように、独自提出文書で用いられる編集上および発行までの工程上の規範について述べている。

　IAB（Internet Architecture Board）によるRFC発行課程についての文書がRFC 4845として承認された。
　IAB自身が文書をRFCとして発行することがある。RFC 4845は、IABが著者となる文書がRFCにおいてどのように執筆され、査読され、発行されるかについて定義している。

　RFCとRFC編集者に関する文書がRFC 4884として承認された。
　RFC 4884はRFCとRFC編集者の役割に関するフレームワークについて述べている。インターネットの技術コミュニティが成長したため、組織化されたコミュニティにおける一般メンバーとの関わり方や一般メンバーへの説明責任といった原則を取り入れる必要が生じた。このフレームワークによって、RFCは今後もその役割を果たし続けることになる。

　GEANT用のURN名前空間に関する文書がRFC 4926として承認された。
　RFC 4926はGEANT（Consortium of European Academic and Research Networks）によって定義されるリソースや計画、活動、作業部会その他の恒久的名付け用に、DANTE（Delivery of Advanced Network Technology to Europe）によって管理されるURN名前空間について述べている。

　クレジットフローとリンク指標用のPPPoE拡張に関する文書がRFC 4938として承認された。
　RFC 4938はPPPoEプロトコルを拡張して信用に基づくフロー制御メカニズムとリンク品質指標レポートを実現する。オプション拡張はモバイル電波リンクのような可変帯域幅の限定バッファリング媒体上のPPPoEの性能の改善するはずである。

　PPPoE（PPP over Ethernet）に関するIANAの検討文書がRFC 4937として承認された。
　RFC 4937はPPPoEプロトコルについてIANAの検討事項について述べている。

　オープンモバイルアライアンスのBCAST LTKM/STKM伝送用のMIKEY（Multimedia Internet KEYing）汎用拡張ペイロードに関する文書がRFC 4909として承認された。
　RFC 4909はMIKEYの新しい汎用拡張ペイロード（RFC 3830）の仕様を定めて、OMA（Open Mobile Alliance）のBCAST（BAC Broadcast）グループのサービスとコンテンツ保護仕様で定義されたSTKM（Short-Term Key Message）とLTKM（Long-Term Key Message）を伝送できるようにする。

　エリア間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通信プロトコルの要件を補っている。

　マルチリンクサブネットの問題に関する文書がRFC 4903として承認された。
　いくつかのプロトコルが、サブネットはルーターによって接続された複数のリンクにまたがるという考えに基づいて発行されている。RFC 4903はそうしたアプローチには潜在的な問題があることを文書化している。

　ネームサーバーインスタンス識別メカニズムの要件がRFC 4892として承認された。
　DNSエニーキャストや負荷分散その他のメカニズムにより、1つのIPアドレスを複数のDNSサーバーで共有できるようになったため、ある問い合わせに対して、一群のDNSサーバーのうちのどれが応答したのかを特定するのが困難になっている。特に管理者がネットワークの障害を診断するような場合、ある問い合わせに対して、どのネームサーバーが応答したのかを識別するメカニズムが標準化されているのは有用である。しかし、こうした必要性から生じた既存のメカニズムは間に合わせであり、いくつかの欠点がある。しかも、この問題に関する従来の分析には、ネームサーバーインスタンスの識別メカニズムがどのように設計され、どのように適用するのかという視点が欠けている。そこでRFC 4892はDNSプロトコルの広く普及した実装に見られる既存の方法について、その長所と短所を述べ、改良方法の属性について議論している。

　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）経由で実行される。

　リンク指標についての設計上の意味に関する文書がRFC 4907として承認された。
　RFC 4907はインターネットのアーキテクチャにおけるリンク指標の役割について述べている。リンク指標は、リンク層から上位層に対してリンクの状態に関する情報を表している。各種のリンク指標を上手に使えばパフォーマンス上のメリットがある一方で、下手な使い方をすると頑強さやパフォーマンスを劣化させることになる。RFC 4907は現行プロトコルのリンク指標を要約し、設計上の問題について述べ、リンク指標に関する適切または不適切な使い方にいついての例を示している。

　IKE（Internet Key Exchange）およびIPsecにおけるハッシュアルゴリズムの使用に関する文書がRFC 4894として承認された。
　RFC 4894はIKEv1とIKEv2、IPsecプロトコルがどのようにハッシュ機能を使うかについて述べている。また、MD5およびSHA-1アルゴリズムの劣化した衝突耐性について、こうしたプロトコルの脆弱性がどのような水準にあるのかについても説明している。

　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適合に関する後継の作業部会や個別の開発者のとっかかりとなる。

　IPアドレスの位置情報に関するプライバシーとモバイルIPv6について問題を提起する文書がRFC 4882として承認された。
　RFC 4882は、モバイルIPv6に関する位置情報のプライバシーについて議論されている。ホームアドレスが第三者に漏れたときや気付けアドレスが通信相手に明らかになったときの問題についてまとめている。

　IPv6用のローカルネットワーク保護に関する文書がRFC 4864として承認された。
　NAT（Network Address Translation）には多くのメリットがあるが、その最大のメリットである利用可能なアドレス空間の拡大は、IPv6では不要である。しかし、深刻なデメリットが多い一方で、インターネットプロトコルスイートの利便性を高めるような管理やセキュリティ上のさまざまなメリットもある。とはいえ、そもそもIPv6の設計意図にはNATを不要にすることが含まれているのであり、RFC 4864ではIPv6を使ったLNP（Local Network Protection）が、NATと同等かそれ以上のメリットをアドレス変換をせずにどのように実現するのかを示している。

　LDAP（Lightweight Directory Access Protocol）ベースエージェント用のプロファイルスキーマ設定に関する文書がRFC 4876として承認された。
　RFC 4876は大きく2つの部分に分けられる。1つはLDAPを用いたエージェント用のスキーマ、もう1つは同様のディレクトリユーザーエージェント用の、スキーマの使用例である。
　属性タイプとオブジェクトクラスの仕様が提示されており、使用例では、DUA（Drectory User Agent）がスキーマを使ってディレクトリデータの位置を判断し、対応する特定のサービス用のパラメータにアクセスしている。さらに使用例では、属性とオブジェクトクラスの対応付けにより、DUAがエンドユーザーの環境に合わせて想定される（デフォルトの）スキーマを再構成できるようにしている。なお、RFC 4876は特定のDUAサービスの構成について述べる将来の文書の骨子となる。

　IPv6-in-IPv4トンネルを安全にするためのIPsecの使用に関する文書がRFC 4891として承認された。
　RFC 4891は、IPsecのトランスポートモードを用いて、手動で構成されたIPv6-in-IPv4トンネルを安全にするためのガイダンスである。IPsecフレームワークの範疇を超えるようなプロトコルの追加的な拡張などは一切議論されていない。

　ファイアウォールにおけるICMPv6（Control Message Protocol version 6）メッセージフィルタリング用の推奨仕様がRFC 4890として承認された。
　IPv6に対応するネットワークでは、ICMPv6が幅広い基本的機能を担うため、それぞれの機能を実現するICMPv6のメッセージタイプとオプションも数多く存在する。ICMPv6はIPv6に機能に欠かせない存在だが、ICMPv6メッセージの転送を制御しないことによるセキュリティ上のリスクもいくつか存在する。また、IPv4におけるICMP用のフィルタリング戦略は、規格通りに機能するためには必要ではない、ICMPの補助的な使い道を考慮しているため、そのままでは適用できない。
　RFC 4890は、ICMPv6のファイアウォールフィルター構成用の推奨仕様を提供して、ネットワーク機能を維持するためには必要だが、セキュリティ上のリスクがあるために、破棄すべきICMPv6メッセージを伝播できるようにする。

　作業部会の最終招集からIETF文書発行までの工程管理に関する文書がRFC 4858として承認された。
　公開までの工程管理は、従来、それぞれの作業部会を担当するIESGのエリアディレクターが担っていた。RFC 4858はIETF文書の発行までの工程を改善し、日程を早めるために考えられた方法論について述べている。RFC 4858が定めている一連の手続きは、公開のためにIESGに対して提出された文書に関する主要な工程管理規則として、作業部会長またはRFC発行に関わる事務局が用いる。

　IPsec用のスイートB暗号スイートに関する文書がRFC 4869として承認された。
　RFC 4869はRFC 4308が2つの暗号スイートを提示しているように、IPsec用に4つの暗号UIスイートのオプションを提示している。新しい4つの暗号スイートは、合衆国国家安全保障局のスイートB仕様と互換性がある。

　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サーバー間の認証情報を伝送する。

　レイヤー1VPN（L1VPN）のフレームワークと要件をまとめた文書がRFC 4847として承認された。
　RFC 4847はL1VPNのフレームワークとサービスレベル要件を提供している。フレームワークは、互換性のあるL1VPNに対応するためのプロトコルやメカニズムの開発と標準化を助けるのが目的である。
　RFC 4847は、L1VPNの契機や高レベル（サービスレベル）での要件を調べて、L1VPNを構築するのに使われるかもしれないいくつかの設計モデルの概要を示している。

　XMPP（Extensible Messaging and Presence Protocol ）拡張用のURN（Uniform Resource Name）名前空間に関する文書がRFC 4854として承認された。
　RFC 4854はXMPPを拡張し、XSF（XMPP Standards Foundation）によって仕様が定められたXML形式とプロトコルを重複せずに特定するためのURN名前空間について述べている。

　RSVP-TE（Resource Reservation Protocol-Traffic Engineering）セッション属性オブジェクトにおけるフラッグフィールド用のコードポイント登録に関する文書がRFC 4859として承認された。
　RFC 4859はMPLSおよびGMPLSのシグナリングで用いるRSVP-TEシグナリングメッセージのセッション属性オブジェクト内のフラッグフィールド用に新しいコードポイントを登録することをIANAに指示するための文書である。

　OPF（OEBPS Package File）用メディアタイプの登録に関する文書がRFC 4839として承認された。
　RFC 4839は、OEBPS（Open eBook Publication Structure）用のパッケージファイルのメディアタイプを登録するための文書である。

　MPLSトラフィックエンジニアリング用のLSP先取ポリシーに関する文書がRFC 4829として承認された。
　優先度の高いTE LSP（Traffic Engineering Label Switched Path）の確立で優先度の低いTE LSPの先取が必要な場合、ノードは個別にどのTE LSPを選ぶか判断しなければならない。先取されたLSPは個別に通信事業者側のLSR（Label Switch Router）の経路となる。
　RFC 4829は柔軟な先取ポリシーを示して、異なる目的で利用できるようにしている。

・優先度がもっとも低いLSPを先取
・もっとも少ない数のLSPを先取
・先取するTE LSP用に必要な帯域幅にもっとも近いTE LSPを先取（なるべく帯域幅の無駄を省くのが目的）
・もっとも経路の再構成（reroute）がしやすいLSPを先取

　RFC 4829はシミュレーション結果やいくつかの異なるポリシーとの比較を示し、先取のカスケードについても、先取LSPの数や優先度、無駄になった帯域幅、ブロックする可能性に言及している。

　インターネット上の安全なピアトゥピア型ビジネスデータ交換用のFTP（File Transfer Protocol）伝送に関する文書がRFC 4823として承認された。
　RFC 4823は、XMLやバイナリー、EDI（Electronic Data Interchange、ANSI X12またはUN/EDIFACT）、MIME準拠のコンテント形式を使ってMIME方式のパッケージ化が可能なビジネストゥビジネスのデータ交換用のその他のデータ形式用に、どのように構造化データを安全にFTPで伝送するかに関する適用性宣言（AS：Applicability Statement）である。認証とデータの完全性はCMS（Cryptographic Message Syntax：暗号メッセージ文法）のS/MIMEによって保護されたデータ本体によって実現される。認証の確認は、元のメッセージに「multipart/signed」の応答を付けることで実現する。

　IPv6企業ネットワークの分析に関する文書がRFC 4852として承認された。
　RFC 4852はIPレイヤー3に注目して企業ネットワークをIPv6に以降させることについて分析している。企業ネットワークの特徴は複数のインターネット接続があり、1社以上のプロバイダに対して、1つ以上のルータで接続しており、ネットワーク運用を担当する部署によって管理されていることである。分析は、説明用の移行ネットワークとIPv6への移行シナリオに関する以前の文書から拡張した要件に重きを置いている。また、デュアルIPレイヤー（IPv4とIPv6）に対応するネットワークとノードが企業にあることを前提に、移行に関する分析に集中して議論されている。その上で、それぞれの説明用ネットワークについて移行メカニズムを推奨している。

　レイヤ3PPVPN（Provider-Provisioned Virtual Private Network：プロバイダ提供型VPN）マルチキャストの要件がRFC 4834として承認された。
　RFC 4834はレイヤ3PPVPNで、IPマルチキャストを実用化するためのネットワークソリューションの機能要件を示している。要件は、エンドユーザーおよびサービス事業者の観点からまとめられている。RFC 4834の目的は、こうしたVPNでIPマルチキャストに対応する可能性のあるソリューションが、要件をガイドラインとして用いることである。

　NETLMM（Network-Based Localized Mobility Management）に関する問題提起がRFC 4830として承認された。
　エッジ側モビリティ制御はIETFでよく知られた概念であり、すでにいくつかのソリューションが存在する。RFC 4830は既存のソリューションの主要な欠点を注視し、すべてのソリューションでモビリティ制御にホストを関係させていることを発見し、NETLMM問題の事例を述べている。

　NETLMM（Network-Based Localized Mobility Management）の目標に関する文書がRFC 4831として承認された。
　RFC 4831はNETLMMの設計上の目標について議論している。

　NETLMM（Network-Based Localized Mobility Management：エッジノード・モビリティ制御）に対する安全上の問題に関する文書がRFC 4832として承認された。
　RFC 4832はNETLMMに対する安全上の問題について議論している。
　この問題は2カ所で起こりうる。第1にローカル側モビリティアンカーとモバイルアクセスゲートウェイ間、第2にモバイルアクセスゲートウェイとモバイルノード間である。第1の問題はNETLMMプロトコルそのものに影響を与える。

　耐遅延性ネットワークアーキテクチャに関する文書がRFC 4838として承認された。
　RFC 4838は耐遅延性、耐妨害性ネットワークのアーキテクチャについて述べている。耐遅延性ネットワークアーキテクチャは、深宇宙探査への対応における惑星間級の長距離でインターネット的なサービスを実現するための通信システムとして計画された「惑星間インターネット」に端を発し、進化したものである。
　RFC 4838は、インターネットに代表的な従来のネットワーク技術の手法が適用できなかったり、実用にならないような、運用上および性能上の特性の問題を対処する耐遅延性ネットワークアーキテクチャについて述べている。執筆者たちは、相互接続したネットワークを伝送層などに用い、その上で動作するメッセージ指向のオーバレイネットワークを定義した。RFC 4388は耐妨害性ネットワーク開発の端緒や概要、運用に必要な状態管理に関する所見、アプリケーション設計に関する論点について議論している。
　

　多重カプセル化方式の危険性に関する文書がRFC 4840として承認された。
　RFC 4840はIPの多重カプセル化方式に対応するリンク層プロトコルに起因するアーキテクチャおよび運用上の問題について述べている。

　IP over SFSSの伝送に関する文書がRFC 4824として笑認された。
　RFC 4824はSFSS（Semaphore Flag Signal System：手旗信号体系）上でIPv4/IPv6パケットをカプセル化し伝送するための方法について述べている。

　ネットワーク機器ベンチマーキングの見落とされている要因に関する文書がRFC 4814として承認された。
　テストエンジニアにとって、所期の負荷パケットの長さやテスト時間、トラフィックの向きといった計測に影響を与えるすべての要因を明らかにするのは骨の折れる作業である。しかし、現在のベンチマーキングの実態では、テスト結果に大きな影響を与える2つの要因を見逃している。
　第一に、既存の方法では、テスト結果に影響する可能性があるにもかかわらず、アドレスやトラフィックの内容などを報告する必要がない。第二に、リンク層技術によって詰め込まれるビット列やバイトデータも無視できないほどのサイズがあり、あらかじめどのようなオーバーヘッドになるのかわからず、ひいてはテスト結果に影響を与えてしまう。
　RFC 4814はこうした要因の影響について述べ、テストトラフィックの内容に関するガイドラインを推奨し、ビット列におけるビット列やバイトデータの影響の度合いを測る公式を提示している。

　長期保管サービスの要件に関する文書がRFC 4810として承認された。
　データの長期保管サービスのユーザーが、必要時にある時点でデータが存在したことを証明できなければならなかったり、データがある時点から改ざんされていないことを、データが存在した時点から証明するまでの間隔が非常に開いている場合でも示せなければならなかったりする場面はいくつか考えられる。さらに、データをデジタル署名してからユーザーが署名の有効性を確認するまでに長い年月が経っている場合もある。RFC 4810は、こうした場面に対応するある種の長期データ保管サービスと、そうしたサービスを利用するための技術的要件について述べている。

　OSPF（Open Shortest Path First）のルーター分離型LSDB（Link State Database）再同期に関する文書がRFC 4811として承認された。
　OSPFはIPネットワークで使われるリンクステート型のドメイン内ルーティングプロトコルである。OSPFにおけるLSDBの再起動には、OSPFルーターがネットワークに接続されたときの「初期LSDB同期」と、初期化手続き終了後に、トポロジーの変化に対するLSDBの持続的同期を確認するための「非同期フラッディング」という2つの方式がある。OSPFルーターは場合によってはLSDBを再同期する必要があるが、OSPFの規格はネットワークのトポロジーが実際に変化したときしか再同期を認めていない。
　RFC 4811は、ルーター分離型LSDB再同期のベンダー固有のメカニズムについて述べている。RFC 4811で述べられているメカニズムはRFC 3623で述べられているOSPFの「段階的再起動」として誕生し、1社以上の大手ベンダーによって実装／対応されている。RFC 4811の目的は、インターネット全体にこのメカニズムを知らせるため、技術の詳細を明らかにすることである。ただし、このメカニズムはIETFによる規格ではない。

　OSPF（Open Shortest Path First）再起動シグナリングに関する文書がRFC 4812として承認された。
　OSPFはIPネットワークで使われるリンクステート型のドメイン内ルーティングプロトコルである。ルーターは、「Hello」サブプロトコルによって、新しい、あるいは到達できない近隣ルーターを見つける。また、OSPFの「Hello」パケットは時間内で両方向の通信が可能かどうかを確認するためにも使われる。また、ルーターがOSPFプログラムを再起動すると、ルーターは近隣ルーターがわからなくなる。この場合、ルーターが「Hello」パケットを送信して、近隣ルーターが隣接情報をリセットすることになるが、このような挙動はある種の条件では望ましくない。
　RFC 4812は、OSPFルーターが近隣ルーターに対して再起動プロセスにあることを通知できるようにするベンダー固有のメカニズムについて述べている。ただし、このメカニズムは再起動するルーターだけではなく、その近隣ルーターも対応していなければならない。
　RFC 4812で述べられているメカニズムはRFC 3623で述べられているOSPFの「段階的再起動」として誕生し、1社以上の大手ベンダーによって実装／対応されている。RFC 4812の目的は、インターネット全体にこのメカニズムを知らせるため、技術の詳細を明らかにすることである。ただし、このメカニズムはIETFによる規格ではない。

　TCP-MD5用の鍵交換戦略に関する文書がRFC 4808として承認された。
　TCP-MD5オプションはルーター間でBGPセッションを安全にするために広く使われている。しかし、異なる組織との同期が必要になるため、長期間にわたって使われる鍵を変えるのは難しい。そこでRFC 4808では、非同期で鍵を変更できる「一方的戦略」について述べている。

　侵入検知メッセージ交換の要件に関する文書がRFC 4766として承認された。
　IDMEF作業部会（IDWG）の目的は、データ形式を定義して侵入検知と対応システム、それらを操作する管理システムにとって重要な情報を共有するための手続きを交換することである。
　RFC 4766は、説明な必要な場合は理論的根拠を示して、通信メカニズムなどの高水準要件について述べている。いくつかの要件については、シナリオを使って例示している。

　IPsec（Internet Protocol Security）証明書管理プロファイルの要件に関する文書がRFC 4809として承認された。
　RFC 4809は、IKE（Internet Key Exchange）のバージョン1および2を使ったIPsec VPN（Virtual Private Network）システムとPKI（Public Key Infrastructure）システム間でPKC（Public Key Certificate）ライフサイクルトランザクションを扱うための処理の要件について述べている。この要件は、企業規模のIPsec VPNの実運用上のニーズに適合するように設計されている。こうした多くの要件を明らかにするために、管理プロトコルの標準化提案プロファイルの作成が意図されている。

　EAP-POTP（EAP Protected One-Time Password Protocol）に関する文書がRFC 4793として承認された。
　RFC 4793はOTPトークンとともに用いるのに適した汎用的なEAP（Extensible Authentication Protocol）方式について述べ、関連するクライアントへの電気的な直接のインターフェイスを持つトークンの特定の利点を提示している。この方法は、一方向または両方向の認証、鍵生成の元データとして、PPPやIEEE 802.1X、IKEv2（Internet Key Exchange Protocol Version 2）などEAPを利用するプロトコルで使える。

　モバイルIPv6の経路最適化を促進する方法の分類と分析に関する文書がRFC 4651として承認された。
　RFC 4651は、この分野の研究を深めるために、既存の提案を元にモバイルIPv6の経路最適化を促進させる戦略を説明し、評価している。RFC 4651は、IRTFのIPモビリティ最適化（MobOpts）研究部会の成果物である。

　H.263用RTPペイロード形式を定めたRFC 2190を「歴史的」に変更することに関する文書がRFC 4628として承認された。
　ITU-T（ITU Telecommunication Standardization Sector）勧告であるH.263のRTPペイロード形式を最初に定めたRFCはRFC 2190である。RFC 4628ではRFC 2190をどうして「歴史的」に変更するかの理由を述べている。

　ISP（Internet Service Provider）環境におけるセキュリティ実態に関する文書がRFC 4778として承認された。
　RFC 4778は大規模ISPで運用されているレイヤー2およびレイヤー3の基盤的機器の安全面での実態に関する調査報告である。ここであげられている情報は、ISP環境で基盤の安全を定義および実装する責任者から直接得た情報が元になっている。

　LLMNR（Link-local Multicast Name Resolution：リンクローカルマルチキャスト名前解決）の目的に関する文書がRFC 4795として承認された。
　LLMNRの目的は、従来型のDNSによる名前解決が利用できない場合に名前を解決できるようにすることである。LLMNRはDNSとは別のポートで実行し、独立したリゾルバーキャッシュを保持する一方で、現在そして将来のすべてのDNSメッセージ形式やレコード型、クラスに対応する。ただし、LLMNRはリンクローカルでのみ実行されるため、DNSの代用にはならない。

　BGP/MPLS IP VPN（Virtual Private Network）におけるPE-PE（Provider Edge to Provider Edge）GRE（Generic Routing Encapsulation）またはIPの利用に関する文書がRFC 4797として承認された。
　RFC 4797はもっとも外側のMPLSラベル（トンネルラベルなど）が1つのIPヘッダーまたはGRE付きのIPヘッダーに置き換わるBGP/MPLS IP VPNの実装戦略について述べている。
　RFC 4797で述べられている実装戦略によって、エッジ側装置がMPLSとVPNに対応しているが、その内部の装置は対応していないネットワークにBGP/MPLS IP VPN技術を導入できるようになる。

　ブロードバンドアクセスネットワークにおけるISPのIPv6普及シナリオに関する文書がRFC 4779として承認された。
　RFC 4779は既存のIPv4と共存する現在のサービスプロバイダーのブロードバンドネットワークにおけるIPv6の普及と統合の方法およびシナリオの詳細を説明している。RFC 4779で議論されているのは、主要なブロードバンド技術として現在普及しているケーブル／HFC（Hybrid Fiber and Coaxicial：光ファイバーと同軸ケーブルの併用）、ブロードバンドEthernet、xDSL、無線LANはもちろん、最近注目を集めているPLC/BPL（Broadband Power Line Communications）についても言及されている。RFC 4779では、IPv6ブロードバンドネットワークの主要部分およびIPv4ブロードバンドネットワークとの相違、トンネリングメカニズムやネイティブIPv6といった技術を用いて、IPv6をどのように普及させ、併用するかについても議論している。

　IKE（Internet Key Exchange）およびIKEv2（Key Exchange version 2）用のECPグループの仕様がRFC 4753として承認された。
　RFC 4753はすでに定義されているグループに加えて、IKEおよびIKEv2で利用する新しいECC（Elliptic Curve Cryptography）グループについて述べている。特に、新しい楕円グループは2進数よりも剰余演算に基づいている。また、新しいグループはIKEおよびIKEv2と他のECC実装および標準（特にNIST標準）を結びつけるために定義されている。さらに、RFC 4753で定義された楕円は、すでに定義されているECCグループよりも効率的な実装である。

　DES（Data Encryption Standard）を使ったセキュリティの意味を解説する文書がRFC 4772として承認された。
　DESは、ある程度の資金がある攻撃者には十分に手が届くほどブルートフォース攻撃によって暗号を解読されやすい。したがって、DESの利用は控えるべきであり、AES（Advanced Encryption Standard）への移行が進んでいる。もちろん、DESの利用がつねに不適切とまではいえないが、アプリケーションによっては安全性をDESに依存していることがあり、新規アプリケーションでもDESに対応するプロトコルのデザイナーやアプリケーションの実装者がいる。
　そこでRFC 4772では、DESを使ったセキュリティの意味を詳細に議論し、プロトコルのデザイナーやアプリケーションの実装者がDESの利用について、賢明に判断できるようになすべての情報を提供している。

　IANA特定目的IPv6アドレスブロックの管理に関する文書がRFC 4773として承認された。
　RFC 4773は、IANA特定目的IPv6アドレス割り当て登録の管理に関して、IANAに指示を与えるための文書である。

　インターネットDoS（Denial of Service）攻撃に関して検討した文書がRFC 4732として承認された。
　RFC 4732はインターネットシステムに対するDoS攻撃について、その考えられる手法の概要を提供している。RFC 4732の目的は、プロトコルデザイナーとネットワークエンジニアがプロトコルやネットワークをより頑強に設計するように促すことである。また、完璧ではないものの、攻撃の効率を下げる解決策や、ある種の解決策は、別の脆弱性をもたらしかねないことが議論されている。

　メディアタイプとして「audio/mobile-xmf」を登録する文書がRFC 4723として承認された。
　MMA（MIDI Manufacturers Association）とAMEI（Association of Musical Electronics Industry）は、モバイルMIDIアプリケーション用の技術として、モバイルXMF規格を作成した。モバイルXMFは非常にコンパクトなメディアタイプであり、高品質のシンセサイザーオーディオコンテンツを実現する。音楽のダウンロードやメッセージングアプリケーションで用いるために、MIMEの登録を必要とする。そこでRFC 4723で「audio/mobile-xmf」メディアタイプを登録する。

　GSS-API（Generic Security Services API）バージョン3の「名前」に望まれる拡張に関する文書がRFC 4768として承認された。
　GSS-APIは、名前に基づく認証に対応する名前機能を実現している。GSS-APIにより、名前を持つ両者がお互いに認証できるようになる。認証の可否を判断するために、名前はACL（Access Control List：アクセス制御リスト）に格納できる。したがって、GSS-APIの次のバージョンでは、セキュリティメカニズムにおける機能追加においても、実装者がGSS-APIを使いたくなる用途においても、名前機能は拡張される必要がある。
　人事異動や改姓など、GSS-APIによって認証される名前は同じとは限らないため、名前以外の持続的なIDを使った方がACLを安定して利用できるようになる。公開鍵メカニズムのように、すべての環境で1つの名前が使われないメカニズムがある一方で、Kerberosのように、認証の一部に所属グループや役割情報を含めるメカニズムもある。RFC 4768は、GSS-APIの名前機能への拡張を促進するとともに、現在議論されている拡張仕様について述べている。

　GMPLS（Generalized MPLS）の警告情報のやりとりの仕様がRFC 4783として承認された。
　RFC 4783は、GMPLSシグナリングを拡張して警告情報のやりとりに対応させる仕様について述べている。GMPLSシグナリングはすでに警告レポートの制御には対応しているが、警告情報のやりとりには対応していない。そこでRFC 4783は、機能面での説明とGMPLS-RSVPにおける拡張仕様を述べている。また、RFC 4783はRSVP ERROR_SPECオブジェクトの改訂についても提案している。
　RFC 4783によって、新しいオプションが追加されるため、「GMPLSシグナリングRSVP-TE拡張」（RFC 3473）は更新される。ただし、RFC 3473で定義された手続きについては何の変更もなく、後方互換性を保っている。
　

　マイクロソフトWindowsで使われているRC4-HMAC Kerberos暗号化型式に関する文書がRFC 4757として承認された。
　マイクロソフトのWindows 2000のKerberosの実装は、MD5 HMACをチェックサムに用いるRC4暗号アルゴリズムに基づく新しい暗号型式を取り入れている。この型式は、既存のDESに基づく暗号型式の代替となる。
　RC4-HMAC暗号型式は、既存のWindows NT環境からのアップグレードを容易にするために用いられ、128ビットの鍵長に対応する強力な暗号を実現し、合衆国政府の輸出規制要件に合致する。

　RFC 1264の廃止に関する文書がRFC 4794として承認された。
　RFC 1264は、インターネットの有り様が実質的に今日とはまったく異なる時代に公開された文書である。RFC 1264は、当時のインターネットにさまざまな悪影響を与えかねない新しいルーティングプロトコルに対して、インターネットを保護するためのルールを処方している。しかし、今日のインターネットでは不当なプロトコルの実際の普及を妨害するような他の要因がいくつもあり、既存のプロトコルは従っていると考えられるため、RFC 1264のルールはむしろ邪魔になっている。

　CT-KIP（Cryptographic Token Key Initialization Protocol）バージョン1リビジョン1の仕様がRFC 4758として承認された。
　CT-KIPは暗号トークンの初期化と構成用のクライアント／サーバー型プロトコルであり、暗号トークン内の秘密鍵や確立されたPKIも不要なプロトコルである。提供または生成された鍵情報などはサーバーおよび暗号トークンそのものでのみ有効である。
　RFC 4758は、RSA研究所のOTPS（One-Time Password Specifications）仕様群からCT-KIPバージョン1リビジョン1仕様を定めている。知的財産権に関する部分を除くと、RFC 4758の本文はCT-KIPバージョン1仕様に由来している。ただし、改訂版という位置づけであって、IETF査読時のコメントが反映されている。ワイヤー上のビット列の変更はなく、プロトコルはCT-KIPバージョン1.0の仕様と互換性がある。

　ENUM有効化アーキテクチャの仕様がRFC 4725として承認された。
　ENUMドメイン名はE.164番号と強く結びついている。このとき、ENUMドメイン名の登録者が対応するE.164番号の割り当てを受けた者と同一であるかどうかを確認する処理を「検証（Validation）」と呼ばれる。RFC 4725は、検証の要件とENUM検証基盤用の高レベルアーキテクチャについて述べている。

　IBM iSeriesのTelnet拡張の仕様がRFC 4777として承認された。
　RFC 4777はビジネス用コンピュータの中級機ラインであるIBM iSeries上のTelnetサーバーのインターフェイスについて述べている。このインターフェイスにより、TelnetクライアントはTelnet端末やプリンターセッションに対して、デバイス名や暗号、言語サポート、自動サインオン、応答コード、セッションアソシエーションなどに関する特定のセッション属性を用いて要求できるようになる。
　なお、iSeriesのTelnetサーバーで認識されるUSERVEAR変数を新しく定義するために、この拡張仕様でサポートされる機能の実装には、RFC 1572で定められているTelnet環境オプションネゴシエーションが用いられている。
　

　EAP-SAKE（Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment）の仕様がRFC 4763として承認された。
　RFC 4763はSAKE用のEAPメカニズムの仕様を定めている。また、RFC 4763はRFC 3748によるベンダーEAPメソッド用のEAP型のIANA割り当てを文書化ためにも発行された。なお、EAP-SAKEの仕様はIANA割り当て用の指定専門家評価を経ている。

　EAP（Extensible Authentication Protocol）パスワード認証交換に関する文書がRFC 4746として承認された。
　RFC 4746は「EAP-PAX（Password Authenticated eXchange）」と呼ばれるEAPの方式を定義している。EAP-PAXは軽量な共有鍵型の認証プロトコルで、鍵の供給や管理、データの完全性保護、認証によるデータ交換などのオプションに対応している。

　NFC（Near Field Communication）フォーラム用のURN（Uniform Resource Name：定型リソース識別子）名前空間の仕様がRFC 4729として承認された。
　RFC 4729はNFCフォーラムが発行したURNリソース用のNID（Namespace Identifier：名前空間識別子）について述べている。NFCフォーラムはこのURN識別モデルを活用するリソースの定義と管理を担当する。管理業務はNFCフォーラムの技術委員会が実行する。

　ドメイン間MPLS TE（Multiprotocol Label Switching Traffic Engineering）用のフレームワークについて述べたレポートがRFC 4726として承認された。
　RFC 4726はマルチドメインネットワークにおけるMPLSとGMPLS（Generalized MPLS）のTEを確立したり制御したりするためのフレームワークを提供している。
　なお、RFC 4726は、ドメイン間のMPLS/GMPLS TEについて述べるために、「ドメイン」はアドレス管理や最適経路の算出を所管する主体が共通である個々のネットワークの集まり、とみなして議論している。したがってドメインには、IGP（Interior Gateway Protocol）エリアやAS（Autonomous System：自律システム）が含まれる。

　SSH（Secure Shell）公開鍵ファイル形式の仕様がRFC 4716として承認された。
　RFC 4716は、さまざまなSSH実装において公開鍵をやりとりするために用いられている既存の公開鍵ファイル形式を公式に文書化したものである。さらにRFC 4716は、SSH公開鍵のフィンガープリントの標準的なテキスト表記についても定義している。

　インテルPXE（Preboot eXecution Environment）用のDHCP（Dynamic Host Configuration Protocol）オプションの仕様がRFC 4578として承認された。
　インテルが定義したDHCPオプションによって、PXEおよびEFI（Extensible Firmware Interface）クライアントが起動中のクライアントマシンとOSに制御が移る以前の実行環境を重複しないように識別し、DHCPやPXEのブートサーバーが適切なOSの起動イメージ（またはOSに先だって実行されるアプリケーション）の名前やサーバーをクライアントに応答できるようになる。

　「tel」URI用のISDN（Integrated Services Digital Network）サブアドレス符号化型式の仕様がRFC 4715として承認された。
　ISDNサブアドレス符号化型式を示す「tel」URIのパラメーターがないと、ISUP（ISBN User Part）とSIP（Session Initiation Protocol）ネットワークの相互運用が場合によってはできなくなる。この問題を解決するため、RFC 4715は「tel」URIの新しいオプションパラメーターの仕様を定めて、ISDNサブアドレス符号化型式を示せるようにしている。

　MSCML（Media Server Control Markup Language）とプロトコルの仕様がRFC 4722として承認された。
　MSCMLはマークアップ言語の一種で、SIPとともに用いて、より高度なカンファレンス機能やIVR（Interactive Voice Response：音声自動応答装置）機能を実現する。MSCMLで表現されるのはアプリケーションレベルの制御モデルであり、装置レベルでの制御モデルとは異なる。MSCMLを用いると、IETFのIPカンファレンスフレームワークにおいて、カンファレンスフォーカス（カンファレンスを主催するSIPサーバー）とカンファレンスミキサー（カンファレンスのメディアストリームの配信サーバー）間で通信ができるようになる。

　MIDI over RTPの実装ガイドがRFC 4696として承認された。
　RFC 4696は、ネットワーク経由で音楽を実演するアプリケーション向けのアドバイスとして、RTP（Real-time Protocol）上でMIDI（Musical Instrument Digital Interface）データを伝送するための実装ガイド（規格ではない）である。MIDI over RTPのアプリケーションでは、物理的に異なる場所にいる2人の演奏者が、あたかも同じ部屋にいるようにネットワーク経由で楽器を演奏する。
　演奏は、ユニキャスト上のMIDI over RTPセッションを基礎とした上で、RFC 4696ではさらに回復ジャーナル（ペイロード形式用の補正構造）の送受信用アルゴリズムの詳細を述べている。なお、RFC 4696はネットワーク経由での演奏の「出来」つまり遅延などによって演奏を台無しにしないようにすることにについて特に述べているが、実装のアドバイスはMIDI over RTPのアプリケーション全般に適用できる。

　経路情報が緩やかに作られたMPLS（Multiprotocol Label Switching）TE（Traffic Engineering）LSP（Label Switched Path）の再最適化に関する文書がRFC 4736として承認された。
　RFC 4736は経路情報が緩やかに作られたMPLSおよびGMPLS（Generalized Multiprotocol Label Switching） TEの、RSVP-TE（Resource Reservation Protocol Traffic Engineering）で伝えられたLSPを再最適化するメカニズムを定義している。また、TE LSPのヘッドエンド（局側終端）LSR（Label Switching Router）が緩やかなホップまたは絶対ホップとして定義された次ホップを持つすべてのホップに対して新しい経路の再評価を促したり、中間地点のLSRがヘッドエンドのLSRに対して、現在の経路よりも適切な経路が存在することや、TE LSP経路の維持のために、TE LSPを再最適化するように通知するためのメカニズムを提案している。なお、このメカニズムはドメイン内またはIGP（Interior Gateway Protocol）エリアやASのようなドメイン間のパケットおよび緩やかな経路による非パケットのTE LSPに適用される。

　ASON（Automatic Switched Optical Network：自動交換光ネットワーク）ルーティング要件に対する既存ルーティングプロトコルの評価がRFC 4652として承認された。
　GMPLS（Generalized MPLS：汎用GMPLS）用の一連のプロトコルは、さまざまな交換技術ばかりではなく、さまざまなアプリケーションについも制御できるように定義されている。こうしたGMPLSの目的には、SONET/SDH（Synchronous Optical Network/Synchronous Digital Hierarchy）やOTN（Optical Transport Network）を含む、TDMコネクションも含まれる。
　RFC 4652は、ITU-Tで定義されたASON用のルーティング要件に対する、IETFのルーティングプロトコルの評価を述べている。

　ネットワーク層トラフィック制御メカニズムのベンチマーキング用語がRFC 4689として承認された。
　RFC 4689は定義された基準によってパケットを分類するトラフィック制御を実装する装置のベンチマーキング用語について述べている。IPトラフィック制御メカニズムを評価するためにデータプレーンを計測するとき、この用語を適用する。パケット分類のルールは、DSCP（Differentiated Services Code Point）といったIPヘッダーやポート番号などのパケットペイロード内のどのフィールドでも利用できる。

　IKEv2の説明と実装ガイドラインがRFC 4718として承認された。
　RFC 4718は、IKEv2仕様の多くの領域について説明している。プロトコルの内容を変更するわけではないが、実装が曖昧になりがちな点について詳しく述べている。RFC 4718の目的は、互換性のある実装が開発されるようにすることである。

　WebDAV（Web Distinguished Authoring and Versioning）サーバーのマウントに関する文書がRFC 4709として承認された。
　現在のWebブラウザーにはリンクをユーザーがクリックすることでWebDAVサーバーの編集画面を表示させるようにする定型的な方法がない。たとえば、リンクをクリックするとウィンドウが開き、WebDAVサーバーに保存されたリソースをドラッグアンドドロップで操作するようなことはできない。
　そこでRFC 4709は、WebDAVサーバーにマウント情報をクライアントに送信させるためのメカニズムとデータ形式を定めている。このメカニズムはどのプラットフォームでも、どのWebDAVクライアントとブラウザーとの組み合わせでも動作するように設計されている。MIME型を通じて、よく理解されている文書形式ごとのアプリケーション呼び出しにのみ依存している。
　

　「CellML」メディアタイプがRFC 4708として承認された。
　RFC 4708は、CellML Umbrella 1.0互換のマークアップ言語で表現された数学モデルのやりとり用の新しいメディアタイプである「application/cellml+xml」を標準化している。

　他の標準化団体とIETFの連絡担当者の役割に関するガイドラインがRFC 4691として承認された。
　IETFが他の標準化団体（SDO：Standards Development Organization）やコンソーシアム、業界団体などと連携することを決めたときは、必ず連絡担当者が任命される。こうしたIETFと他の団体との連携を始めたり、保ったりするときのIABの手続きはRFC 4052で定められているとおりである。
　RFC 4691は、連絡担当者や代表者の役割を拡大するために、権限や期待される役割、義務、職責に関するガイドラインを定めている。

　ASD（Aerospace and Defence Industries Association of Europe：ヨーロッパ航空宇宙産業協会）の1000D仕様用のURN（Uniform Resource Name：定型リソース名）名前空間がRFC 4688として承認された。
　「S1000D（Specification 1000D）」とは、民間および政府の技術文書の調達と制作に関する仕様のことである。RFC 4688は、ASDの1000D仕様で定義されている恒久リソースに名前を付けるときに用いるURN名前空間について述べている。

　PIM-SM（Protocol Independent Multicast - Sparse Mode）マルチキャストルーティングのセキュリティ問題と拡張について述べた文書がRFC 4609として承認された。
　RFC 4609は大規模（ドメイン間またはドメイン内）なマルチキャストルーティング基盤のセキュリティ面の脅威について述べている。ただし、分析対象となっているのは、PIM-SMの3つの主要な運用モードであるASM（Any-Source Multicast）、SSM（Source-Specific Multicast）、Embedded-RP（ASM model enhanced by the Embedded Rendezvous Point：ASM埋め込みランデブーポイント拡張）のみである。また、RFC 4609は特定の脅威を中和させるプロトコル運用の拡張仕様についても述べている。

　ルーティングプロトコル全般のリスクについてまとめた文書がRFC 4593として承認された。
　ルーティングプロトコルには個々のユーザーやネットワーク全体の運用に悪影響を与えかねない攻撃にさらされやすい。RFC 4593は、ルーティングプロトコル全般に影響を与える一般的な脅威について説明と概要をまとめている。文書には、脅威の発生源、影響のある範囲、脅威の内容、結果、また、個別に攻撃された場合のルーティング機能の停止についても述べている。

　中国語ドメイン名の登録および管理の要件がRFC 4713として承認された。
　一般に使われている漢字にはさまざまな異体字があるため、ほとんどの中国語ドメイン名（CDN：Chinese Domain Name）には少なくとも2つの形式を持つことになる。簡体字（SC：Simplified Chinese）および繁体字（TC：Traditional Chinese）のドメイン名が等価であることは、CDNの登録においてきわめて重要である。
　そこでRFC 4713は、CDNの登録および管理手続きに関する仕様を定めるため、基本的な概念や一般的なガイドライン、RFC 3743の枠組みについて述べている。また、RFC 4713はIANAが作成した簡体字と繁体字の対応表を理解し、利用するための情報も提供している。
　

　IETF技術文書発行サービスの要件がRFC 4714として承認された。
　インターネットの運用を支援するための技術的仕様を議論し、開発し、普及させることがIETFの作業である。技術的文書は仕様の審査過程で用いられ、その成果物をインターネットの技術コミュニティ全体に広める目的でも使われる。したがって、技術文書の発行過程の要件について理解しておくことが重要である。

　GigaBeam高速電波リンク暗号の仕様がRFC 4705として承認された。
　RFC 4705は、電波リンク技術「WiFiber」の一部であるGigaBeamで使われる暗号化と鍵管理について述べている。競合する他の無線製品の開発において、GigaBeamとの互換性が得られるようにしたいという思いから文書化されたものである。

　IPv6のホスト密度の計測に関して検討した文書がRFC 4692として承認された。
　RFC 4692は、IPv6のユニキャストアドレスブロックの割り当て登録の参考に現在使われているホスト密度の計測に関する分析レポートを提供している。また、RFC 4692は、現在採用されているIPv4ネットワークのアドレスとIPv6プロトコルのアドレスの効率を比較している。ただし、IPv4とIPv6では、特に広範囲にわたる割り当てに関して、効率の計測に大きな違いがあることに留意すべきである。

　PCE（Path Computation Element：経路計算要素）ディスカバリー用の要件がRFC 4674として承認された。
　RFC 4674は、PCC（Path Computation Client：経路計算クライアント）がPCEの選択に関する任意の情報に合致するPCEを動的かつ自動的に発見するためのPCE用の要件について述べている。RFC 4674の目的は、PCEディスカバリーなどの手続きやプロトコル、既存プロトコルの拡張仕様を定めるソリューションが要件を満たすようにすることである。

　国際化ドメイン名（IDN）に関する評価と推奨を述べた文書がRFC 4690として承認された。
　RFC 4690は、IDNの導入や利用にともなう問題について述べている。また、DNSの登録時や利用時の問題について述べ、今後とるべき方針について、IETF以外の組織でなされるべき作業を示し、要約すると同時に、IETFがIDN関連のRFCを更新することを勧告している。
　特に、IDNA（Internationalizing Domain Names in Applications：アプリケーションにおける国際化ドメイン名）の規格やその対応表に関しては、これまでの経験に基づいて、変更が検討されるべきことを提案している。

　サーバー／アプリケーション状態プロトコル・バージョン1の実験的仕様がRFC 4678として承認された。
　システム群に仕事を割り当てる主体は、伝統的に、仕事を達成するためにそれぞれのアプリケーション上のアプリケーションにどの程度の能力があるのかほとんど把握していない。一方で、仕事量の管理システムは、伝統的に、アプリケーションの処理能力の負担度合いをかなりの程度把握しているが、アプリケーションが受け取る仕事の割合について、制御しない。
　サーバー／アプリケーション状態プロトコル（SASP：Server/Application State Protocol）が提供するのは、ロードバランサーや仕事量管理システムが既存の仕事量をメンバーに対してよりよくやりとりするためのメカニズムである。

　通信事業者提供型レイヤ2VPN（L2VPN）のサービス要件に関する文書がRFC 4665として承認された。
　RFC 4665は、L2VPNの分類と用語の定義を示し、全般的かつ一般的なサービス要件を提示している。内容には、拠点間VPN（Point to Point VPN）やVPWS（Virtual Private Wire Service）、VPLS（Virtual Private LAN Service）としても知られる多拠点間VPN（Multipoint to Multipoint VPN）が含まれる。顧客側および通信事業者側の観点から、詳細な要件が述べられている。

　L2VPN用のフレームワークに関する文書がRFC 4664として承認された。
　RFC 4664は、プロバイダ提供型のL2VPN用のフレームワークについて述べている。このフレームワークの目的は、相互運用可能なL2VPNのプロトコルおよびメカニズムを標準化することである。

　DKIM（DomainKeys Identified Mail）を利用したセキュリティリスクの分析に関する文書がRFC 4686として承認された。
　RFC 4686は、シグネチャベースのメール認証、特にドメイン名キーを用いたメールに対するセキュリティリスクを分析している。攻撃者の性質や攻撃場所、潜在的なリスクやどのような目的を達成するための攻撃なのかについて議論している。

　PCE（Path Computation Element）通信プロトコルの一般要件がRFC 4657として承認された。
　PCEモデルは、「PCEアーキテクチャ」の文書で述べられており、PCC（Path Computation Client）からPCE（Path Computation Element）への経路計算要求を促す。RFC 4657は、PCCとPCE間、およびPCE間の協同が不可能な場合のPCE間の通信プロトコル用の一般要件を定めている。PCE通信プロトコルのアプリケーション固有の要件については、別の文書によって定める。

　モバイルIPv6の初期化処理に関する問題提起に関する文書がRFC 4640として承認された。
　モバイルIPv6の動作には、少なくとも以下の3つの情報が必須である。

1.ホームアドレス
2.ホームエージェントアドレス
3.ホームエージェントに登録するときに使う暗号化伝送路であるSA（Security Association）

　これらの情報を取得する過程は、モバイルIPv6の初期化処理（ブートストラッピング）と呼ばれる。RFC 4640は、モバイルノードがどのようにモバイルIPv6用にブートストラップされるかに関する問題、モバイルノードのブートストラッピング用の、さまざまな現場への導入シナリオについて議論している。

　DSL（Digital Subscriber Line）フォーラムのRADIUS（Remote Authentication Dial-In User Service）VSA（Vendor-Specific Attribute：ベンダー固有属性）の仕様がRFC 4679として承認された。
　RADIUS VSAは、標準的なRADIUS属性では対応していないDSL情報を伝送するために設計された。なお、RFC 4679は標準化過程の文書ではなく、DSL関連機器メーカーが他の機器との相互接続性を得たい場合の参照用であり、DSLフォーラムが追加的なベンダー固有属性を定めたときに更新される。

　RADIUS（Remote Authentication Dial-In User Service）動的認証サーバーMIBの仕様がRFC 4673として承認された。MIBの一部としてネットワーク管理プロトコルで用いられる。
　RFC 4673は、RADIUS（RFC 2865）の拡張機能としてRFC 3576定義されているDAS（Dynamic Authorization Server）用のMIBについて述べている。

　RADIUS（Remote Authentication Dial-In User Service）動的認証クライアントMIBの仕様がRFC 4672として承認された。MIBの一部としてネットワーク管理プロトコルで用いられる。
　RFC 4672は、RADIUS（RFC 2865）の拡張機能としてRFC 3576定義されているDAC（Dynamic Authorization Client）用のMIBについて述べている。

　MIDI用ダウンロード音源のメディアタイプ登録に関する文書がRFC 4613として承認された。

　IETFの「道」　-　初心者のためのIETFガイドがRFC 4677として承認された。
　RFC 4677は、IETFミーティングの内部の作業および作業部会について述べ、IETFに関連する組織について議論し、標準化過程について紹介している。RFC 4677は公式のIETFの手続きに関する文書ではないが、情報提供を目的とした概要になっている。

　IETFブリッジMIB作業部会からIEEE 802.1作業部会へMIB標準化作業を委譲させることに関する文書がRFC 4663として承認された。
　RFC 4663は、ブリッジ関連MIBモジュールの標準化に関する権限をIETFブリッジMIB作業部会からIEEE 802.1作業部会に委譲する計画について述べている。IEEE 802.1作業部会は、MIBモジュールが管理する対象となるブリッジ技術の開発を担当している。

　PPPoE（Point-to-Point Protocol over Ethernet）でMTU（Maximum Transit Unit）/MRU（Maximum Receive Unit）の最大値を1492以上に調整することを述べた文書がRFC 4638として承認された。
　RFC 2516で定義されているPPPoEは、ネゴシエートしたMRUの最大値を1492に指定している。RFC 4638は、この制限を緩和する解決方法および次世代の広帯域ネットワークにおいてなるべく断片化を起こさないようにネゴシエートしたMRUの値を1492以上にするための概要を述べている。

　TCP（Transmission Control Protocol）仕様の道のりを記した文書がRFC 4614として承認された。
　RFC 4614は、TCPに関するこれまでのRFC（Requests for Comments）を振り返る文書である。RFCとして蓄積されてきた、TCPとTCPのさまざまな拡張仕様を定義している文書の簡単な要約になっている。TCPの実装者やTCP関連RFCに含まれる情報に関心のある人々に、案内や「あんちょこ」として役に立つだろう。

　言語副タグ初期値の登録に関する文書がRFC 4645として承認された。
　RFC 4645は、言語の識別用にタグを形成するときに用いる、IANAの言語副タグの初期値を定義している。ただし、RFC 4645の内容は登録のための始まりに過ぎず、その実際の内容は混乱を避けるため、公開前に削除される。

　PIM-SMがIETF標準化提案要件を満たしているかを分析する文書がRFC 4602として承認された。
　RFC 4602は、PIM-SM（Protocol Independent Multicast - Sparse Mode）をIETF標準化過程の実験ステータスから標準化提案へ格上げすることを支援する文書である。

　SIP（Session Initiation Protocol）用のユーザー特性認証の要件に関する文書がRFC 4484として承認された。
　RFC 4484は、SIP用のユーザー特性認証に関する要件の全貌を述べている。SIPの基本仕様ではいくつかの認証メカニズムが述べられているが、ユーザー特性に基づく認証は、セッションに参加するユーザーの属性に基づいてポリシーの判断ができるような情報を提供する。ユーザー特性認証によって、認証用のより詳細なフレームワークが実現される。また、ユーザー情報を管理するシステムにおけるユーザーのプライバシーも保護される。

　IPv6用RADIUSアカウンティングサーバーMIBの仕様がRFC 4671として承認された。
　RFC 4671で定義されたRADIUSアカウンティングサーバー用の拡張仕様によって、IPベースの管理ステーションからRADIUSアカウンティングサーバーを管理できるようになる。また、RFC 4671はIPv4アドレス形式のみにしか対応できないMIBテーブルの仕様を破棄し、IPのバージョンに依存しないIPアドレス形式に対応する新しいMIBテーブルを定義することでRFC 2621を廃止する。RFC 2621で定義されたその他のMIBオブジェクトはRFC 4671に移行する一方で、オブジェクトを選択するためのUNITSおよびREFERENCEが追加されている。

　IPv6用RADIUSアカウンティングクライアントMIBの仕様がRFC 4670として承認された。
　RFC 4670で定義されたRADIUSアカウンティングクライアント用の拡張仕様によって、IPベースの管理ステーションからRADIUSアカウンティングクライアントを管理できるようになる。また、RFC 4670はIPv4アドレス形式のみにしか対応できないMIBテーブルの仕様を破棄し、IPのバージョンに依存しないIPアドレス形式に対応する新しいMIBテーブルを定義することでRFC 2620を廃止する。RFC 2620で定義されたその他のMIBオブジェクトはRFC 4670に移行する一方で、オブジェクトを選択するためのUNITSおよびREFERENCEが追加されている。

　PCE（Path Computation Element）ベースのアーキテクチャに関する文書がRFC 4655として承認された。
　制約に基づくパスの計算は、基礎的な構成要素としてMPLS（Multiprotocol Label Switching）やGMPLS（Generalized Multiprotocol Label Switching）などのトラフィックエンジニアリングシステムで使われている。
　しかし、ネットワークの規模が大きく、複数のドメインや地域、2つ以上レイヤーにまたがっていると、計算は複雑になり、特殊な計算装置や異なるネットワークドメイン間の協力が欠かせなくなる。
　そこでRFC 4655はこの問題に対応するために、PCEに基づくモデルのアーキテクチャの仕様を定義している。
　ただし、RFC 4655はアーキテクチャを構成するすべての要素についての詳細な説明をしているわけではなく、むしろ構築されるはずのソリューションから、PCEアーキテクチャ用の構成要素を述べている。

　DiffServサービスクラス用の構成ガイドラインがRFC 4594として承認された。
　RFC 4594が述べているのはDiffservで構成されるサービスクラスであり、どのようにサービスクラスを使うか、DSCP（Differentiated Services Code Point）やトラフィックコンディショナー、PHB（Per-Hop Behavior）、AQM（Active Queue Management）を用いてどのようにサービスクラスを構築するかを推奨している。あるサービスクラスが特定のDSCPやトラフィックコンディショナー、PHB、AQMを使うべきであるという本質的な要件はないものの、ポリシーおよび相互接続性の観点から、そうした機能を一貫した仕様によって備えておくとよい。

　ラトビア中央政府インテグレーション計画用のURN（Uniform Resource Name：定型リソース名）公式名前空間についての文書がRFC 4617として承認された。
　RFC 4617は、ラトビア中央政府インテグレーション計画（ラトビア語での省略形はIVIS）によって発行または生成された情報リソースに名前を付けるために、Olimps LTDが総合請負人となり、ABCソフトウェア、マイクロソフト・ラトビア、Riga Internet eXchange (RIX)テクノロジーズ、Microlinkが協同請負人となった企業体によって管理されるURN名前空間について述べている。

　会議のシナリオに関する文書がRFC 4597として承認された。
　RFC 4597は、マルチメディアタイプ会議のシナリオについて述べている。音声、ビデオ、テキスト、対話型テキストのセッションに関連する基本的な会議のシナリオやより踏み込んだことがらについて述べている。こうしたシナリオは、集中型カンファレンスXCON作業部会で開発中のプロトコルの定義や評価のためになる。

　MOBIKE（IKEv2 Mobility and Multihoming）の設計に関する文書がRFC 4621として承認された。
　MOBIKEプロトコルは、IKEv2（Internet Key Exchange Protocol version 2）の拡張仕様であり、ホストが複数のIPアドレスを扱う場合や、通信中にIPsecホストのIPアドレスが変わってしまうようなIKEまたはIPsecのSA（Security Association）を効率的に管理できるようにする。
　RFC 4621は、関連するネットワーク機器やIKEv2のシグナリングと他のプロトコルによって提供される情報との関係について議論している。また、MOBIKEプロトコル設計の背景にある判断や情報、作業部会における議論が記録されている。

　SHAとHMAC-SHAに関する文書がRFC 4634として承認された。
　アメリカ合衆国はSHA（Secure Hash Algorithm）と呼ばれる一連のアルゴリズムを採用している。このアルゴリズムには特にSHA-224（RFC 3874）やSHA-256、SHA-384、SHA-512というSHA-1以降の4つのアルゴリズムが含まれており、FIPS（Federal Information Processing Standard：連邦情報処理標準）の一部となっている。
　RFC 4634の目的は、これらのハッシュ関数を実行するソースコードをインターネットコミュニティに公開することであり、FIPS 180-2標準の著者によって、SHA-1の仕様を述べているRFC 3174を書き改めている。また、RFC 3174にあるSHA-1のサンプルコードを更新、SHAベースのHMACのサンプルコードも示されている。すべてのサンプルコードは任意の長さのビット列に対応している。

　JSON（JavaScript Object Notation：JavaScript式オブジェクト表記）用の「application/json」メディアタイプに関する文書がRFC 4627として承認された。
　JSONとは、仕様が単純なテキストベースの特定のプログラム言語から独立したデータ交換形式のことである。ECMAScript（JavaScript）の規格から派生したデータの表記方法で、構造化データを2者間でやりとりするのに適した簡単な書式化ルールを定めている。

　RADIUSのNAS-Port-Type属性への追加の値に関する文書がRFC 4603として承認された。
　RFC 4603は、RADIUSのNAS-Port-Type属性用に、PPPoA、PPPoEoA、PPPoEoE、PPPoEoVLAN、PPPoEoQinQを表す値を定めている。

　ファイバーチャネルSA（Security Association）管理プロトコルにおけるIKEv2（Internet Key Exchange protocol version 2：インターネット鍵交換プロトコルバージョン2）の利用に関する文書がRFC 4595として承認された。
　RFC 4595は、FC-SP（Fibre Channel Security Protocol）のネゴシエートおよびファイバーチャネル用にファイバーチャネルSA管理プロトコルの一部としてIKEv2を利用することについて述べている。IKEv2の利用には、ファイバーチャネル固有のFC-SP、変換方式、名前形式と組み合わせられるようにIKEv2を拡張する必要がある。そこでRFC 4595はIKEv2の拡張仕様を定めて、仕様に対する識別子を割り当てている。ファイバーチャネルSA管理プロトコル用の新しいIKEv2識別子を用いることによって、IPネットワーク用ネゴシエーションとファイバーチャネル用ネゴシエーションを区別できるようになり、混乱を避けられる。

　SIP（Session Initiation Protocol：セッション開始プロトコル）呼び出し元プリファレンス拡張用のガイドラインがRFC 4596として承認された。
　RFC 4596は、SIPの拡張仕様である呼び出し元プリファレンスの使い方に関するガイドラインである。呼び出し元プリファレンスの長所を特定の応用例として示し、適切な操作方法、登録済み機能タグの適用性、プリファレンスの忠実な実装およびRFC 3841のセクション7.2にあるプリファレンスマッチングアルゴリズム機能についても述べている。

　RTP/AVPF拡張のタイミングルールシミュレーションの結果に関する文書がRFC 4586として承認された。
　RFC 4586は、RTP/AVPF拡張（Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback）のタイミングルールのシミュレーションによって得られた結果について述べている。シミュレーションでは、いくつかのプロトコルおよび環境構成と同様にユニキャストおよびマルチキャストトポロジーが考慮された。その結果、タイミングルールはフィードバック遅延に関してよりよい性能を発揮できることがわかった。また、トラフィック制御用に許されたビットレートに関して広く受け入れられているRTPのルールに反しないことがわかった。