OSPF-xTE（Experimental Extension to OSPF for Traffic Engineering）の実験的仕様がRFC 4973として承認された。
　RFC 4973はOSPF-xTEと呼ばれる、リンク状態ルーティングプロトコルであるOSPFへのトラフィックエンジニアリング拡張技術を定義している。OSPF-xTEが定義しているのはAS（Autonomous System：自律システム）内のTEの計測値を広めるための新しいTE LSA（Link State Advertisement：リンク状態広告）である。（ASは複数のエリアから成り立っていてもよい）
　ASがTEと非TEノードから成り立っている場合、OSPF-xTEは非TEノードがTE LSA から影響を受けないことを保証している。OSPF-xTEはTEのサーキット経路を算出するために、元々のOSPF LSDB（Link State Database）とは区別される、独立したTE-LSDB（TE Link State Database）を生成する。OSPF-xTEは多くの用途に利用でき、SONET/TDM（Synchronous Optical Network/Time Division Multiplexing）や光ネットワークのような非パケット型のネットワークにも拡張可能である。

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

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

　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文書をバイナリ符号化するコンパクトな代替形式にもなる。

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

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

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

　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に返還される。

　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が共有する帯域幅をかなり多めに使うことがわかった。

　OSPFリンクローカルシグナリングの実験的仕様がRFC 4813として承認された。
　OSPFはIPネットワークで使われるリンクステート型のドメイン内ルーティングプロトコルである。OSPFルーターは、きちんと定義された形式のパケットを使って、リンク上で情報を交換している。ただし、OSPFパケットの形式は、ある種の状況では必要になる、アプリケーションによる任意のデータ交換ができるほどには柔軟ではない。
　RFC 4813は、リンク上で任意のデータを交換するような、リンクローカルシグナリングを実現するベンダー固有の後方互換性のあるテクニックについて述べている。

　IDMEF（Intrusion Detection Message Exchange Format：侵入検知メッセージ交換形式）の実験的仕様がRFC 4765として勧告された。
　IDMEFの目的は、データ形式を定義して侵入検知と対応システム、それらを操作する管理システムにとって重要な情報を共有するための手続きを交換することである。
　RFC 4765は侵入検知システムがエクスポートする情報を表現するためのデータモデルについて述べ、このモデルを使う理論的根拠について説明している。また、XML（Extensible Markup Language）によるこのデータモデルの実装が示され、XMLのDTD（Document Type Definition）も用意され、使用例も提示されている。

　IDXP（Intrusion Detection Exchange Protocol：侵入検知交換プロトコル）の実験的仕様が、RFC 4767として承認された。
　RFC 4767は侵入検知システム間でデータを交換するためのアプリケーション層プロトコルであるIDXPについて述べている。IDXPはコネクション指向のプロトコル上での相互認証や完全性、機密性に対応している。IDXPによって、侵入検知システムはIDMEFメッセージや非構造化テキスト、バイナリーデータを交換できる。なお、IDMEFメッセージ要素はIDWGによる関連文書である「IDMEF（侵入検知メッセージ交換形式）」（RFC 4765）で述べられている。

　IPv4用モバイルアドホックネットワークのためのDSR（Dynamic Source Routing）の実験的仕様がRFC 4728として承認された。
　DSRはシンプルで効率的なルーティングプロトコルで、特に移動ノードのマルチホップ無線アドホックネットワーク用に設計されている。DSRによって、ネットワークは完全に自己組織化および自己構成ができるようになり、既存のネットワーク基盤は管理は不要になる。DSRプロトコルは「経路探索」と「経路維持」という2つの主要なメカニズムからなり、協調して動作することで、ノードがアドホックネットワークにおいて任意の宛先への経路を発見したり維持したりできるようにする。すべてのプロトコル操作は要求によって始まり、DSRのルーティングパケットの積み重ねによって、現在の経路からの変化に対処するために必要なことのみに自動的に調整できる。また、DSRプロトコルはどの宛先についても複数の経路を扱えるようになっており、たとえば負荷分散や安定性の向上のために、送信側はパケットのルーティングでどの経路を用いるのか選んだり制御したりできる。
　DSRプロトコルの他のメリットとして、ループしないルーティングや単一方向リンクのネットワーク運用、ルーティングにおけるソフト状態のみの利用、ネットワーク内の経路変更時の非常に高速な回復などが簡単に保証できることがある。DSRプロトコルは、おもに最大200ノードまでのモバイルアドホックネットワーク用に、移動が高頻度で起きても動作するように設計されている。
　RFC 4728はユニキャストIPv4パケットのルーティング用のDSRプロトコルの運用仕様について定めている。

