名前は面白い(IPv4 + IPv6 == IPv10)ですが、実際の提案は奇妙に見えます(パケット形式間の非互換性と戦うためのもう1つのパケット形式)。
長所と短所のバランスが取れた通常の提案なのか、まじめな顔で「IPv10」をからかうための最小限の実行可能な文書なのか?
深刻な場合は、「tl; dr」形式で説明してください。nat64 / teredoのような別の移行技術ではなく、なぜこれなのか?
名前は面白い(IPv4 + IPv6 == IPv10)ですが、実際の提案は奇妙に見えます(パケット形式間の非互換性と戦うためのもう1つのパケット形式)。
長所と短所のバランスが取れた通常の提案なのか、まじめな顔で「IPv10」をからかうための最小限の実行可能な文書なのか?
深刻な場合は、「tl; dr」形式で説明してください。nat64 / teredoのような別の移行技術ではなく、なぜこれなのか?
回答:
ロンが言ったように、誰でも提案を書くことができます。ただし、衛星と光ファイバーを相互接続することを提案する人からの提案を真剣に受け止めるのは大変です。
また、特にこのメモにより、この実際の提案が勢いを増すことは想像できません。
すべてのインターネット接続ホストは、使用される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に送信されました。
誰もがIETFに提案を提出できることを覚えておく必要があり、それらは採用されたり、関心の欠如により死ぬまで真剣に受け止められます。
この特定の提案は期限切れであり、著者によって数回更新されました。サポートがあるとしても、ほとんどサポートされていないようで、RFCステータス(標準化トラックなど)も提案されていません。著者はおそらく彼の提案に真剣ですが、彼は提案に対する真剣な支持を獲得していないようです。
そこに提案され日の入りはIPv4 で深刻には、それはその背後にある完全なワーキンググループを持っていますが、それは、先にそれを完全に採択への長い険しい道があります。IPv4からIPv6への移行に固有の問題に対処する予定です。
「IPv10」は冗談ですか、それとも深刻なRFCドラフトですか?
両方。失敗は深刻であり、彼が提案しているような馬鹿げたスキームを理解していないと思います。ジョークは彼にかかっています。
ファイバー衛星提案は、それが必要な繊維長を無視し、完全に軌道力学を無視して、さらに滑稽です。
IETFは彼をトローリングでブロックする必要があります。
それは本当の問題を解決するための真剣な試みです。解決策が良いか悪いか(おそらくごみ)、問題のステートメントは正しいです。IPv6を実装しようとする現在の戦略は、これまでのところ失敗しました。その導入が述べているように、19年のIPv6であり、意味のある方法で移行したことを確認する方法はまだありません。
それが言及するように、我々はすでにNAT64などのいくつかのブリッジングソリューションを持っています(他にも言及しています)。これらは問題ありませんが、まだIPv6への完全な移行を許可していません-パブリックIPv4専用ホストが存在することを前提としています。
そうは言っても、IPv6への移行に伴う基本的な問題を考えると、この仕様がどのように役立つかについては懐疑的です。私はそれがどのようにしようとするのかを理解しようとしてあまり時間を費やしておらず、おそらく私より賢いかもしれません(他の答えの間のコンセンサスは私が正しいことを示唆していますが)最初の場所。
しかし、それは問題を解決するための真剣な試みです。
新しいプロトコルの実装にはある程度の妥当性があります。現在の変換プロトコルは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は常にボトルネックでした。