EPP（Extensible Provisioning Protocol）の仕様がRFC 4930として勧告された。
　RFC 4930は共有型中央リポジトリーに保管されたオブジェクトの供給と管理用のクライアント／サーバー型のアプリケーション層プロトコルについて述べている。XMLで仕様を定めることで、EPPは汎用のオブジェクト管理操作とオブジェクトに対するプロトコルの操作の対応付けを拡張できるフレームワークになっている。RFC 4930にはプロトコル仕様とオブジェクト対応付けのテンプレート、XMLメディアタイプの登録が含まれる。RFC 4930によってRFC 3730は廃止される。

　EPP（Extensible Provisioning Protocol）のドメイン名対応付けの仕様がRFC 4931として勧告された。
　RFC 4931は共有中央リポジトリーに保管されたインターネットドメイン名の供給と管理用のEPP対応付けについて述べている。対応付けはXMLで定められており、EPPコマンド文法とその意味をドメイン名に対応させる。RFC 4931によってRFC 3731は廃止される。

　EPP（Extensible Provisioning Protocol）ホスト対応付けの仕様がRFC 4932として勧告された。
　RFC 4932は共有型中央リポジトリーに保管されたインターネットホスト名の供給と管理用のEPP対応付けについて述べている。XMLで仕様を定めることで、対応付けはEPPコマンド文法とその意味をホスト名として定義できる。RFC 4932によってRFC 3732は廃止される。

　TCP（Transmission Control Protocol）上のEPP（Extensible Provisioning Protocol ）伝送の仕様がRFC 4934として勧告された。
　RFC 4934はどのようにEPPセッションを単一のTCPコネクション上に対応付けるかについて述べている。対応付けにはTLS（Transport Layer Security）プロトコルを用いて、EPPクライアントとEPPクライアント間でやりとりされる情報を保護する必要がある。RFC 4934によってRFC 3734は廃止される。

　TCP拡張統計MIBの仕様がRFC 4898として勧告された。
　RFC 4898はTCP用の拡張パフォーマンス統計について述べている。ネットワークやアプリケーションのパフォーマンス上の問題を診断するための、TCPの絶好の観測地点となるように設計されている。ネットワークアプリケーションでパフォーマンスが出ない場合、TCPはボトルネックが送信者にあるのか、受信者にあるのか、ネットワークにあるのかを判断できる。もしボトルネックがネットワークにあるのであれば、プロトコルで規定されているとおり、TCPは特定の情報を提供できる。

　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に関する位置情報のプライバシーについて議論されている。ホームアドレスが第三者に漏れたときや気付けアドレスが通信相手に明らかになったときの問題についてまとめている。

　DomainKeysに関する歴史的文書がRFC 4870として承認された。
　DomainKeysは電子メール公開鍵技術とDNSを用いた電子メール用のドメインレベル認証フレームワークであり、DomainKeysによって送信元と内容を探査できるようになる。RFC 4870はドメインごとに電子メールをデジタル署名するためのフレームワークについて定義している。
　DomainKeysフレームワークの最終目的は現在の電子メールのデータ形式やプロトコルの解釈方式に変更を加えることなく、電子メールの送信元と内容がデジタル署名されてから改ざんされないようにし、また改ざんされていないことを確認できるようにすることである。電子メールの改ざんを防止したり、改ざんを検出したりできれば、インターネットメール全体のスパムやフィッシング対策にもなる。

　DKIM（DomainKeys Identified Mail）署名の仕様がRFC 4871として勧告された。
　DKIMは公開鍵と鍵サーバー技術を用いたドメインレベルのメール用認証フレームワークを定義しており、DKIMによってMTA（Mail Transfer Agent）やMUA（Mail User Agent）がメッセージの送信者や内容を確認できるようになる。DKIMの最終目的はあるメッセージの配信に関する責任が署名ドメインにあることを明確にすることであり、スパムメールによって蝕まれた現在のインターネットメールの機能を維持しつつ、メッセージへの署名者やメッセージ内容の改ざんを防ぐことである。また電子メールの改ざんを防止することは、インターネットメール全体のスパムやフィッシング対策につながる。
　