　TCPおよびIP用のクイックスタートの実験的仕様がRFC 4782として承認された。
　RFC 4782は、通信開始時、場合によっては（一定の通信アイドル後など）データ伝送時にルーターと協調することで送信レートを判断するトランスポート層プロトコル用のクイックスタートメカニズムのオプション仕様を定めている。
　なお、クイックスタートはさまざまなトランスポート層プロトコルで用いられているが、RFC 4782ではTCPでの利用のみ仕様を定めている。クイックスタートにより、経路に明白な未使用帯域がある場合、コネクションはより高いレートで送信できるようになる。また、送信側と経路上のすべてのルーターはクイックスタート要求を承認するか決められる。
　RFC 4782はクイックスタート要求が承認されないであろう多くの経路についても述べている。こうした経路とは、クイックスタートに対応しないルーターやIPトンネル、MPLS経路などが含まれる。また、IPのオプションヘッダーを取り除いてしまうルーターや他の中継機器のある経路でもクイックスタート要求は承認されない。また、複数のネットワークプロトコルからなるレイヤ2ネットワークでも、クイックスタート要求を承認するのは難しい。さらにRFC 4782は、送信側が間違ってクイックスタート要求が経路上のすべてのルーターで承認されたと誤認するなど、クイックスタートの処理が誤って失敗する環境についても述べている。こうした点を考慮し、さらにコアルーターなどがクイックスタートに対応するメリットが見いだせないことから、クイックスタートはインターネット全体での利用は意図せず、適切でもないため、管理された環境でのみ利用できるメカニズムとして提案された。

　EAP-PSKプロトコルの事前共有鍵EAPメソッドに関する実験的仕様がRFC 4764として承認された。
　RFC 4764はEAP-PSKの仕様を定めている。EAP-PSKとは、事前共有鍵（PSK：Pre-Shared Key）を使った相互認証とセッション鍵の生成用のEAPメソッドである。EAP-PSKによって、暗号化された通信チャネルを通信用の相互認証をすませた両者が利用できるようになる。RFC 4764はEAPの応答を暗号してやりとりする目的のみ述べているが、将来のEAP-PSK拡張は他の用途にも利用可能である。EAP-PSKはIEEE 802.11のような安全ではないネットワーク上の認証用に設計されている。

　IKEv2（Internet Key Exchange）プロトコルにおける複合認証交換に関する実験的仕様がRFC 4739として承認された。
　IKEv2プロトコルは、送受信側双方を認証用のメカニズムとして、公開鍵証明書付きの署名や秘密鍵の共有、EAP（Extensible Authentication Protocol）のメソッドなどに対応している。しかし現在のところ、それぞれのエンドポイントはこうしたメカニズムのうち1つだけを使って自身を認証している。そこでRFC 4739では、IKEv2の拡張仕様を定めて、異なるメカニズムや同じメカニズムを複合的に用いて、認証情報を交換できるようにしている。この拡張仕様により、EAPのユーザー認証に先立って証明書に基づくクライアントマシンの認証を実行する、といったことが可能になる。また、ネットワークアクセスプロバイダーやサービスプロバイダーなど、異なる管理ドメインに所属する認証サーバーを別に用意し、それぞれで認証させるような運用も可能になる。

　MSDP（Multicast Source Discovery Protocol）MIB（Management Information Base）の実験的仕様がRFC 4624として承認された。インターネットにおけるネットワーク管理のために、MIBの一部として使われる。
　RFC 4624はRFC 3618で定義されているMSDP（Multicast Source Discovery Protocol）のスピーカー用管理オブジェクトについて述べている。

　ネットニュース管理システム（NAS：Netnews Administration System）に関する実験的仕様がRFC 4707として承認された。
　NASはインターネット上のネットワークニュース（Netnews）の管理と利用を簡潔にするためのフレームワークである。ニュースグループと階層構造の管理用のデータは分散型の階層的データベースに格納され、クライアント／サーバー型のプロトコルで利用可能である。
　データベースはニュースサーバーやニュース管理者、ニュース読者からアクセスできる。ニュースサーバーは構成を自動的に更新可能で、管理者は手動でデータを取得する。ニュース取得用のプログラムは自動的またはユーザーの操作によって、ユーザーにグループや階層構造の詳細な情報をNASサーバーから取得できる。
　NASは現在のすでに確立された制御メッセージの手続きと共存可能であり、不要な干渉は不可能である。さらにNASは階層構造データベースにおけるUsenetのある種の無秩序さも反映可能である。また、NASは既存のニュースリレーやニュースサーバー、ニュースリーダーソフトウェアを更新せずに利用可能である。ただし、NAS互換のソフトウェアの方がいくつかのタスクを簡潔に実現できる。

