「IPv10」は冗談ですか、それとも深刻なRFCドラフトですか?


72

インターネットプロトコルバージョン10(IPv10)仕様

名前は面白い(IPv4 + IPv6 == IPv10)ですが、実際の提案は奇妙に見えます(パケット形式間の非互換性と戦うためのもう1つのパケット形式)。

長所と短所のバランスが取れた通常の提案なのか、まじめな顔で「IPv10」をからかうための最小限の実行可能な文書なのか?

深刻な場合は、「tl; dr」形式で説明してください。nat64 / teredoのような別の移行技術ではなく、なぜこれなのか?


9
最初にリンクをたどると、「4月1日」が表示されると予想していました。
Vi。


4
提案は冗談かもしれませんが、名前はそうではありません。IPv4からIPv9はすでに予約されいます(ただし、IPv4とIPv6のみが使用されます)。IPv10は、次に使用可能な未割り当てバージョンです。
user4556274

5
興味深いことに、著者は、32ビットのASNは、すでに一般的な方法であれば、ASNフィールドに16ビットを使用することを提案
ハーゲン・フォン・Eitzen

4
伝統的に4月1日に公開された、軽快なRFCの素晴らしい伝統があります。en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Commentsは開始するのに適した場所です。
ドミニククローニン

回答:


84

ロンが言ったように、誰でも提案を書くことができます。ただし、衛星と光ファイバーを相互接続することを提案する人からの提案を真剣に受け止めるのは大変です。

また、特にこのメモにより、この実際の提案が勢いを増すことは想像できません。

すべてのインターネット接続ホストは、使用されるIPバージョンに関係なく通信できるようにIPv10ホストである必要があり、IPv10展開プロセスは、ホストネットワーキングおよびセキュリティデバイス用のOSを開発しているすべてのテクノロジー企業によって実現できます。

したがって、IPv4のみのホストがIPv6のみのホストと通信できないという問題(およびその逆)を解決するには、別のプロトコルIPv10 を実装する必要があります。それから、なぜそのIPv4専用ホストにIPv6を実装するだけでなく、それを気にしてそれでやるのか。

さらに、RFC7059で読み取れるように、この問題の一部を解決するために使用できる十分なトンネルメカニズムがすでに利用可能です。

正直に言うと、私は著者がで読み取ることができるように、著作権を主張することにより、いくつかの商業的成功に期待していると思うこれらのツイート

発表:著作権の保護、#IPv10およびKHALEDルーティングプロトコル(#KRPまたは#RRP)は@The_Road_Series CEOによって開発されました。

開発者@Eng_Khaled_Omarの承認なしに、組織によって代表または公開されてはなりません。

2017年5月26日、リポジトリから#IPv10 #KRP(#RRP)ドラフトを削除するための2回目のリクエストがietfに送信されました。


15
彼らの言うことはよく知っています-抽象化の層が多すぎるという問題を除いて、抽象化の別の層ですべての問題を解決できます!
さようなら

13
ファイバーでリンクされた衛星のROFL。IPoACとほぼ同じくらい合理的に聞こえます。
reirab

14
彼は著作権で不運です。彼は、IETFのポリシーに準拠していないドキュメントのテキストに何が書かれているかに関係なく、RFCプロセスに従事することにより、IETFに著作権を既に割り当てています。
user207421

14
RFC形式で読んだものを暗黙的に信頼しないように脳を再訓練するときです。
マット

6
ツイートリンクが私の日(/週/月)
失敗した科学者

27

誰もがIETFに提案を提出できることを覚えておく必要があり、それらは採用されたり、関心の欠如により死ぬまで真剣に受け止められます。

この特定の提案は期限切れであり、著者によって数回更新されました。サポートがあるとしても、ほとんどサポートされていないようで、RFCステータス(標準化トラックなど)も提案されていません。著者はおそらく彼の提案に真剣ですが、彼は提案に対する真剣な支持を獲得していないようです。