　プレゼンス文書の内容操作用の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方式のプレゼンス文書で構築する場合を想定している。

　リソースリスト表記用の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）によって作成、管理される。

　XCAP（XML Configuration Access Protocol）の仕様がRFC 4825として勧告された。
　RFC 4825はXCAPの仕様を定めている。XCAPによってクライアントはサーバー上にXML形式で保管されたアプリケーション構成データを読んだり書いたり更新したりできるようになる。XCAPがXML文書の子ツリーや要素属性をHTTPのURIに対応付けることで、XML文書の個々のデータをHTTPで直接アクセスできるようになる。

　4オクテットAS（Autonomous System）番号空間用のBGP対応の仕様がRFC 4893として勧告された。
　現在のAS番号は、BGPの仕様で2オクテット幅で符号化されることになっている。RFC 4893はBGPの仕様を拡張してAS番号を4オクテット幅で伝送できるようにする。
　

　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メッセージを伝播できるようにする。

　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の埒外である。

　モバイルIPv6用の経路最適化拡張の仕様がRFC 4866として勧告された。
　RFC 4866はモバイルIPv6用の経路最適化技術のハンドオフ時の遅延を短くし、セキュリティを向上させ、シグナリングのオーバーヘッドを減らす拡張仕様を定義している。

　ワイルドカード疑似有線タイプの仕様がRFC 4863として勧告された。
　疑似有線のシグナリングでは、PWタイプ（Pseudowire Type）が両端で同じである必要がある。しかし、ある種のアプリケーションでは、PWタイプの構成は一方の終端で情報を設定すれば済むのに対して、LDPベースのシグナリングの場合、それぞれのPW終端が単一方向のLSPの作成から始めなければならない。2つのLSPをそれぞれ別個に作成することから開始するには、相手のPWタイプを事前に知らないPW終端でもLSPの作成から始められるような方法が必要である。RFC 4863は、この条件を満たすワイルドカード疑似有線タイプについて定義している。

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

　MPLSセグメントの回復機能に関する仕様がRFC 4873として勧告された。
　RFC 4873はGMPLSのRSVP-TEシグナリング用にプロトコル固有の手続きと拡張仕様を述べて、LSP（Label Switched Path）セグメントの保護と回復に対応する。
　この拡張仕様の目的は、「エンドトゥエンドGMPLS回復機能に対応するためのRSVP-TE拡張仕様」（RFC 4872）を補い、一体となることにある。高速再経路（Fast Reroute）との関係と相互作用についても触れている。なお、RFC 4873はNOTIFY_REQUESTオブジェクトの扱いを更新する。

　エンドトゥエンド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で述べている。

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

　汎用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ネットワークに接続されたエンドシステムが汎用帯域予約集約の仕組みを直接にも利用できる。

　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は長さを切り詰めない。

　SIP（Session Initiation Protocol）用のMIB（Management Information Base）の仕様がRFC 4780として勧告された。ネットワーク管理用のプロトコルとともに、MIBの一部として使われる。
　RFC 4780はSIPのユーザーエージェント、プロキシー、リダイレクト／登録サーバーなどが用いる管理オブジェクトについて述べている。

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

　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）に基づいている。

　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を更新する。

　URIとDDDS（Dynamic Delegation Discovery Service：動的委任発見システム）を使ったドメインベースのアプリケーションサービスロケーションの仕様がRFC 4848として勧告された。
　RFC 4848の目的は、特定のアプリケーションサービスとプロトコル用に新しい単純なDDDSのアプリケーションを定義して、ドメイン名をURIに対応づけられるようにすることである。U-NAPTRを置き換える新しいDDDSアプリケーションが定義されているが、実際にはNAPTR（S-NAPTR）DDDRアプリケーションの拡張である。