　IETF運営の覚え書きに関する実験的仕様がRFC 4693として承認された。
　RFC 4693は、IETF活動の内容を文書として記録するために用いる新しい文書シリーズについて述べている。この新しい文書シリーズは、RFCよりも有効期間が短いが、インターネットドラフトよりは参照しやすく、各執筆者が勝手にWebページに文書をアップロードするよりはより手続きが明解になることを目指す。 RFC 4693は、この新しい文書シリーズがRFC 3933の意志決定過程の実験となることを提案している。

　前後のDNS名の生成に関する実験的仕様がRFC 4471として承認された。
　RFC 4471は、あるDNS名の前後を正規化されたDNS名順に取得するための2つの方法について述べている。この方法は動的NSEC資源レコードの同期に用いられ、DNSSEC対応のネームサーバーがDNSSECのセキュアゾーンにある他のオーナー名を公開せずに不存在の証明を実現できるようになる。

　非輻輳イベントに対するTCPの頑強さの向上に関する実験的仕様がRFC 4653として承認された。
　RFC 4653は、TCP用にNCR（Non-Congestion Robustness：非輻輳型の頑強性）の仕様を定めている。ネットワークからの明示的な輻輳通知機能が存在しないために、TCPはパケットの消失を輻輳の指標に用いている。TCPがパケットの消失を検出する1つの方法は、3重の確認応答（ACK）が到着を用いることである。しかし、こうした発見的手法がつねに正しいとは限らない。特にネットワーク経路が何らかの理由でセグメントを再配置した場合、著しいパフォーマンスの低下を引き起こす。
　そこで、セグメントの再配置と本当にセグメントが消失したことをよりはっきりと区別しようとしながら、コネクションの現在の状態に基づいて消失復旧のトリガーとなる確認応答の重複数を増やすことで、TCP-NCRパフォーマンスの低下を抑える。また、RFC 4653は、この変更の是非と共にTCPの変更について定めている。

　IETF（Internet Engineering Task Force）メーリングリストへの長期投稿禁止措置における実験に関する実験的仕様がRFC 4633として承認された。
　IETF内の議論で、RFC 3683およびRFC 3934がIETFメーリングリストを運営するための適度な柔軟性を持っているかについての疑問が提示された。RFC 4633は、メーリングリストを運営するためのさまざまな手段をコミュニティが備えて検証するためのRFC 3933による実験である一方で、メーリングリストへの長期投稿禁止措置がどうあるべきかを判断しようとしている。
　

　TFMCC（TCP-Friendly Multicast Congestion Control：TCPと共存可能なマルチキャスト輻輳制御）プロトコルの実験的仕様がRFC 4654として承認された。
　TFMCCとは、インターネットのベストエフォート環境におけるマルチキャスト伝送用の輻輳制御メカニズムである。単一レートの輻輳制御スキームであり、送信レートは受信側から見た最悪のネットワーク条件に適合される。
　また、TFMCCはTCPフローと帯域幅が競合する場合におおよそ公平であり、通信中のスループットが比較的変化が少ないため、送信レートが急激に変化しないことが重要なストリーミングメディアなどのアプリケーションに適している。

　IPv6ノード情報の問い合わせに関する実験的仕様がRFC 4620として承認された。
　IPv6の現場への導入により、サーバーのない環境やデバッグ目的でホスト名その他の情報を直接問い合わせるメカニズムの有用性がわかった。そこで、RFC 4620は、IPv6ノードにホスト名やFQDN（Fully-Qualified Domain Name：完全修飾ドメイン名）といったネットワーク情報を提供するように要求するためのプロトコルについて述べている。

　LDAP（Lightweight Directory Access Protocol：軽量ディレクトリアクセスプロトコル）のコンテント同期オペレーションに関する実験的仕様がRFC 4533として承認された。
　コンテント同期オペレーションは、クライアントがDIT（Directory Information Tree：ディレクトリ情報ツリー）の断片のコピーを保持できるようにする。変更を検知する方式としては、ポーリングやLDAPサーバからの通知に対応する。コンテント同期オペレーションはLDAP検索オペレーションの拡張として定義される。
　