そこに提案され日の入りはIPv4 深刻には、それはその背後にある完全なワーキンググループを持っていますが、それは、先にそれを完全に採択への長い険しい道があります。IPv4からIPv6への移行に固有の問題に対処する予定です。


19

「IPv10」は冗談ですか、それとも深刻なRFCドラフトですか?

両方。失敗は深刻であり、彼が提案しているような馬鹿げたスキームを理解していないと思います。ジョークは彼にかかっています。

ファイバー衛星提案は、それが必要な繊維長を無視し、完全に軌道力学を無視して、さらに滑稽です。

IETFは彼をトローリングでブロックする必要があります。



1

それは本当の問題を解決するための真剣な試みです。解決策が良いか悪いか(おそらくごみ)、問題のステートメントは正しいです。IPv6を実装しようとする現在の戦略は、これまでのところ失敗しました。その導入が述べているように、19年のIPv6であり、意味のある方法で移行したことを確認する方法はまだありません。

それが言及するように、我々はすでにNAT64などのいくつかのブリッジングソリューションを持っています(他にも言及しています)。これらは問題ありませんが、まだIPv6への完全な移行を許可していません-パブリックIPv4専用ホストが存在することを前提としています。

そうは言っても、IPv6への移行に伴う基本的な問題を考えると、この仕様がどのように役立つかについては懐疑的です。私はそれがどのようにしようとするのかを理解しようとしてあまり時間を費やしておらず、おそらく私より賢いかもしれません(他の答えの間のコンセンサスは私が正しいことを示唆していますが)最初の場所。

しかし、それは問題を解決するための真剣な試みです。


1
何年もの間、すべてがIPv6に対応しています。実際の採用は遅いように見えるかもしれません。その理由は、IPv4がまだ「機能する」からです。ただし、IPv6トラフィックは約20%であり、非常に急速に成長しています。2017年に、IPv6を提供しないインターネットサービスは、その位置を再考する必要があります。今、本当に必要ないのは、もう1つの移行メカニズムです。
ch7kor

すべて本当。しかし、IPv6は意味のある普及には決して至らず(最初の20%が最も簡単で、最後の20%はもっと難しいはずです)、いつか他の方法で人々が決断するでしょう。移行を容易にすることを目的とする技術についてのことは、それらが十分に長く存在する、それらが新しいインターネットになったことに気付くことです。
thomasrutter

3
実際、IPv6がインターネットトラフィックの80%を占める場合、IPv4を廃止するという提案がおそらく標準となり、ほとんどのISPはIPv4トラフィックのルーティングを停止するため、最後の20%が最も簡単であると主張できます。IPv4トラフィックを(IPv6)インターネット上でトンネリングする必要があるように、状況はIPv6の始まりとは逆になります。
ロンモーピン

0

新しいプロトコルの実装にはある程度の妥当性があります。現在の変換プロトコルはNAT64です。

NAT64は、ネットワークアドレス変換(NAT)の形式を使用してIPv6ホストとIPv4ホスト間の通信を容易にするIPv6移行メカニズムです。NAT64ゲートウェイは、IPv4とIPv6プロトコル間の翻訳であり、1は、少なくとも1つのIPv4アドレスと32ビットのアドレス空間を含むIPv6ネットワークセグメントを必要とし機能するため。IPv6クライアントは、IPv6ネットワークセグメントのホスト部分を使用して通信したいIPv4アドレスを埋め込み、結果としてIPv4埋め込みIPv6アドレス(IPv6ネットワークセグメントの32ビットアドレス空間)を生成し、パケットを結果のアドレス。NAT64ゲートウェイは、IPv6アドレスとIPv4アドレス間のマッピングを作成します。これは、手動で構成するか、自動的に決定できます。

ソース

IPv10の主なアイデアは、NAT64の廃止です。厳密に言えば、NATは常にボトルネックでした。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.