アカウント名:
パスワード:
自宅に 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するときに使うぐらいじゃないの?
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: (スコア:2, すばらしい洞察)
IPv6の場合、ルータとかグローバル公開しているサーバとかを除けば、基本的にはDHCPv6等での配布や自動設定だから、クライアントレベルではアドレス設定することはまずない。LAN内のローカル通信ならIPv4のプライベートアドレスで十分だし、インフラSEでもなければ、わざわざIPv6アドレスを入力して使うなんて、かなり稀だ。せいぜい、疎通確認でpingするときに使うぐらいじゃないの?
Re:IPv6 のアドレスは長すぎた (スコア: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で覗き見し放題だしね。