アカウント名:
パスワード:
不可能でしょう. 「古いipv4の実装のコンピュータには手を入れずに,新プロトコルのコンピュータと相互に通信できること」 かつ 「新プロトコルは32ビットを超えるアドレス空間を持つこと」ってのは.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
なんでこんな仕様に・・・ (スコア:0)
膨大なデータ(ネット)が蓄積されているシステムから
新しいものへの移行は並行運用できないと移行できませんよね
Re: (スコア:1)
不可能でしょう. 「古いipv4の実装のコンピュータには手を入れずに,新プロトコルのコンピュータと相互に通信できること」 かつ 「新プロトコルは32ビットを超えるアドレス空間を持つこと」ってのは.
Re: (スコア:0)
>「新プロトコルは32ビットを超えるアドレス空間を持つこと」ってのは.
前提が厳しすぎます。
「古いipv4の実装のコンピュータには手を入れずに,新プロトコルのコンピュータと相互に通信できること」は必須事項でしょうか?
古いIPv4の実装は、IPv4のアドレスが枯渇するまで使えると割り切ればよかったのです。
たとえば、IPv4のオプションフィールドに拡張空間を定義すれば、IPv4のネットワークをそのまま使えるので、
20年もすればそれを解
Re: (スコア:1)
000.000.000.000.192.168.000.001
とか単純にIPの先頭4桁が0だったらIPv4、それ以外は新方式って単純化できなかったんでしょうかね?
これなら上位ルータとかの対応だけでも何とかなりそうですが
イーサネットヘッダ,IPヘッダ,実データ
ってのを
イーサネットヘッダ,IPv4(新方式下位4桁),(新方式上位4桁+)実データ
みたいな感じなら、既存の機器でも実データの頭にゴミ付く物のそこはIPv4に繋ぐときに上位のルータで何とかする・・・と
Re: (スコア:0)
旧機器は当然「ゴミ」のことなど知らないので、旧機器が生成するパケットに「ゴミ」は含まれません。したがって旧機器から32ビット超アドレスを持つホストへパケットを送ることができません。32ビット超アドレスを持つホストから一方的にUDPを送りつけるくらいのことしかできないのです。
構造体のフィールドを拡張するのとはわけが違うのですよ。
Re: (スコア:1)
つまり、100.100.100.100.168.000.002から、000.000.000.000.128.168.0.1なIPv4当ては
上位ルータがテーブル等でMACアドレス記憶しておいて転送する見たいな事で何とでもなりそうだと思うのですが。
指摘でIPv4のネットの中からIPv6のネットワークへ要求を送るときが困るのには気づきましたが
IPv6なネットワークからIPv4の既存の環境へ(Yahooでもどこでも良いですが)アクセスしたい場合は有効なのでは?と。
Re: (スコア:0)
答: 不可能
旧機器は宛先を区別する情報を何もパケットに含めないので。
> IPv6なネットワークからIPv4の既存の環境へ(Yahooでもどこでも良いですが)アクセス
TCPのコネクションはACKのパケットを返送できないと確立できないのですが。そんな初歩的なことでもわからないのではちょっとお話にならないです。
Re: (スコア:0)
7桁の郵便番号と同じ情報量を5桁で実現するのが不可能なのと同様に。
IPv4環境からIPv6へ相互接続する為には、グローバルIPを捨てて(無視して)接続先毎に動的にリマップするしか方法は無いと思うんですがね…。
Re:なんでこんな仕様に・・・ (スコア:0)
IPv4環境からIPv6へ相互接続する為には、
エンドユーザーから見たグローバルIPの一部をIPv6専用ゲートウェイ領域にして動的にリマップするしか…
ですね。
(この方法ではゲートウェイ領域がプライベートアドレスになる)
Re:なんでこんな仕様に・・・ (スコア:1)
Re: (スコア:0)
で終わらせてしまって、IPv4からの移行にはNATを避けて通れないという現実を無視した結果が今の惨状なわけですよね。
1990年代前半からまじめに研究を重ねておけば今から大慌てでキャリアグレードNATを開発したりしなくても済んだだろうに。