アカウント名:
パスワード:
IPv6の話題には本当に辟易します。技術者は物事を定量的に扱える人種だと思うのですが、ことIPアドレスの話になると感情的になり、ついには平気に嘘をつき始めるのがなぜか全然わかりません。
「IPv6移行しなくちゃだわ教」元信者のかたがいらっしゃったら、信じていた頃の気持ち(マインドコントロール?)を教えてください。
また最近入信したひとがいらっしゃったら、その理由を教えてください。
IPv4ホストからIPv6ホストのwebコンテンツを見ることはできますか?IPv6ホストからIPv4ホストのwebコンテンツを見ることはできますか?IPv4ホストからIPv6ホストのドメインのメールアドレスへメールを送ることはできますか?IPv6ホストからIPv4ホストのドメインのメールアドレスへメールを送ることはできますか?IPv4ホストからIPv6ホストのドメインのPOP/IMAPサーバのメールを受信することはできますか?IPv6ホストからIPv4ホストのドメインのPOP/IMAPサーバのメールを受信することはできますか?
これらができなくて、既存のIPv4ネットワーク上の資産を捨てて移行することなど、無理だと思います。これらができるのであれば、積極的にシームレスな移行を推進すべきだと思います。
端末とサーバの間に 6to4 gateway がいれば IPv4 to IPv6 は普通にできますね。 IPv6 ノードから IPv4 ノードへのアクセスは直接行う手段はありませんが、通常は proxy として働くサーバなどを通すことで IPv6 から IPv4 に落とすことで間接的にアクセス可能ですね。 Web では困る場面もありますが (HTTPS 等)、SMTP などではこれで困る状況はほとんどない (ISP 側が IPv4/IPv6 デュアルスタックで契約ユーザは IPv6、送り先が IPv4 のみを想定) と思います。
これらとは別に、比較的素直な解として 4to6 gateway という手段もあります。 6to4 とは逆に IPv4/IPv6 のデュアルスタックルーターが IPv6 -> IPv4 変換を行って通信する形ですね。 この場合、特に間を考慮する必要はないかと思います。 ただし、この場合でも DNS 的な面でごにょごにょする必要があるでしょう。
基本的に問題が出るのは外へ直接出る場合における IPv6 → IPv4 であって、この点はサービス側が IPv4/IPv6 デュアルスタック構成を当面継続する事が必須となる最大の理由でしょう。
なお、サーバーソフト自体は結構 IPv4/IPv6 両対応のものも少なくありません。 HTTP/SMTP/POP3/IMAP4 辺りなどは「しっかりメンテナンスされているもので」非対応のものを探す方が難しいです。 しかし、その先 (例えば CGI 等の該当サーバーから先で動くアプリ) に関しては問題を抱えたままのものが少なくないでしょう。
6to4 gatewayと4to6 gatewayは、誰が設置するんでしょうか?ISPですか?違いますよね?サービス側ですよね?
> サービス側が IPv4/IPv6 デュアルスタック構成を当面継続する事が必須となる
「移行」という、過渡的な状況でしか使われないもののためにサービス側が負担を強いられることこそ、IPv6が普及しない原因の一つではないでしょうか。
v6とv4との透過的接続の仕組みをISPが用意すれば、エンドユーザは勿論、サービス側も負担せずに済みます。透過的接続の仕組みにかかるコストは、ISPが料金として徴収すればよいでしょう。夫々のネットワーク資源同士の接続が保障された時点で、v6の方にコストメリットがあるように誘導すれば、コスト意識のあるユーザ/サービスはv6ネットワークに移行するでしょうし、そうでない者はレガシーなv4ネットワークに留まり続けるでしょう。「共存」を前提に考えれば、素直に解決すると思います。
なんでこういう風に考えな(い|かった)んでしょうか。
6to4 gatewayと4to6 gatewayは、誰が設置するんでしょうか? ISPですか?違いますよね?サービス側ですよね?
エンドユーザ宅にあるルータや ISP レベルでしょう。できれば ISP 側でしょうね。 基本的に「サービス側はしばらくデュアルスタック」の形とした方が IPv4 アドレスの消費が少なくて済みますので。
デュアルスタック構成は別に過度の負担を強いられるものではありませんよ。 IPv4 用のサービスと IPv6 用のサービスを別途起動するようなものではなく、一つのインスタンスで両方のスタックに対して listen する程度です。
極めて単純な例では Apache httpd で Listen 0.0.0.0:80 の次の行に Listen [::]:80 を追記する程度でしょうか。Virtual Host を利用している場合はその分の記述も必要になりますが。 ここ数年のものであれば、大抵は何も考えなくても「使えるなら listen する」形の設定がデフォルトになっているかと思います。
単に知らない、試験が足りていない、運用する体制がない、まともに利用できる機材がない、または高価といった理由が大きいのではないでしょうか。 *BSD などではかなり昔から faith インタフェースを利用する事で、外界へ繋がっているルータのみが IPv4 アドレスを持ち LAN は IPv6 のみ、という構成でも外部の IPv4 ネットワークへ接続する形を取ることは可能です。
ただ、このような形を取るにも、そこらの LAN と ISP レベルでは収容するユーザー数の差がありすぎます。 この点で単純に「なんでこういった機能を使ってやらないんだ」とは言えない話ですね。
6to4があればなんでも解決!という理解は間違っています。
なんでも解決するなんて全く思っていませんよ? 結局 end to end の接続が保障される訳ではありませんし、様々なサービスが利用できないでしょう。
例えば IRC の DCC なんてまず機能しませんね。 もっとも、現状でも IPv4/IPv6 相互接続が行われている IRC ネットワークでも IPv4 な人と IPv6 な人では DCC での通信はできませんが。
しっかりメンテナンスされているもので
やはりqmailは捨てたほうがいい [ya.maya.st]ということだな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
技術者が終末思想に囚われる理由 (スコア:-1, フレームのもと)
IPv6の話題には本当に辟易します。技術者は物事を定量的に扱える人種だと思うのですが、
ことIPアドレスの話になると感情的になり、ついには平気に嘘をつき始めるのがなぜか全然わかりません。
「IPv6移行しなくちゃだわ教」元信者のかたがいらっしゃったら、
信じていた頃の気持ち(マインドコントロール?)を教えてください。
また最近入信したひとがいらっしゃったら、その理由を教えてください。
Re: (スコア:3, すばらしい洞察)
感情的な議論を避けたいのであれば、まず「嘘」と「間違い」と「単なる意見の相違」の区別はきちんとつけるべきです。
IPv6への移行が「必要」という人(仮にAさんとします)と「必要でない」という人(仮にBさんとします)がいるわけですが、
Aさんの持っている根拠とBさんの持っている根拠が相反していた場合に、両者の信頼性が拮抗していて甲乙付けがたいのであれば、それはまだ「単なる意見の相違」でしょう。
Re: (スコア:0)
IPv4ホストからIPv6ホストのwebコンテンツを見ることはできますか?
IPv6ホストからIPv4ホストのwebコンテンツを見ることはできますか?
IPv4ホストからIPv6ホストのドメインのメールアドレスへメールを送ることはできますか?
IPv6ホストからIPv4ホストのドメインのメールアドレスへメールを送ることはできますか?
IPv4ホストからIPv6ホストのドメインのPOP/IMAPサーバのメールを受信することはできますか?
IPv6ホストからIPv4ホストのドメインのPOP/IMAPサーバのメールを受信することはできますか?
これらができなくて、既存のIPv4ネットワーク上の資産を捨てて移行することなど、無理だと思います。
これらができるのであれば、積極的にシームレスな移行を推進すべきだと思います。
Re:技術者が終末思想に囚われる理由 (スコア:2, 参考になる)
端末とサーバの間に 6to4 gateway がいれば IPv4 to IPv6 は普通にできますね。
IPv6 ノードから IPv4 ノードへのアクセスは直接行う手段はありませんが、通常は proxy として働くサーバなどを通すことで IPv6 から IPv4 に落とすことで間接的にアクセス可能ですね。
Web では困る場面もありますが (HTTPS 等)、SMTP などではこれで困る状況はほとんどない (ISP 側が IPv4/IPv6 デュアルスタックで契約ユーザは IPv6、送り先が IPv4 のみを想定) と思います。
これらとは別に、比較的素直な解として 4to6 gateway という手段もあります。
6to4 とは逆に IPv4/IPv6 のデュアルスタックルーターが IPv6 -> IPv4 変換を行って通信する形ですね。
この場合、特に間を考慮する必要はないかと思います。
ただし、この場合でも DNS 的な面でごにょごにょする必要があるでしょう。
基本的に問題が出るのは外へ直接出る場合における IPv6 → IPv4 であって、この点はサービス側が IPv4/IPv6 デュアルスタック構成を当面継続する事が必須となる最大の理由でしょう。
なお、サーバーソフト自体は結構 IPv4/IPv6 両対応のものも少なくありません。
HTTP/SMTP/POP3/IMAP4 辺りなどは「しっかりメンテナンスされているもので」非対応のものを探す方が難しいです。
しかし、その先 (例えば CGI 等の該当サーバーから先で動くアプリ) に関しては問題を抱えたままのものが少なくないでしょう。
Re: (スコア:0)
6to4 gatewayと4to6 gatewayは、誰が設置するんでしょうか?
ISPですか?違いますよね?サービス側ですよね?
> サービス側が IPv4/IPv6 デュアルスタック構成を当面継続する事が必須となる
「移行」という、過渡的な状況でしか使われないもののためにサービス側が負担を強いられることこそ、IPv6が普及しない原因の一つではないでしょうか。
v6とv4との透過的接続の仕組みをISPが用意すれば、エンドユーザは勿論、サービス側も負担せずに済みます。
透過的接続の仕組みにかかるコストは、ISPが料金として徴収すればよいでしょう。
夫々のネットワーク資源同士の接続が保障された時点で、v6の方にコストメリットがあるように誘導すれば、コスト意識のあるユーザ/サービスはv6ネットワークに移行するでしょうし、そうでない者はレガシーなv4ネットワークに留まり続けるでしょう。
「共存」を前提に考えれば、素直に解決すると思います。
なんでこういう風に考えな(い|かった)んでしょうか。
Re:技術者が終末思想に囚われる理由 (スコア:1)
エンドユーザ宅にあるルータや ISP レベルでしょう。できれば ISP 側でしょうね。
基本的に「サービス側はしばらくデュアルスタック」の形とした方が IPv4 アドレスの消費が少なくて済みますので。
デュアルスタック構成は別に過度の負担を強いられるものではありませんよ。
IPv4 用のサービスと IPv6 用のサービスを別途起動するようなものではなく、一つのインスタンスで両方のスタックに対して listen する程度です。
極めて単純な例では Apache httpd で Listen 0.0.0.0:80 の次の行に Listen [::]:80 を追記する程度でしょうか。Virtual Host を利用している場合はその分の記述も必要になりますが。
ここ数年のものであれば、大抵は何も考えなくても「使えるなら listen する」形の設定がデフォルトになっているかと思います。
単に知らない、試験が足りていない、運用する体制がない、まともに利用できる機材がない、または高価といった理由が大きいのではないでしょうか。
*BSD などではかなり昔から faith インタフェースを利用する事で、外界へ繋がっているルータのみが IPv4 アドレスを持ち LAN は IPv6 のみ、という構成でも外部の IPv4 ネットワークへ接続する形を取ることは可能です。
ただ、このような形を取るにも、そこらの LAN と ISP レベルでは収容するユーザー数の差がありすぎます。
この点で単純に「なんでこういった機能を使ってやらないんだ」とは言えない話ですね。
Re: (スコア:0)
6to4があればなんでも解決!という理解は間違っています。
Re:技術者が終末思想に囚われる理由 (スコア:1)
なんでも解決するなんて全く思っていませんよ?
結局 end to end の接続が保障される訳ではありませんし、様々なサービスが利用できないでしょう。
例えば IRC の DCC なんてまず機能しませんね。
もっとも、現状でも IPv4/IPv6 相互接続が行われている IRC ネットワークでも IPv4 な人と IPv6 な人では DCC での通信はできませんが。
Re: (スコア:0)
やはりqmailは捨てたほうがいい [ya.maya.st]ということだな。