ROHC-FN（Formal Notation for RObust Header Compression）の仕様がRFC 4997として勧告された。
　RFC 4997はROHCフレームワーク内で新しいプロファイルを定義する際の圧縮形式用フィールド符号化の仕様を定義するための正式の表記方法について定義している。ROHC-FNが提供しているのは、符号化方式のライブラリーであり、ROHCプロファイルでしばしば使われるほか、将来のプロファイル開発作業を簡潔にする。

　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のリンク上で威力を発揮する。

　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の偽造についても議論している。

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

　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としてダイヤル文字列を符号化できるようにしている。

　DNSSEC（DNS security）オプトインの実験的仕様がRFC 4956として承認された。
　DNSSECの拡張仕様では、未署名のサブゾーンへの委任は暗号的に保護されている。しかし、暗号はいつでも必要なわけではなく、実際的でない場合もある。そこでRFC 4956は実験的なオプトインモデルについて述べて、管理者がDNSSECの暗号を省いたり、巨大ゾーンでDNSSECを採用することのコストを管理できるようにしている。

　DNSSEC（DNS Security）の実験に関する仕様がRFC 4955として勧告された。
　RFC 4955は、標準化されたDNSSECの普及を妨げることなく、実験的なやり方によって、DNSSECの現在とは異なる、後方互換性のない、セキュリティ上の方法論について述べている。

　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はインターネットの透過性の原則が破られることが影響を与えそうないくつかの特徴的事例を示している。

　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節を更新する情報も含まれている。

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

　iSNS（Internet Storage Name Service）用管理オブジェクトの定義がRFC 4939として勧告された。
　iSNSプロトコルは、iSCSI（Internet Small Computer System Interface）やiFCP（Internet Fibre Channel Protocol）用に使われているIPネットワーク上で動作するストレージネームサービス機能を実現する。RFC 4939は複数のiSNSサーバー（iSNSサーバー内の登録オブジェクトを含む）を監視するメカニズムを実現する。

　AAA（Authentication, Authorization, and Accounting）鍵管理のガイダンスがRFC 4962として承認された。
　RFC 4962はAAA鍵管理プロトコルの設計者用ガイダンスである。また、AAA鍵管理プロトコルを含むシステムやソリューションの設計者にも便利な内容になっている。セキュアな設計における複雑性と困難性や長期間使える鍵管理アルゴリズム、専門知識を持つセキュリティ分野の専門家が開発したプロトコルがなければ、IETF作業部会がAAAに基づく独自の鍵管理アルゴリズムとプロトコルを設計することは非常に難しい。RFC 4962におけるガイドラインはIETFのRFCとして発行される他の文書にも適用される。また、こうしたガイドラインは他のSDO（Standards Development Organization：標準化団体）がAAAに基づく鍵管理技術を標準化する際にも有用である。

　Atomライセンス拡張の実験的仕様がRFC 4946として承認された。
　RFC 4946はAtomフィードとその内容に関連づけるライセンス用のAtomシンジケーション形式に対する拡張仕様を定めている。

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

　認証用のSMTP（Simple Mail Transport Protocol）拡張の仕様がRFC 4954として勧告された。
　RFC 4954はSMTPクライアントがサーバーに対して認証メカニズムを指定したり、認証プロトコルをやりとりしたり、セッション中に下位プロトコルが用いるセキュリティ層を交渉するオプションといったSMTP拡張を定義している。また、SMTP用のSASL（Simple Authentication and Security Layer）プロファイルも含まれている。

　CGA（Cryptographically Generated Addresse）における複数ハッシュアルゴリズムへの対応に関する仕様がRFC 4982として勧告された。
　RFC 4982はCGAでよく使われるハッシュ関数への最近の攻撃について分析し、複数のハッシュアルゴリズムに対応するようにCGA仕様を更新するものである。

　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に関する問題と解決策の要件について議論する際の用語を定義している。

　OSPFに関するIANAの検討事項に関する文書がRFC 4940として承認された。
　RFC 4940は、OSPFに関するいくつかの登録事項と、そのコードポイントを割り当てるためのIANAへのガイダンスである。

　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は今後もその役割を果たし続けることになる。

　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のセットアップの成功と回復の比率は、特に同時に大量のセットアップ要求が送信された場合に大幅に改善される。

　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仕様を参照定義とする符号化手順も定義されている。

