回答:
残念ながら、これは使用しているオペレーティングシステムによって異なります。
Microsoft Windowsでは、ソケットを::
バインドするとIPv6ポートにのみバインドされます。したがって、IPv4とIPv6の両方ですべてのアドレスをリッスンするには0.0.0.0
、だけでなくにもバインドする必要があります::
。次の抜粋はVistaボックスからのものです。
C:\>netstat -an | find "445"
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP [::]:445 [::]:0 LISTENING
私が挙げる例はポート445で、NetBIOSが使用されていないときにSMBトラフィックに使用されます。ご覧のとおり、両方にバインドされて0.0.0.0
おり::
、それぞれIPv4クライアントとIPv6クライアントの両方を機能させています。
Linuxでは、::
正確に推測したとおり、にIPv4互換アドレスが含まれているため、へのバインド0.0.0.0
も不要です。AF_INET6
上のソケットにのみバインドする単純なPythonプログラムを作成しました::
。AF_INET
(IPv4)ソケットにもバインドしていませんが、IPv4クライアントからの接続を受け入れます。たとえば、10.1.1.3
それに接続すると、からの接続として表示されます::ffff:10.1.1.3
。
それが毛むくじゃらになることを除いて。/proc/sys/net/ipv6/bindv6only
がに設定さ1
れている場合、上記はLinuxには適用されません。この場合、動作はWindowsとまったく同じ::
です。バインド先はIPv6リクエストのみをリッスンします。IPv4リクエストもリッスンする場合は、AF_INET
ソケットを作成してリッスンする必要0.0.0.0
もあります。幸い、のデフォルトbindv6only
は0
なので、これに対処しなければならない可能性は非常に低くなります(実際にはデフォルトでに設定されているDebianを使用する場合を除いてbindv6only = 1
)。
これらすべては、サービスがIPv6対応であるかどうか、およびサービスがIPv4対応であるかどうかを確認するのに役立ちます。これが私のSSHサーバーです:
$ netstat -64ln | grep 22
tcp6 0 0 :::22 :::* LISTEN
ご覧のように、SSHは::
ポート22でのみリッスンしています。ただし、SSHはIPv6クライアントをリッスンするだけではなく、IPv4互換バインディングのため、IPv4クライアントから正常に機能します。これを証明するには、これを見ると:
$ cat /proc/sys/net/ipv6/bindv6only
0
bindv6only
無効になっています(デフォルト)。それがに設定されている場合は、1
SSHが0.0.0.0
同様に(または代わりに)待機するように奨励する必要があります。
Mac OS X側の情報がないことをお詫びします。私は過去にそれを使用しましたが、私はGNOMEの美学を好むので、あまり長い間使用していません。ただし、動作はLinuxと同じだと思います。
お役に立てれば。
これは不可能です。IPv6アドレス空間のセグメントはIPv4空間と同じであるため、IPv4ソケットを無効にできたとしても、IPv4パケットをIPv6ソケットに送信することは可能です。IPv4ウィキペディアページのIPv4移行セクションをご覧ください。
編集:ああ、少し下にそれは言う:
一部の一般的なIPv6スタックは、IPv4とIPv4スタックが別々の実装(Vista / Longhornより前のMicrosoft Windows:XP / 2003など)であるため、またはセキュリティ上の懸念(OpenBSD)のため、IPv4マップアドレス機能をサポートしていません。これらのオペレーティングシステムでは、サポートするIPプロトコルごとに個別のソケットを開く必要があります。一部のシステム(Linux、NetBSD、FreeBSDなど)では、この機能はRFC 3493で指定されているソケットオプションIPV6_V6ONLYによって制御されます。