アカウント名:
パスワード:
バグだろう。既製品市販デバイスでそんなとこにバグが入り込むとは考えにくいからハードウェアオフロードでの自社開発アクセラレータロジックにバグが有ったとか?TCPしか十分テストしてなかったのかね# チェックサムって言ってるけどCRCでしょ。
IPv4でのUDPチェックサムは必須ではない(使用しない場合は0をセット)はずなのに、どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ
> IPv4でのUDPチェックサムは必須ではない(使用しない場合は0をセット)はずなのに、> どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ
近いけど、・65536分の1の割合でUDPチェックサムの計算結果が0x0000になったときに0xffffに上書きしないNAPTのバグ・チェックサムが0x0000のパケットを廃棄してしまうRakutenLinkのバグの相乗効果と予想。割合は65536分の1でも、0x0000になるパケットは何度再送しても0x0000だから永久に受信できない。
逆、つまり、・RakutenLinkがチェックサム0x0000を0xffffにしない・NAPTがチェックサム0x0000を廃棄するの組み合わせだと、チェックサム0x0000で送ってくる端末、OSなんてたくさんあるから、RakutenLinkで問題になる前に気づいているはず。
その仮説だと特定のパケットだけまれに受信できないことから利用者には音抜けとして観測されるはず。発表内容(「片通話になったり発着信が出来なくなったりする」)を読むに音抜けのニュアンスは感じ取れないから、素直に(#4034360)の仮説の方がまだ可能性高いと思う。
RFC6935 と RFC2460 のどちらに従うかの「齟齬」と思われる。
RFC 2460 [ietf.org]→IPv6の基本仕様を定めたRFCで、UDPチェックサム必須RFC 6935 [ietf.org]→RFC 2460のUDPチェックサム必須仕様を削除するRFC
だよね。でも「プライベートIPアドレスをお使いの方にこの問題が生じる」「NAT環境下では動作しないか、極めて不安定である」という話なので、本質的にIPv4でのUDPチェックサムの取り扱いに関する問題で、IPv6は関係ないんじゃないかと。
もしかすると「IPv4/v6デュアルスタック環境では片通話となる」現象には関係しているかもしれない?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
UDPチェックサムの取扱に齟齬がありって、それ (スコア:0)
バグだろう。
既製品市販デバイスでそんなとこにバグが入り込むとは考えにくいから
ハードウェアオフロードでの自社開発アクセラレータロジックにバグが有ったとか?
TCPしか十分テストしてなかったのかね
# チェックサムって言ってるけどCRCでしょ。
Re:UDPチェックサムの取扱に齟齬がありって、それ (スコア:1)
IPv4でのUDPチェックサムは必須ではない(使用しない場合は0をセット)はずなのに、
どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ
Re:UDPチェックサムの取扱に齟齬がありって、それ (スコア:2, 参考になる)
> IPv4でのUDPチェックサムは必須ではない(使用しない場合は0をセット)はずなのに、
> どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ
近いけど、
・65536分の1の割合でUDPチェックサムの計算結果が0x0000になったときに0xffffに上書きしないNAPTのバグ
・チェックサムが0x0000のパケットを廃棄してしまうRakutenLinkのバグ
の相乗効果と予想。
割合は65536分の1でも、0x0000になるパケットは何度再送しても0x0000だから永久に受信できない。
逆、つまり、
・RakutenLinkがチェックサム0x0000を0xffffにしない
・NAPTがチェックサム0x0000を廃棄する
の組み合わせだと、チェックサム0x0000で送ってくる端末、OSなんてたくさんあるから、
RakutenLinkで問題になる前に気づいているはず。
Re: (スコア:0)
その仮説だと特定のパケットだけまれに受信できないことから利用者には音抜けとして観測されるはず。
発表内容(「片通話になったり発着信が出来なくなったりする」)を読むに音抜けのニュアンスは感じ取れないから、素直に(#4034360)の仮説の方がまだ可能性高いと思う。
Re:UDPチェックサムの取扱に齟齬がありって、それ (スコア:1)
RFC6935 と RFC2460 のどちらに従うかの「齟齬」と思われる。
Re:UDPチェックサムの取扱に齟齬がありって、それ (スコア:3, 興味深い)
RFC 2460 [ietf.org]→IPv6の基本仕様を定めたRFCで、UDPチェックサム必須
RFC 6935 [ietf.org]→RFC 2460のUDPチェックサム必須仕様を削除するRFC
だよね。でも「プライベートIPアドレスをお使いの方にこの問題が生じる」「NAT環境下では動作しないか、極めて不安定である」という話なので、本質的にIPv4でのUDPチェックサムの取り扱いに関する問題で、IPv6は関係ないんじゃないかと。
もしかすると「IPv4/v6デュアルスタック環境では片通話となる」現象には関係しているかもしれない?