　LDAP（Lightweight Directory Access Protocol：軽量ディレクトリアクセスプロトコル）のTurn操作に関する実験的仕様がRFC 4531として承認された。
　RFC 4531はLDAPを拡張し、セッション中の以後のプロトコルのやりとりでクライアントとサーバの役割を反転（Turn）させたり、他のLDAPホストに対して、どちらもがクライアントまたはサーバとして振る舞うようにする操作について述べている。

　管理オブジェクト集合MIBの実験的仕様がRFC 4498として承認された。ネットワーク管理用にMIB（Management Information Base：管理情報ベース）の一部として使われる。
　集合MIBモジュールはネットワーク管理エージェントを構成して管理オブジェクトインスタンスのユーザー固有の値を集約し、集約した管理オブジェクトのインスタンスに関連する問い合わせを処理するために使われる。

　ファイアウォールやNATなどの機能を持つミドルボックスを制御するためのプロトコルの実験的仕様がRFC 4540として承認された。
　ミドルボックスとはネットワークの中間に位置し、ファイアウォールやNAT、IPsecサービスなどのミドルボックスサービス（ミドルボックス機能ともいう）を提供する装置のことである。RFC 4540のプロトコル仕様はミドルボックスの通信（MIDCOM）について定義しているRFC 3989に完全に準拠している。また、SIMCOプロトコルの初期の実験的仕様に比べて、バージョン3.0ではバイナリーメッセージエンコードを使うことでハードウェアなどの性能要件を緩めている。

　電子メールでドメインの利用を認証するためのSPF（Sender Policy Framework）バージョン1の実験的仕様がRFC 4408として承認された。
　インターネットの電子メールは、いくつかの方法で偽造できる。特に既存のプロトコルは送信ホストが用いるメッセージの復路やSMTPのHELO/EHLOコマンドで用いるドメイン名について、何の規制もしていない。そこでRFC 4408では、SPFプロトコルバージョン1の仕様を述べ、ホストがあるドメインを名乗ることを明確に認めるための方法と受信ホストがそのドメインを確認する方法について述べている。

　PRA（Purported Responsible Address：推定責任アドレス）を導き出すためのアルゴリズムの実験的仕様がRFC 4407として承認された。
　RFC 4407はあるメッセージが配信されたことについて責任をもつであろう人物などを電子メールメッセージから取り出すためのアルゴリズムを定義している。取り出されたアドレスはPRAと呼ばれる。

　送信者IDの実験的仕様がRFC 4406として承認された。
　インターネットの電子メールで多くの望まれないメッセージが飛び交っているのは、差出人アドレスを偽造したメッセージを送信できるからである。「偽造」とはこの場合、あるメールアドレスが、そのメールアドレスに含まれるドメインの所有者の許可無く使われることを意味する。そこでRFC 4406では、受信したメッセージの差出人メールアドレスのドメインの所有者の許可があるかどうかをSMTPサーバーが判断するための検査方法について述べている。

　SMTP（Simple Mail Transfer Protocol）を拡張してSMTPクライアントが電子メールメッセージの投函責任者を特定できる実験的仕様がRFC 4405として承認された。
　投函責任者とは、受信クライアントから見てメッセージを中継させたことについて直近の責任を持つメールアドレスのことである。RFC 4405により、受信側のメールサーバーは送信側のSMTPクライアントが投函責任者のドメインを使ってメッセージを中継する権限があるのかについて、的確に判断できるようになる。

　IKEv2（Internet Key Exchange version 2）プロトコルにおける繰り返し認証に関する実験的仕様がRFC 4478として承認された。
　特にリモートアクセス目的でIPsecを使うコンピュータ間では、第三者がIPsecの通信コネクションの制御権を奪取しないように、SA（Security Association）の利用可能時間を制限するために、一定の間隔で相互に繰り返し認証するのが望ましい。そこでRFC 4478では、IKEv2プロトコルにおいて認証を繰り返す機能について述べている。

　ND（Neighbor Discovery：近隣探索）プロキシーの実験的仕様がRFC 4389として承認された。
　2つ以上のリンクを1つのリンクにブリッジ接続すると、いくつかの運用上のメリットがある。しかし、1つのサブネット用のプレフィックスがあれば2つ以上の物理層のリンクを束ねられるため、それぞれの物理層ネットワークに異なるサブネット番号を割り当てる必要はないにもかかわらず、下位層の種類によっては、ネットワーク層が対応していないとブリッジ接続できない場合がある。
　そこでRFC 4389では、こうしたケースについて説明し、IP層での対応によってブリッジ接続を実現する方法について述べている。

