MPLSネットワークにおける同コストの複数経路の取り扱いの回避に関する文書がRFC 4928として承認された。
　RFC 4928は現在利用されているMPLSネットワークのECMP（Equal Cost Multipath）の振る舞いについて述べている。RFC 4928は、MPLSネットワーク上でアプリケーションを実行するとき、同コストの複数経路上の同じフローの異なるパケットの伝送によって引き起こされる再構成をIPパケットのバージョン番号フィールドの監視によって避けるための、現状の最善の慣行による推奨仕様である。推奨仕様は、発見的手法を採っているにも関わらず、MPLSネットワークの運用において比較的安定した効果がある。

　オープンモバイルアライアンスの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通信プロトコルの要件を補っている。

　モバイル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）も必要である。

　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の査読手続きの必要性を示している。

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

　モバイルIPv4メッセージ文字列の拡張仕様がRFC 4917として勧告された。
　RFC 4917はモバイルIPv4用の新しい拡張仕様を定めている。この拡張仕様はホームエージェントと異動先エージェントに追加可能で、モバイルノードのユーザー用に、登録応答メッセージというテキスト文字列を伝送できるようにする。

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

　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その他の関連仕様によって置き換えられている。

　MPLSネットワーク上のレイヤー2フレーム伝送用のカプセル化手法に関する歴史的文書がRFC 4905として承認された。
　RFC 4905はフレームリレーやATM（Asynchronous Transfer Mode）、イーサーネットといったレイヤー2のPDU（Protocol Data Unit）をMPLSネットワーク上で伝送するためのカプセル化手法について述べている。RFC 4905が述べているのはいわゆる「draft-martini」プロトコルであり、エッジ間疑似有線エミュレーション作業部によるRFC 4447その他の関連仕様によって置き換えられている。

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

　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は現行プロトコルのリンク指標を要約し、設計上の問題について述べ、リンク指標に関する適切または不適切な使い方にいついての例を示している。

　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プロトコルの操作は単一の疑似有線上で、まさしく単一の拠点間リンクであるかのように独立している。

　SigComp（Signaling Compression）仕様の訂正と明確化に関する文書RFC 4896として勧告された。
　RFC 4896はSigCompに関するよくある誤った実装と仕様の曖昧な箇所について述べ、その結果起きる問題を解決するためのガイダンスを開発者に対して提供している。SigCompはSIP（Session Initiation Protocol）などのアプリケーション層プロトコルが生成したメッセージを圧縮するためのスキーマを定義しており、RFC 4896によって、RFC 3320、RFC 3321、RFC 3485の内容が更新される。

　モバイルIPv4の地域登録に関する実験的仕様がRFC 4857として承認された。
　モバイルIPを使う場合、モバイルノードは気付アドレスの変更のたびにホームエージェントに気付アドレスを登録し直す。RFC 4857は新たな種類である「地域登録」について述べている。この場合の登録手続きはホームエージェントではなく、訪問先のドメインである。
　地域登録はGFA（Gateway Foreign Agent）と呼ばれる新しいネットワーク機器を通して実行され、このために訪問先ドメインのネットワーク階層に新たな層を加える。地域登録によってホームエージェントへのシグナリング回数が減り、訪問先ドメインが同じであればある移動先エージェントから別の移動先エージェンにモバイルノードが移動した場合のシグナリングの遅延も減らせる。地域登録はモバイルIPv4のオプション拡張である。

　tel/sip URI（Uniform Resource Identifier）におけるトランク群の表記の仕様がRFC 4904として勧告された。
　RFC 4904はsipおよびtel URIにおいて、トランク群パラメーターを伝送するための標準化されたメカニズムについて述べている。そのために、tel URIに対する拡張仕様を定義している。

　標準化過程文書に対する規範的参照の取り扱いに関する文書がRFC 4897として承認された。
　IETF（The Internet Engineering Task Force）とRFC（Request for Comments）編集者は、長期にわたって、参照先のすべての文書の成熟度が参照元の文書の標準化過程における成熟度と同じがそれ以上でない限り、文書を発行しないというルールに基づいてきた。しかし、このルールはしばしば文書の公開に遅れを来すほか、標準化過程文書の成熟度を進行させる上での障害になっているとの指摘もあるほどである。IETFはRFC 3967によってこのルールを迂回する場合があるが、RFC 4897は、参照先の標準化過程またはBCP（Best Current Practice）文書の成熟度が参照元よりも低い場合のより簡単な手続きについて述べている。つまり、「メモって前に進め！」というわけである。
　なお、RFC 3967に定められた手続きは参照先が標準化過程またはBCPではない場合には引き続き適用される。いずれにしても、参照先についての注釈は加えられるべきである。

　メッセージの事前送信用SMTP投函サービス拡張の仕様がRFC 4865として勧告された。
　RFC 4865はSMTP投函プロトコルの拡張仕様を定義し、クライアントがメッセージの配信日時を指定できるようにする。この拡張仕様により、クライアントは予定された日時になるまで、メッセージをサーバー側に保管し、サーバーから実際の配信キューに移せるようになる。ローカルストレージを持たないクライアントや、ある日時までメッセージを配信用に送信できない場合に便利である。

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