　ASN.1（Abstract Syntax Notation One）用RXER（Robust XML Encoding Rules）の実験的仕様がRFC 4910として承認された。
　RFC 4910はASN.1データタイプの値がXML表現になる頑強なXML符号化規則またはRXFRと呼ばれるASN.1の符号化規則の仕様を定めている。また、正規のRXER符号化を出力するための規則も定められている。

　GSER（Generic String Encoding Rules）用符号化手順のASN.X（Abstract Syntax Notation X）表現に関する実験的仕様がRFC 4913として承認された。
　ASN.XはASN.1のXML（Extensible Markup Language）表現である。RFC 4913はGSER用符号化手順のASN.X表現についての仕様を定めている。

　XER（XML Encoding Rules）用符号化手順のASN.X（Abstract Syntax Notation X）表現についての実験的仕様がRFC 4914として承認された。
　ASN.XはASN.1のXML（Extensible Markup Language）表現である。RFC 4914はXER用符号化手順のASN.X表現についての仕様を定めている。

　ASN.X（Abstract Syntax Notation X）の実験的仕様がRFC 4912として承認された。
　ASN.Xは、ASN.1言語にある数々の曖昧性を排除している。したがって、ASN.Xで記述された仕様は、元のASN.1で記述された仕様よりも構文解析がしやすく、たやすく管理できる。また、RXERと併用することで、ASN.XはXML文書用のスキーマ言語として利用でき、他のASN.1符号化規則を適用することで実際のXML文書をバイナリ符号化するコンパクトな代替形式にもなる。

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

　EPON（Ethernet Passive Optical Networks）用管理オブジェクトがRFC 4837として勧告された。ネットワークの管理用にMIBの一部として使われる。
　RFC 4837はIEEE標準802.3ah-2004として定義され、Ethernetのリンクインターフェイスを拡張するEPON標準に適合するインターフェイスの管理オブジェクトを定義している。

　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機能の結果や状態を提供したりするための管理オブジェクトを定義している。

　モバイルIPv4における低レイテンシーハンドオフに関する実験的仕様がRFC 4881として承認された。
　異なるフォーリンエージェントによるサブネット間でモバイルノードがどのようにIPv4レイヤーをハンドオフするかについてはモバイルIPv4の仕様で述べられている。しかしある種の場合、ハンドオフ時のレイテンシーが、遅延に弱かったり、リアルタイムのサービスに対応するために、許容値を超えてしまうことがある。
　RFC 4881の目的は、低レイテンシーのモバイルIPv4ハンドオフの2つの手法を示すことである。また、2つの手法を組み合わせる方法についても述べている。この手法によって、モバイルIPv4の登録手続きに遅延が生じることでモバイルノードがIPv4パケットを送受信できなくなる時間をなるべく短くし、リアルタイムサービスにより対応できるようになる。

　WebDAV（Web Distributed Authoring and Versioning）用のHTTPの拡張仕様がRFC 4918として勧告された。
　WebDAVはHTTP/1.1を補助する形で一連のメソッドやヘッダー、コンテントタイプを定義し、リソース属性の管理やリソースコレクションの作成と管理、URL名前空間の操作、衝突を回避するためのリソースのロック機構を実現している。RFC 4918によって、WebDAVは相互運用の実績から得た軽微な改訂が加えられ、1999年2月に発行されたRFC 2518は廃止される。

　OSPF（Open Shortest Path First）におけるMT（Multi-Topology）ルーティングに関する仕様がRFC 4915として勧告された。
　RFC 4915はOSPFを拡張してMTと呼ばれる独立したIPトポロジーを定義することについて述べている。MT拡張はユニキャストトラフィックやマルチキャストトラフィック、柔軟な基準に基づく異なるサービスクラス用の異なる経路や、内向きのネットワーク管理トポロジーを算出するために利用できる。また、デフォルトトポロジーから選択されたリンクを除外するためのオプション拡張についても述べている。

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

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