　WebDAVを拡張してクライアントからHTTPのリダイレクト先を更新するための実験的仕様がRFC 4437として承認された。更新できるのは、HTTPの応答コードが「HTTP/1.1 3xx」となっているWebページである。リダイレクト参照によって、URIで関連づけるあらゆるリソースにWebページから間接的にアクセスできるようになる。
　なお、この仕様はリソースのツリー構造の再配置や正規表現を使ったリダイレクトについては扱わない。リダイレクト参照リソースに関連する技術的統合を図るものではなく、他の仕様によって同じ機能が実現できる場合もある。むしろ、WebDAVを使ったダイレクト参照リソースに関する問題点の議論や技術的改善を多くの運用によって促すのが目的である。

　SRMP（Selectively Reliable Multicast Protocol：選択的な信頼性のあるマルチキャストプロトコル）の実験的仕様がRFC 4410として承認された。
　SRMPとは、信頼性のある通信とベストエフォート型の通信が混在するANY対ANYのマルチキャスト環境において利用するトランスポート層プロトコルである。また、このマルチキャスト環境では信頼性のある通信よりもベストエフォート型の通信のトラフィックの方が遙かに多く、それゆえパケット消失を検出するためのシーケンス番号を信頼性のある通信で用いるパケットでも伝送する。
　SRMPは分散型のシミュレーションアプリケーション環境での利用を想定しており、そうした環境では特定のデータ識別子用の最新の信頼できる伝送だけが必要とされる。そのためSRTPには、メッセージの集成と輻輳制御を扱うバンドル副層と、SRT（Selectively Reliable Transport：選択的な信頼性のあるトランスポート）副層の2つの副層がある。信頼性のある通信とベストエフォート型の通信のどちらを選択するかは、アプリケーションによって判断される。

　公開鍵基盤（PKI）のリポジトリロケーターサービスについての実験的仕様がRFC 4386として承認された。RFC 2782に従って定義されたDNS SRVレコードを利用して、証明書を利用するシステムがPKIリポジトリの場所を突き止められるようにするサービスである。

　ISATAP（Intra-Site Automatic Tunnel Addressing Protocol：サイト間自動トンネルアドレッシングプロトコル）の実験的仕様がRFC 4214として承認された。
　ISATAPとは、IPv4ネットワーク上のIPv6ホストやルーターを接続するためのプロトコルである。IPv4ネットワークをIPv6ネットワークのリンク層と見立てて、ネットワーク上の他のノードをIPv6のホストやルーターになりうる存在とみなす。ISATAPが対応しているトンネリングによるネットワークの抽象化は、NBMA（Non-Broadcast Multiple Access：非ブロードキャスト型多重アクセス）に類似したモデルである。

　ローカルモビリティを扱うためのモバイルIPv6とIPv6の近隣探索を拡張する実験的仕様がRFC 4140として承認された。
　モバイルIPv6用の階層的なモビリティ管理は、通信相手ノードおよびホームエージェントといったモバイルノード間のシグナリング量を減らすために設計された。また、RFC 4140で述べられているMAP（Mobility Anchor Point）は、モバイルIPv6のハンドオーバー速度面での性能を向上させるためにも利用できる。

　偽造されたTCP再送タイムアウト用のF-RTO（Forward Retransmission Timeout：転送再送タイムアウト）検出アルゴリズムの実験的仕様がRFC 4138として承認された。
　偽造再送タイムアウトがTCPの性能低下を引き起こすのは、直近のTCPウィンドウの不要な再送を引き起こすことがあるからである。
　F-RTOとはTCPの受信側のみで使えるアルゴリズムで、処理のためにTCPオプションを使う必要はない。タイムアウトによって確認応答のないセグメントを最初に再送したあとで、TCP送信側のF-RTOアルゴリズムはタイムアウトが偽造かどうかを判定するために到着する確認応答を監視し、新しいTCPセグメントを送信するか、確認応答のないセグメントを再送するか判断する。F-RTOアルゴリズムによって不要な再送を防ぐことで効率を高め、偽装タイムアウト時のTCPの性能を向上させる。また、F-RTOアルゴリズムはSCTP（Stream Control Transmission Protocol：ストリーム制御伝送プロトコル）にも適用可能である。

