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

　IEEE 802.3 MAU（Medium Attachment Unit）用管理オブジェクトの仕様がRFC 4836として勧告された。ネットワーク管理用のプロトコルとともに、MIBの一部として利用される。
　RFC 4836はRFC 3636を廃止する。また、MAU型のOBJECT-IDENTITYの定義と関連する省略記法の定義をIANA管理の別のMIBモジュールに移行し、MAU用管理オブジェクトの仕様を変更している。さらに、管理情報を追加してEFM（Ethernet in the First Mile）や10GBASE-CX4 MAUに対応している。

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

　ORCHID（Overlay Routable Cryptographic Hash Identifiers）用のIPv6プレフィックスの実験的仕様がRFC 4843として承認された。
　RFC 4843はORCHIDをIPv6のアドレスに相当する実験的IDとして紹介している。ORCHIDの目的はアプリケーションやAPI（Application Programming Interface）のエンドポイントIDとして使うことであり、IP層におけるネットワークの場所をなどを示すことではない。ORCHIDはアプリケーション層や既存のIPv6 APIで使われるように設計されており、実際のIPv6ヘッダーでは使われない。
　ORCHIDをより本物のIPv6アドレス風味にするために、オーバーレイレベルではルーティング可能であることが想定される。その結果、ORCHIDはIPv6レイヤーからはルーティングできないアドレスでしかないが、既存のIPv6アプリケーションはORCHIDを現行のIPv6アドレスと同様の方法で扱えるはずである。
　RFC 4843はIANAに対し、Overlay Routable Cryptographic Hash Identifiers用にIPv6のアドレス空間外に暫定的なプレフィックスを割り当てるように求めている。IETFの合意による延長手続きがとられない限り、プレフィックスは2014年に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）に対応するネットワークとノードが企業にあることを前提に、移行に関する分析に集中して議論されている。その上で、それぞれの説明用ネットワークについて移行メカニズムを推奨している。

　iSCSI（Internet Small Computer Systems Interface）ノードアーキテクチャ用の共用拡張の仕様がRFC 4850として勧告された。
　RFC 3720で定義されているiSCSIは、私用または共用の拡張キーの形式でプロトコルで拡張項目を使えるようにしている。RFC 4850はiSCSIの対応を拡張するために共用の拡張キーについて述べている。iSCSIノードがiSCSIログインシーケンス中にアークテクチャの詳細をやりとりできるようにすることで、この目的を達成する。受信側ノードはこの情報を拡張ログの対応に使う。RFC 4850はRFC 3720を改訂し、iSCSIの拡張項目が標準化過程または実験仕様のRFCとして定義できるようにする。

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

　CMS（Cryptographic Message Syntax：暗号メッセージ文法）複数署名者の説明がRFC 4853として勧告された。
　RFC 4853はCMS（RFC 3852）の仕様を改訂し、デジタル署名が2つ以上存在する場合のSignedData保護コンテント型を適切に扱うようにする。

　DHCP用のタイムゾーンオプションの仕様がRFC 4833として勧告された。
　タイムゾーン情報をやりとりするには、POSIX 1003.1のタイムゾーン文字列とタイムゾーンデータベース名を使う2つの方法がある。RFC 4833はどちらの方法も利用可能なDHCPオプションの仕様を定めている。

　TFRC（TCP-Friendly Rate Control）スモールパケット版の実験的仕様がRFC 4828として承認された。
　RFC 4828は、現時点でインターネット全体で広く使われてはいない、今後の実験のためのメカニズムを提案している。
　TFRC（RFC 3448）はベストエフォートのインターネット環境において運用されているユニキャストフロー用の輻輳制御メカニズムである。TFRCは固定パケットサイズを用いるアプリケーション用のプロトコルであり、同じパケットサイズを用いるTCPコネクションと帯域幅を競合して用いる場合に一般的には公平といえるように設計されている。
　一方、RFC 4828として提案されたTFRCのスモールパケット版であるTFRC-SPは、小さなパケットを送信するアプリケーション用に設計されている。TFRC-SPの設計上の目標は1500バイトまでのパケットサイズを用いるTCPフローと同じ通信速度を達成することである。TFRC-SPは1つのTCPフローが小さなパケットを任意の頻度で送信しないように、パケットの送信間隔を最小10ミリ秒に制限している。
　大きなパケットと小さなパケットのパケット消失率が同様の実験環境では、TFRC-SPのフローは大きなサイズのTCPおよびTRFCフローと一般的には公平に帯域幅を使うことを確かめた。ただし、小さなパケットのフローが大きなパケットのフローよりもパケットの消失率が低い実験環境では、TFRC-SPが共有する帯域幅をかなり多めに使うことがわかった。

　RADIUS（Remote Authentication Dial In User Service）IPv6プレフィクス属性の仕様がRFC 4818として勧告された。
　RFC 4818はRADIUS属性を定義してユーザーに委譲されるIPv6プレフィクスを伝送できるようにしている。属性はRADIUSおよびDiameterで利用可能である。

　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プロトコルそのものに影響を与える。

　ESP（Encapsulating Security Payload）およびAH（Authentication Header）用の暗号アルゴリズム実装要件の仕様がRFC 4835として勧告された。
　IPsecと総称されるプロトコル群は、セキュリティサービスを実現するためにさまざまな暗号アルゴリズムを利用している。ESPとAHという2つのメカニズムが、IPsecのSA（Security Association）上のデータ送信を保護する目的で使われているが、異なる実装間の相互運用性を確保するには、必須となるアルゴリズムの仕様を定めて、少なくとも1つのアルゴリズムはすべての実装で利用可能になるようにしなければならない。
　そこでRFC 4835では、現行のESPとAH用に実装が必須のアルゴリズムを定めるとともに、将来必須となるべきアルゴリズムの仕様も定めている。

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

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

　SONET/SDH（Synchronous Optical Network/Synchronous Digital Hierarchy） CEP（Circuit Emulation over Packet：パケット上の回線エミュレーション）の仕様がRFC 4842として勧告された。
　RFC 4842はMPLS上のSONET/SDH回線とサービスのエミュレーション用のカプセル化形式と解釈について述べている。

　IKEv2および改訂されたIPsecアーキテクチャとのモバイルIPv6の運用に関する仕様がRFC 4877として勧告された。
　RFC 4877はIKEv2および改訂されたIPsecアーキテクチャとのモバイルIPv6の運用について述べている。

　RFC 3979にある第三者公開手続きの説明がRFC 4879として承認された。
　RFC 4879はRFC 3979の一文、特に、IPR（Intellectual Property Rights：知的所有権）の第三者公開について説明し、更新している。RFC 3879の意図は、この場合にIETFの執行理事が知的所有権の権利者に第三者公開の手続きに入ったことを通知し、RFC 3979のルールによって、知的所有権を公開するかどうか尋ねることである。

　排他的経路に関する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：リスク共有リンクグループ）をどのように除外するかについても述べている。

　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は更新される。

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