アカウント名:
パスワード:
自宅に IPv6 を導入して使ってみた経験がありますが(今は嫌気がして完全に無効にしていますが)、IPアドレスが長すぎるので、不便極まりないです。
256^4 だったIPv4 アドレスが足りなくなって困りだしたとき、 256^5 にすればよかったのに、256^16 なんかにしたのが間違いだったと思います。
IPv4: 4,294,967,296 個 (例) 10.51.45.123このぐらいで十分足りたはず:
IPv6の場合、ルータとかグローバル公開しているサーバとかを除けば、基本的にはDHCPv6等での配布や自動設定だから、クライアントレベルではアドレス設定することはまずない。LAN内のローカル通信ならIPv4のプライベートアドレスで十分だし、インフラSEでもなければ、わざわざIPv6アドレスを入力して使うなんて、かなり稀だ。せいぜい、疎通確認でpingするときに使うぐらいじゃないの?
基本的にはDHCPv6等での配布や自動設定だから、クライアントレベルではアドレス設定することはまずない。
確かに、IPv6ではMACアドレスなどをもとに自動設定されるのが基本ではありますが、IPv4 でもルータなどがDHCPでIPアドレスを自動割り当てするのが一般的だったので、IPv4 と大差ありません。
IPv4 環境でしょっちゅうIPアドレスを打ち込む使い方をしている人ならば、なんだかんだいっても結局 IPv6 になっても頻繁に打ち込むはめになると思います。勿論、LAN内にDNSサーバを立てればその回数は減らせるでしょうが、構築・メンテナンス・トラブル時には結局打ち込むはめになるでしょう。
LAN内のローカル通信ならIPv4のプライベートアドレスで十分だし、インフラSEでもなければ、わざわざIPv6アドレスを入力して使うなんて、かなり稀だ。
「IPv4のプライベートアドレス」を使うのでしたら IPv6 に移行したとはいえないのでは? IPv6 の「リンクローカルアドレス」と IPv4 のプライベートIPアドレスの両方を割り当てることになって管理が大変になると思います。IPv6 には「リンクローカルアドレス」というものがあるのに、それを使わないのはIPv6アドレスが長すぎる故に入力が面倒だし覚えられないからですよね。
LAN内のローカル通信だと、IPv4 であれば例えばルータの設定画面に行きたかったら、ブラウザ起動して「10.0.0.1」と入れるだけだったり、プリンタの設定を変えたかったら「10.0.0.4」と入れるだけ、3階のPCにWindowsネットワークでつなぎたかったらエクスプローラに「\\10.0.3.2」と入れるだけ、と簡単に記憶できる数値とドットを入れるだけですぐ自由自在に好きなところにつなげるのがメリットだと思います。
(IPv4の場合の例) (IPv6の場合の例)10.0.0.1 … ルータ fe80::223:4567:89ab:cdef%5 のようなMACアドレスをもとに自動生成されたリンクローカルアドレス10.0.0.2 … NAS 110.0.0.3 … NAS 210.0.0.4 … プリンタ10.0.1.1 … 1階PC110.0.1.2 … 1階PC210.0.2.1 … 2階PC10.0.3.1 … 3階PC110.0.3.2 … 3階PC2
一方、IPv6 だとリンクローカルアドレスが長くて覚えにくいしうち込みにくい。自分のパソコンのブラウザのブックマークに「プリンタの設定用のIPアドレス」を入れてしても、例えば家族のPCから入りたかったらわざわざ自分のパソコンを立ち上げてメールで長ったらしい「IPv6リンクローカルアドレス」を送るといった面倒な作業をすることになります。
せいぜい、疎通確認でpingするときに使うぐらいじゃないの?
トラブル解決のためにIPアドレスを含むコマンドを打ち込む回数は、IPv6 になって固定IPv6アドレス、一時IPv6アドレス、リンクローカルIPv6アドレス(IPv4を併用しているならそのアドレスも)と1つの端末に割り当てられたIPアドレスの数が増えたことによって増加することになります。
プライベートアドレスの代わりはリンクローカルアドレスじゃなくて ULA。
インターネット10分講座:IPv6アドレス~技術解説~ [nic.ad.jp](「3.4 ユニークローカルIPv6ユニキャストアドレス(ULA)」参照)
リンクローカルアドレスは同一セグメント限定で、近隣探索(IPv4 での ARP に相当)とか DHCPv6 とかで使うものなので、これを意識する必要はない(DHCPv6 とかのトラブルを調べるのにパケットをキャプチャして、その時のリンクローカルアドレス...、でも、その手のトラブルの時は MAC アドレスをキーにして調べるから、やっぱりリンクローカルアドレスは見ないなぁ)。
なんで、
トラブル解決のためにIPアドレスを含むコマンドを打ち込む回数は、IPv6 になって固定IPv6アドレス、一時IPv6アドレス、リンクローカルIPv6アドレス
少なくとも、ping で疎通確認するのに相手のリンクローカルアドレスを使うことは無いなぁ。一時アドレスが振られているなら、その時点で、リンクアップして RA なり DHCPv6 なりのパケットを取れていることになるし。
自分が一番はまったのは、内部では一時アドレスは使わないけど、インターネットに抜けていくときにはグローバルな一時アドレスにしたい、と思うと、少なくとも Windows 7 までのポリシーテーブルだと、内部の通信でもグローバルな一時アドレスが優先されること。この辺の顛末は、下記のページに。
おうちに IPv6 がやってきた - その5 [hatena.ne.jp]
IPv4 環境でしょっちゅうIPアドレスを打ち込む使い方をしている人ならば、なんだかんだいっても結局 IPv6 になっても頻繁に打ち込むはめになると思います。
なら、v6 も手動で振れば?
IPv4 10.0.0.1, IPv6 fe80::1IPv4 10.0.0.2, IPv6 fe80::2IPv4 10.0.0.3, IPv6 fe80::3
これぐらいならそれほど面倒ではありませんよ。リンクローカルアドレスが手動設定できない困った OS を使っているとしても、それはその OS の問題であって、IPv6 の問題ではありませんね。
そもそも不足しているのはグローバル IP アドレスであって、グローバル IPv4 の代わりに IPv6 への移行が言われているわけで、プライベートな 10.0.0.1 を IPv6 アドレスに置き換えるという話をするのが筋違いです。
グローバルアドレスをIPv4からIPv6に移行したとして、内部を移行しないとすれば、どこかでIPv4/v6トランスレートが必要になる。あれもまた簡単な話じゃないんだが。(なによりデファクトスタンダードといえるものがない。どれも一長一短で。)
IPv6を使う場合でもDNS登録しておけばいいのだし、イントラネット内はIPv4で、外部へはPROXYサーバ経由のみにして、PROXYサーバがIPv6サイトにもアクセス可能になっていれば、当分間に合うよな。無理にイントラネット内をIPv6対応する必要性を感じない。社内からの基本Web以外のアクセスを全部禁止するポリシーだしね。不要アクセスの制限もその方が楽だしね。
httpsの通信はどうするの。proxyを通してIPv4/v6変換をするってことは、proxyサーバで一度復号するの?クライアントが確認できるのは、Proxyサーバの証明書だけ?
すくなくともSquid3をフォワードプロキシとして使うならその辺うまいこと暗号は保持したままIPv4/IPv6トランスレートしてしてくれる心配しなくてよろしい。クライアント←→Squid間IPv4, Squid←→目的サーバ間はIPv6で通信できる。証明書云々は気にしなくてよい。
https(SSL)はセッション層(第5層)レベルでの暗号化です。
トランスポート層(第4層、TCPやUDP)レベル以上のデータは(暗号化されたものでも)そのまま素通しする形で、ネットワーク層(第3層)をIPv4からIPv6に変換すれば、アプリケーション層レベルの通信での暗号を「復号・再暗号化」する必要はありません。
#「データリンク層(第2層、WiFiやイーサネットなど)レベルでの変換とかをしても、ネットワーク層以上の通信には影響しない」のと同じことが、ネットワーク層でも言えるわけです。
ただし、HTTPSは問題ありませんが、上述の変換が実現可能となる前提としては「アプリケーション層レベルプロトコルでの通信内容にIPアドレスの情報が含まれない」ようなプロトコルである必要があります。
例えばFTPは、そのアプリケーション層プロトコルレベルで「データコネクションについての情報交換」というIPアドレスについての情報交換がありますので、暗号化したままIP変換することはできません。これは、V4-V6変換にかぎった話ではなく、いわゆる普通の「NAT」でも問題になります。
そのため、ただのNATでも、httpなんかはデータを素通しさせるだけですが、ftpだけはNATルーターなどの内部でアプリケーション層レベルでのパケット内容の改変が行われています。
そういうものですから、そのままの素のFTPの場合、over SSL でNATを超えることはできません。その対策としては、FTPのプロトコルが拡張されて、IPアドレスを使わない情報交換コマンドEPRT/EPSVが定義されています。 [biglobe.ne.jp]FTPSでNATやv4-v6変換を通したい場合は、EPSV対応のサーバとクライアントを使う必要がある、ということになります。
一般的なプロトコルでこういう問題があるのはFTPぐらいですが、その他、独自のプロトコルを使ってるものでは、そのプロトコルによってはv4-v6ゲートウェイを通して通信ができない可能性はあります。でも、まあとりあえず、HTTPSについてはv4-v6変換しても問題ない、ということで。
そうだよ。だからとても危険なの。誰がどう運用しているのかわからないようなPublic PROXYサーバなんか、セキュリティを気にしているなら使うなってことでもある。やろうと思えば、PROXYで覗き見し放題だしね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
IPv6 のアドレスは長すぎた (スコア:4, 興味深い)
自宅に IPv6 を導入して使ってみた経験がありますが(今は嫌気がして完全に無効にしていますが)、IPアドレスが長すぎるので、不便極まりないです。
256^4 だったIPv4 アドレスが足りなくなって困りだしたとき、 256^5 にすればよかったのに、256^16 なんかにしたのが間違いだったと思います。
Re:IPv6 のアドレスは長すぎた (スコア:2, すばらしい洞察)
IPv6の場合、ルータとかグローバル公開しているサーバとかを除けば、基本的にはDHCPv6等での配布や自動設定だから、クライアントレベルではアドレス設定することはまずない。LAN内のローカル通信ならIPv4のプライベートアドレスで十分だし、インフラSEでもなければ、わざわざIPv6アドレスを入力して使うなんて、かなり稀だ。せいぜい、疎通確認でpingするときに使うぐらいじゃないの?
Re:IPv6 のアドレスは長すぎた (スコア:2, オフトピック)
確かに、IPv6ではMACアドレスなどをもとに自動設定されるのが基本ではありますが、IPv4 でもルータなどがDHCPでIPアドレスを自動割り当てするのが一般的だったので、IPv4 と大差ありません。
IPv4 環境でしょっちゅうIPアドレスを打ち込む使い方をしている人ならば、なんだかんだいっても結局 IPv6 になっても頻繁に打ち込むはめになると思います。勿論、LAN内にDNSサーバを立てればその回数は減らせるでしょうが、構築・メンテナンス・トラブル時には結局打ち込むはめになるでしょう。
「IPv4のプライベートアドレス」を使うのでしたら IPv6 に移行したとはいえないのでは? IPv6 の「リンクローカルアドレス」と IPv4 のプライベートIPアドレスの両方を割り当てることになって管理が大変になると思います。IPv6 には「リンクローカルアドレス」というものがあるのに、それを使わないのはIPv6アドレスが長すぎる故に入力が面倒だし覚えられないからですよね。
LAN内のローカル通信だと、IPv4 であれば例えばルータの設定画面に行きたかったら、ブラウザ起動して「10.0.0.1」と入れるだけだったり、プリンタの設定を変えたかったら「10.0.0.4」と入れるだけ、3階のPCにWindowsネットワークでつなぎたかったらエクスプローラに「\\10.0.3.2」と入れるだけ、と簡単に記憶できる数値とドットを入れるだけですぐ自由自在に好きなところにつなげるのがメリットだと思います。
一方、IPv6 だとリンクローカルアドレスが長くて覚えにくいしうち込みにくい。自分のパソコンのブラウザのブックマークに「プリンタの設定用のIPアドレス」を入れてしても、例えば家族のPCから入りたかったらわざわざ自分のパソコンを立ち上げてメールで長ったらしい「IPv6リンクローカルアドレス」を送るといった面倒な作業をすることになります。
トラブル解決のためにIPアドレスを含むコマンドを打ち込む回数は、IPv6 になって固定IPv6アドレス、一時IPv6アドレス、リンクローカルIPv6アドレス(IPv4を併用しているならそのアドレスも)と1つの端末に割り当てられたIPアドレスの数が増えたことによって増加することになります。
Re:IPv6 のアドレスは長すぎた (スコア:5, 参考になる)
プライベートアドレスの代わりはリンクローカルアドレスじゃなくて ULA。
インターネット10分講座:IPv6アドレス~技術解説~ [nic.ad.jp](「3.4 ユニークローカルIPv6ユニキャストアドレス(ULA)」参照)
リンクローカルアドレスは同一セグメント限定で、近隣探索(IPv4 での ARP に相当)とか DHCPv6 とかで使うものなので、これを意識する必要はない(DHCPv6 とかのトラブルを調べるのにパケットをキャプチャして、その時のリンクローカルアドレス...、でも、その手のトラブルの時は MAC アドレスをキーにして調べるから、やっぱりリンクローカルアドレスは見ないなぁ)。
なんで、
少なくとも、ping で疎通確認するのに相手のリンクローカルアドレスを使うことは無いなぁ。一時アドレスが振られているなら、その時点で、リンクアップして RA なり DHCPv6 なりのパケットを取れていることになるし。
自分が一番はまったのは、内部では一時アドレスは使わないけど、インターネットに抜けていくときにはグローバルな一時アドレスにしたい、と思うと、少なくとも Windows 7 までのポリシーテーブルだと、内部の通信でもグローバルな一時アドレスが優先されること。この辺の顛末は、下記のページに。
おうちに IPv6 がやってきた - その5 [hatena.ne.jp]
Re:IPv6 のアドレスは長すぎた (スコア:3)
なら、v6 も手動で振れば?
IPv4 10.0.0.1, IPv6 fe80::1
IPv4 10.0.0.2, IPv6 fe80::2
IPv4 10.0.0.3, IPv6 fe80::3
これぐらいならそれほど面倒ではありませんよ。リンクローカルアドレスが手動設定できない困った OS を使っているとしても、それはその OS の問題であって、IPv6 の問題ではありませんね。
そもそも不足しているのはグローバル IP アドレスであって、グローバル IPv4 の代わりに IPv6 への移行が言われているわけで、プライベートな 10.0.0.1 を IPv6 アドレスに置き換えるという話をするのが筋違いです。
Re: (スコア:0)
グローバルアドレスをIPv4からIPv6に移行したとして、内部を移行しないとすれば、
どこかでIPv4/v6トランスレートが必要になる。あれもまた簡単な話じゃないんだが。
(なによりデファクトスタンダードといえるものがない。どれも一長一短で。)
Re:IPv6 のアドレスは長すぎた (スコア:2)
PC などの各ホストはプライベート IPv4, グローバル IPv6 のアドレスを両方振ることができるのですから、IPv4/v6 トランスレートは必要ありません。
Re: (スコア:0)
IPv6を使う場合でもDNS登録しておけばいいのだし、イントラネット内はIPv4で、外部へはPROXYサーバ経由のみにして、PROXYサーバがIPv6サイトにもアクセス可能になっていれば、当分間に合うよな。無理にイントラネット内をIPv6対応する必要性を感じない。社内からの基本Web以外のアクセスを全部禁止するポリシーだしね。不要アクセスの制限もその方が楽だしね。
Re: (スコア:0)
httpsの通信はどうするの。proxyを通してIPv4/v6変換をするってことは、
proxyサーバで一度復号するの?クライアントが確認できるのは、Proxyサーバの証明書だけ?
Re:IPv6 のアドレスは長すぎた (スコア:1)
すくなくともSquid3をフォワードプロキシとして使うなら
その辺うまいこと暗号は保持したままIPv4/IPv6トランスレートしてしてくれる心配しなくてよろしい。
クライアント←→Squid間IPv4, Squid←→目的サーバ間はIPv6で通信できる。
証明書云々は気にしなくてよい。
Re:IPv6 のアドレスは長すぎた (スコア:1)
https(SSL)はセッション層(第5層)レベルでの暗号化です。
トランスポート層(第4層、TCPやUDP)レベル以上のデータは(暗号化されたものでも)そのまま素通しする形で、
ネットワーク層(第3層)をIPv4からIPv6に変換すれば、
アプリケーション層レベルの通信での暗号を「復号・再暗号化」する必要はありません。
#「データリンク層(第2層、WiFiやイーサネットなど)レベルでの変換とかをしても、ネットワーク層以上の通信には影響しない」のと同じことが、ネットワーク層でも言えるわけです。
ただし、HTTPSは問題ありませんが、
上述の変換が実現可能となる前提としては「アプリケーション層レベルプロトコルでの通信内容にIPアドレスの情報が含まれない」ようなプロトコルである必要があります。
例えばFTPは、そのアプリケーション層プロトコルレベルで「データコネクションについての情報交換」というIPアドレスについての情報交換がありますので、暗号化したままIP変換することはできません。これは、V4-V6変換にかぎった話ではなく、いわゆる普通の「NAT」でも問題になります。
そのため、ただのNATでも、httpなんかはデータを素通しさせるだけですが、ftpだけはNATルーターなどの内部でアプリケーション層レベルでのパケット内容の改変が行われています。
そういうものですから、そのままの素のFTPの場合、over SSL でNATを超えることはできません。
その対策としては、FTPのプロトコルが拡張されて、IPアドレスを使わない情報交換コマンドEPRT/EPSVが定義されています。 [biglobe.ne.jp]
FTPSでNATやv4-v6変換を通したい場合は、EPSV対応のサーバとクライアントを使う必要がある、ということになります。
一般的なプロトコルでこういう問題があるのはFTPぐらいですが、
その他、独自のプロトコルを使ってるものでは、そのプロトコルによってはv4-v6ゲートウェイを通して通信ができない可能性はあります。
でも、まあとりあえず、HTTPSについてはv4-v6変換しても問題ない、ということで。
Re: (スコア:0)
そうだよ。だからとても危険なの。誰がどう運用しているのかわからないようなPublic PROXYサーバなんか、セキュリティを気にしているなら使うなってことでもある。やろうと思えば、PROXYで覗き見し放題だしね。