Independent Submission M. Blanchet
Request for Comments: 9564 Viagenie
Category: Informational 1 April 2024
ISSN: 2070-1721
The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than LIght speed Protocol (FLIP) for Internet. FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on the Internet by using AI to predict future packets at the receiving peer before they arrive. This document describes the protocol, its various encapsulations, and some operational considerations.
大規模な言語モデルなどの人工知能（AI）の最近の進歩により、インターネットのライトスピードプロトコル（FLIP）よりも速い設計が可能になります。Flipは、AIを使用して受信ピアで到着する前に将来のパケットを予測することにより、混雑を回避し、セキュリティを強化し、インターネット上のより速いパケットを配信する方法を提供します。このドキュメントでは、プロトコル、そのさまざまなカプセル、およびいくつかの運用上の考慮事項について説明します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開されることが承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9564.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9564で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Protocol Peer Preparation
3. FLIP Header
4. Protocol Operation
5. Versioning
6. Future Work
7. IANA Considerations
8. Security Considerations
9. Informative References
Acknowledgements
Author's Address
ChatGPT was introduced to the public on 30 November 2022 [CHATGPT]. Since then, large language models (LLMs) have been used for a large variety of applications. It demonstrates the powerful ability to generate precise output based on the input and based on the appropriate training of the LLM. This protocol specification uses this ability to predict future packets before they arrive at the receiving peer, therefore achieving faster-than-light-speed delivery, hence the protocol name: Faster than LIght speed Protocol (FLIP).
ChatGptは2022年11月30日に一般に紹介されました[ChatGpt]。それ以来、大規模な言語モデル（LLM）が多種多様なアプリケーションに使用されてきました。入力に基づいて、LLMの適切なトレーニングに基づいて、正確な出力を生成する強力な能力を示しています。このプロトコル仕様は、この機能を使用して、将来のパケットが受信ピアに到達する前に予測するため、明るい速度よりも速い速度の配信を実現するため、プロトコル名：ライトスピードプロトコル（FLIP）よりも速いです。
Since FLIP can predict packets, frames, strings, or byte streams, it could be used at any layer of the IP protocol stack. Moreover, with proper training, FLIP can also predict future encrypted packets, as encryption is just strings of bytes. This specification shows FLIP as a Layer 2 shim as well as a transport shim layer. Since FLIP can be used at any layer, it is expected that additional specifications will be created, such as predicting HTTP requests and answers, email content, and more.
Flipはパケット、フレーム、文字列、またはバイトストリームを予測できるため、IPプロトコルスタックの任意のレイヤーで使用できます。さらに、適切なトレーニングを使用すると、暗号化はバイトの文字列にすぎないため、Flipは将来の暗号化されたパケットを予測することもできます。この仕様は、フリップがレイヤー2シムとして、およびトランスポートシム層としてのことを示しています。Flipは任意のレイヤーで使用できるため、HTTPリクエストと回答の予測、電子メールコンテンツなど、追加の仕様が作成されることが予想されます。
Since communications in deep space are unfortunately limited to light speed, and given the very large distances between spacecrafts and Earth, the consequence is very long delays. By offering faster-than-light-speed delivery, FLIP is a key enabler and addition to deep-space IP networking [IP-DEEP-SPACE].
残念ながら深宇宙での通信は光の速度に限定されており、宇宙船と地球の間の非常に大きな距離を考えると、結果は非常に長い遅延です。速度よりも速い配信を提供することにより、Flipは重要なイネーブラーであり、ディープスペースIPネットワーキング[IP Deep-Space]に追加されます。
In order to successfully achieve faster than light speed, the peers of any protocol layer used by FLIP must prepare their side of the connection with the right model trained for the specific case. This document does not dictate any specific LLM, as the implementations may choose the one that best works for their use case and train them accordingly. As with any LLM, it is paramount to use a lot of training data, such as packet captures, in a variety of conditions to produce the best trained model. To avoid security, privacy, and legal issues, the specifics of which LLM is used, how it was trained, and what is the data set used, shall not be published nor disclosed in the protocol.
光速度よりも速く成功するためには、FLIPで使用されるプロトコル層のピアは、特定のケースで訓練された適切なモデルとの接続の側面を準備する必要があります。このドキュメントは、実装がユースケースに最適なものを選択し、それに応じてトレーニングするため、特定のLLMを指示しません。他のLLMと同様に、パケットキャプチャなどの多くのトレーニングデータをさまざまな条件で使用して、最高の訓練されたモデルを作成することが最重要です。セキュリティ、プライバシー、および法的問題を回避するために、LLMが使用される詳細、その訓練方法、および使用されるデータセットは、プロトコルに公開または開示されてはなりません。
As an example, an implementation may elect to collect a significant number of Packet Capture (PCAP) files from tcpdump wiretapping at various vantage points on the Internet. The fact that traffic may be encrypted is not an issue, since a well-trained LLM will be able to predict encrypted traffic as accurately as unencrypted traffic.
例として、実装は、インターネット上のさまざまな視点でTCPDUMP盗聴からかなりの数のパケットキャプチャ（PCAP）ファイルを収集することを選択する場合があります。よく訓練されたLLMは暗号化されていないトラフィックと同じくらい正確に暗号化されたトラフィックを予測できるため、トラフィックが暗号化される可能性があるという事実は問題ではありません。
Wherever FLIP is used (below IP, above IP or other transport, or at the application layer), a FLIP shim header is inserted.
フリップが使用される場合（IP以下、IPまたはその他のトランスポート、またはアプリケーション層で）、フリップシムヘッダーが挿入されます。
+----------+---------+----------------+----------------+
| Version | Command | Inner Protocol | Optional Data |
+----------+---------+----------------+----------------+
The header contains the following fields:
ヘッダーには次のフィールドが含まれています。
Version:
バージョン：
A field of variable and unspecified length that contains the SHA-256 hash of the model, used as the version, as described in Section 5.
セクション5で説明されているように、バージョンとして使用されるモデルのSHA-256ハッシュを含む可変および不特定の長さのフィールド。
Command:
指示：
The codepoint identifying the operation of this FLIP frame. Commands are described in Section 4. The initial list of valid FLIP commands is below.
このフリップフレームの動作を識別するコードポイント。コマンドはセクション4で説明されています。有効なフリップコマンドの初期リストは以下にあります。
The maximum number size is infinite, given that artificial intelligence peers can support an infinite number of commands, by just updating their models without the need to update their protocol implementation.
プロトコルの実装を更新することなくモデルを更新するだけで、人工知能のピアが無限の数のコマンドをサポートできることを考えると、最大数のサイズは無限です。
+=========+===========+===========+
| Command | Codepoint | Reference |
+=========+===========+===========+
| model | 0x01 | RFC 9564 |
+---------+-----------+-----------+
| data | 0x02 | RFC 9564 |
+---------+-----------+-----------+
Table 1
Inner Protocol:
内部プロトコル：
As the FLIP header is a shim header, the inner protocol is specified in this field. For example, for a FLIP shim header inserted between IP and TCP, the IP packet will contain the FLIP codepoint as the transport protocol. The FLIP inner protocol field will then contain the TCP codepoint that would otherwise be in the IP packet.
フリップヘッダーはシムヘッダーであるため、インナープロトコルはこのフィールドで指定されています。たとえば、IPとTCPの間に挿入されたフリップシムヘッダーの場合、IPパケットにはトランスポートプロトコルとしてFlip CodePointが含まれます。その後、フリップインナープロトコルフィールドには、それ以外の場合はIPパケットにあるTCPコードポイントが含まれます。
Optional Data:
オプションのデータ：
Some commands have additional data that are following the Command field.
一部のコマンドには、コマンドフィールドに従っている追加データがあります。
The header length is variable and depends on which command is used. Given the use of artificial intelligence by implementations of this protocol, the actual length of the header, and the length of each of its fields, is not specified in the header. Instead, it is expected that the proper neural network on the receiver side will be able to find the actual header termination, thus saving many header bits.
ヘッダーの長さは可変であり、どのコマンドが使用されるかによって異なります。このプロトコルの実装による人工知能の使用を考えると、ヘッダーの実際の長さとその各フィールドの長さは、ヘッダーでは指定されていません。代わりに、レシーバー側の適切なニューラルネットワークが実際のヘッダー終了を見つけることができるため、多くのヘッダービットを保存できると予想されます。
To properly signal the upper layer about the presence of the FLIP header, a specific codepoint is reserved at the layer below FLIP. Section 7 lists the registrations for IP and transport codepoints for this use.
フリップヘッダーの存在について上層層を適切に通知するために、特定のコードポイントがフリップの下のレイヤーに予約されています。セクション7には、この使用のためのIPおよびトランスポートコードポイントの登録を示します。
Prior to sending a first packet using FLIP, the sender and the receiver should be configured with the appropriate model trained as discussed before. It is left to the implementation to choose the right LLM and the right training data set.
Flipを使用して最初のパケットを送信する前に、送信者と受信機は、前に説明したようにトレーニングされた適切なモデルで構成する必要があります。適切なLLMと適切なトレーニングデータセットを選択するのは実装に任されています。
The following commands are defined:
次のコマンドが定義されています。
Model:
モデル：
(codepoint 0x01). This command provides a way for peers to send their model in-band of the FLIP protocol. The model itself is carried in the Optional Data field of the FLIP header. Prior to the actual model data, a MIME header is inserted with the proper media type. If the media type for the model does not exist, it should be registered in the IANA Media Type registry.
（CodePoint 0x01）。このコマンドは、ピアがフリッププロトコルのバンド内のモデルを送信する方法を提供します。モデル自体は、フリップヘッダーのオプションのデータフィールドに携帯されています。実際のモデルデータの前に、MIMEヘッダーが適切なメディアタイプで挿入されます。モデルのメディアタイプが存在しない場合、IANAメディアタイプレジストリに登録する必要があります。
Data:
データ：
(codepoint 0x02). This command tells the receiving peer that the data that follows can be predicted and therefore achieves faster-than-light-speed performance.
（CodePoint 0x02）。このコマンドは、受信ピアに、以下のデータを予測できるため、明るいスピードよりも速いパフォーマンスを達成できることを伝えます。
Sending the model in-band to the other peer is an operation that should be done rarely, as models may be large in size. Moreover, it actually discloses the model for any wiretapping adversary. Implementors may consider using a post-quantum cryptographic algorithm that is also immune to AI prediction, therefore a post-Quantum-AI cryptographic algorithm.
モデルを他のピアにインバンド内で送信することは、モデルのサイズが大きい可能性があるため、めったに行うべきではない操作です。さらに、実際には、盗聴敵のモデルを開示しています。実装者は、AI予測の免疫、したがってQuantum-ai後の暗号化アルゴリズムを免疫する後の暗号化後のアルゴリズムの使用を検討する場合があります。
As described in [RFC6709], most protocols should be designed to enable future enhancements, such as providing a way to signal a new version of the protocol. In the case of FLIP, trained models will always be enhanced by new training. A SHA-256 [RFC6234] hash of the trained model is used as a version number so each peer knows which FLIP version is being used. The SHA-256 hash is put in version field in the FLIP header as described previously. Given that new SHA-256 hashes are not sequential but fully random, replay attacks of future predictions are prevented.
[RFC6709]で説明されているように、ほとんどのプロトコルは、新しいバージョンのプロトコルを信号する方法を提供するなど、将来の強化を可能にするように設計する必要があります。フリップの場合、訓練されたモデルは常に新しいトレーニングによって強化されます。訓練されたモデルのSHA-256 [RFC6234]ハッシュはバージョン番号として使用されるため、各ピアがどのフリップバージョンが使用されているかを知っています。SHA-256ハッシュは、前述のようにフリップヘッダーのバージョンフィールドに入れられます。新しいSHA-256のハッシュは連続的ではなく、完全にランダムになることを考えると、将来の予測のリプレイ攻撃が防止されます。
This new protocol may revolutionize how we design Internet protocols and how we use the Internet. For example, it is envisioned that this protocol may be used for video streaming, augmented reality, virtual reality, and post-quantum cryptography to name a few. By predicting the future packets, all these protocols and applications can benefit the use of FLIP.
この新しいプロトコルは、インターネットプロトコルの設計方法とインターネットの使用方法に革命をもたらす可能性があります。たとえば、このプロトコルは、ビデオストリーミング、拡張現実、バーチャルリアリティ、およびカント後の暗号化に使用されるために使用される可能性があることが想定されています。将来のパケットを予測することにより、これらのすべてのプロトコルとアプリケーションは、フリップの使用に利益をもたらすことができます。
For FLIP, codepoints could be registered in the following IANA registries.
フリップの場合、コードポイントは次のIANAレジストリに登録できます。
* Protocol Numbers [IANA-PN]: 345, FLIP, Faster than LIght speed Protocol, RFC 9564
* プロトコル番号[IANA-PN]：345、フリップ、ライトスピードプロトコルよりも高速、RFC 9564
* Service Name and Transport Protocol Port Number Registry [IANA-SN]: FLIP, 68534, udp and tcp, RFC 9564
* サービス名と輸送プロトコルポート番号レジストリ[IANA-SN]：Flip、68534、UDPおよびTCP、RFC 9564
The ability to predict future packets based on LLMs can be used by adversaries that are listening to the traffic via wiretapping. If they have access to the same model used by the destination peer, they could use it to predict the next packets and then initiate various attacks, including novel ones such as the "futureplay attack." Compared to the typical replay attack, this attack is where the adversary will predict future packets and then send them in advance to the destination. While it may not be obvious at this time, these novel attacks should be investigated before they become a problem. Therefore, further research in this field is suggested.
LLMSに基づいて将来のパケットを予測する機能は、盗聴を介してトラフィックを聞いている敵が使用できます。宛先ピアが使用する同じモデルにアクセスできる場合、それを使用して次のパケットを予測し、「FuturePlay Attack」などの新しい攻撃を含むさまざまな攻撃を開始できます。典型的なリプレイ攻撃と比較して、この攻撃は、敵が将来のパケットを予測し、事前に目的地に送信する場所です。現時点では明らかではないかもしれませんが、これらの新しい攻撃は問題になる前に調査する必要があります。したがって、この分野でのさらなる研究が提案されています。
The ability for a peer to predict future packets enhances the overall security of the Internet because adversaries will not be able to inject bad packets in a connection, as the destination will be able to compare the received bad packet with the calculated prediction and therefore will easily identify and deny any bad packets.
ピアが将来のパケットを予測する能力は、インターネットの全体的なセキュリティを強化するため、敵は接続に悪いパケットを注入できないためです。悪いパケットを特定して拒否します。
[CHATGPT] Wikipedia, "ChatGPT", 20 March 2024,
<https://en.wikipedia.org/w/
index.php?title=ChatGPT&oldid=1214732037>.
[IANA-PN] IANA, "Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers/>.
[IANA-SN] IANA, "Service Name and Transport Protocol Port Number
Registry", <https://www.iana.org/assignments/service-
names-port-numbers/>.
[IP-DEEP-SPACE]
Blanchet, M., Huitema, C., and D. Bogdanović, "Revisiting
the Use of the IP Protocol Stack in Deep Space: Assessment
and Possible Solutions", Work in Progress, Internet-Draft,
draft-many-deepspace-ip-assessment-01, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-many-
deepspace-ip-assessment-01>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/info/rfc6709>.
Since this protocol specification is using artificial intelligence and large language models, it was deemed that dumb humans must not review this specification. Instead, the specification has been submitted to multiple LLM chat services and was enhanced by their comments and suggestions, hence acknowledged here. In fact, this specification may have been produced entirely by LLM chat services. Moreover, given the specifications being produced by the IETF relying upon human intelligence, using LLMs to produce specifications should be envisioned. Finally, given the difficulty to find experts for management positions such as in the IESG or IAB, the use of LLMs should be considered to replace those roles. Unfortunately, given privacy, security, and legal considerations, the LLM chat services used for this specification cannot be named here.
このプロトコル仕様は人工知能モデルと大規模な言語モデルを使用しているため、愚かな人間はこの仕様を確認してはならないと考えられていました。代わりに、仕様は複数のLLMチャットサービスに提出されており、コメントや提案によって強化されたため、ここで認められています。実際、この仕様はLLMチャットサービスによって完全に作成された可能性があります。さらに、人間の知能に依存しているIETFによって生成される仕様を考えると、LLMを使用して仕様を作成する必要があります。最後に、IESGやIABなどの管理職の専門家を見つけるのが難しいことを考えると、LLMの使用を検討する必要があります。残念ながら、プライバシー、セキュリティ、および法的考慮事項を考慮して、この仕様に使用されるLLMチャットサービスはここで名前を挙げることはできません。
Marc Blanchet
Viagenie
Email: marc.blanchet@viagenie.ca