　モバイルIPv6用の高速ハンドオーバーの実験的仕様がRFC 4068として承認された。
　モバイルIPv6によって、移動端末はあるアクセスルーターから別のアクセスルーターに移動するとき、「ハンドオーバー」と呼ばれる処理により、インターネットへの接続を保てるようになる。
　しかしハンドオーバーの際、切り替えの遅延やIPプロトコルの処理のために、移動端末がパケットを送受信できなくなる時間がある。こうした「ハンドオーバーレイテンシー」は標準的なモバイルIPv6の手続きや移動の検知、新しいCoA（Care of Address：気付アドレス）の構成、バインディング更新、により引き起こされるが、VoIP（Voice over IP）のようなリアルタイムトラフィックには障害の原因になってしまう。また、ハンドオーバーレイテンシーを減らすことは、非リアルタイムでもスループットの性能に依存するようなアプリケーションにも有用である。
　そこでRFC 4068では、モバイルIPv6手続きのためのハンドオーバーレイテンシーを改善する仕様を定めている。ただし、RFC 4068の仕様は、リンク交換レイテンシーの改善をあつかうものではない。

　認証されたコンテキストの伝送を可能にするCXTP（Context Transfer Protocol：コンテキスト伝送プロトコル）の実験的仕様がRFC 4067として承認された。
　コンテキスト伝送によって、移動端末上で動作するアプリケーションがなるべくネットワークの切断の影響を受けないようにすることである。レイテンシーとパケットの消失を削減することが主な目的で、CXTPにより移動端末のシグナリングを再初期化しなくて済むようになる。

　CARD（Candidate Access Router Discovery：アクセスルーター候補の探索）の実験的仕様がRFC 4066として承認された。
　移動端末（MN：Mobile Node）があるアクセスルーター（AR：Access Router）から別のアクセスルーターにスムーズにIP層でハンドオーバーするには、移動端末がハンドオーバーの開始に先立って接続先の候補となるアクセスルーター（CAR：Candidate AR）の所在を探索する必要がある。CARの探索には、CARのIPアドレスの識別とCARの機能を確認するという2つの側面があり、この処理をCARD（Candidate Access Router Discovery：アクセスルーター候補の探索）と呼ぶ。
　IP層でハンドオーバーするとき、移動端末の優先度に合致する機能を持つCARがハンドオーバー用のターゲットアクセスルーターとして選ばれる。RFC 4066で述べられている方法により、移動端末はCARDを実行できるようになる。

　Seamobyおよび実験的な移動プロトコルのIANA登録用の指示がRFC 4065として承認された。
　SeamobyのCARD（Candidate Access Router Discovery：アクセスルーター候補探索）プロトコルとCXTP（Context Transfer Protocol ：コンテキスト伝送プロトコル）は実験的なプロトコルで、無線アクセスルーター間のIPハンドオーバーを高速化するように設計されている。しかし、CARDプロトコルとCXTPを使うには、ICMPタイプとオプション、SCTP（Stream Control Transmission Protocol：ストリーム制御伝送プロトコル）のペイロードプロトコル識別子、ポート番号、メッセージ形式オプションの登録が必要である。
　そこでRFC 4065では、Seamobyプロトコルに必要な割り当てのIANAへの指示を含んでいる。なお、他の実験的移動性プロトコルでも利用できるように、Seamoby用のICMPサブタイプ拡張形式を追加的に設計されている。また、SCTPポート番号も他の実験的移動性プロトコルで利用可能である。

　Diffservを意識したMPLSトラフィックエンジニアリング用の「マトリョーシカ」式帯域幅制限モデルの実験的仕様がRFC 4127として承認された。

　Diffservを意識したMPLSトラフィックエンジニアリングとパフォーマンス比較用の予約帯域幅制限モデルによる「最大割り当て」方式の実験的仕様がRFC 4126として承認された。
　RFC 4126では、Diffservを意識したトラフィックエンジニアリング（DS-TE：Diffserv-aware MPLS Traffic Engineering）の要件を、予約帯域幅制限モデルによる「最大割り当て」方式（MAR：Maximum Allocation with Reservation）用の機能仕様を提示することによって補っている。予約帯域幅制限モデルによる「最大割り当て」方式の前提や適用性、運用例などが示されてる。
　MARのパフォーマンスは帯域幅制限モデルの選択基準によって相対的であることがわかった。こうした分析により、ユーザーのネットワークで採用するときのガイドラインを提示している。

　Diffservを意識したMPLSトラフィックエンジニアリング用の「最大割り当て」式帯域幅制限モデルの実験的仕様がRFC 4125として承認された。