![FJ cruiser [FJクルーザー]](https://logo-imagecluster.img.mixi.jp/photo/comm/43/63/434363_174s.jpg){kind=logo}
|
|
|
|
コメント(43)
> ... ただ、このやりかただと routing table が壊れて
> しまうのか、RA で振り出した先の IP と ping6 が
> うまく飛ばないようです。
固定 IP 用と ユニキャスト用に prefix 64 を分けて、
ユニキャスト用の prefix だけを /etc/ratdvd.conf に書いた
のが原因だったようです。
この場合には、もう少し ratdvd.conf を書き足さないと
いけないんでしょうね。
ratdvd.conf を書かないと、固定 IP からも勝手に prefix を
振り出して配下に IP を振ってしまうのがどうかと
思うのですが…
> しまうのか、RA で振り出した先の IP と ping6 が
> うまく飛ばないようです。
固定 IP 用と ユニキャスト用に prefix 64 を分けて、
ユニキャスト用の prefix だけを /etc/ratdvd.conf に書いた
のが原因だったようです。
この場合には、もう少し ratdvd.conf を書き足さないと
いけないんでしょうね。
ratdvd.conf を書かないと、固定 IP からも勝手に prefix を
振り出して配下に IP を振ってしまうのがどうかと
思うのですが…
> >固定 IP 用と ユニキャスト用に prefix 64 を分けて、
> これの意図はなんですか? 別に分ける必要ないですよね。
はい、意図は「サーバ群 (特に DNSサーバ )には、固定の IP も持たせたいが、実験環境ネットワーク全体には RA でユニキャストアドレスが自動的に割り振られる。IP の衝突を避けたい」です。
今日の昼ごろに、「そうか、ratdvd というのは "ルーティンデーモン" なんだから、prefix 64 を分けられていたら ping6 が通らないのは当たり前だ。すると suffix のほうで、使われないことが保障されている 64 bit を指定してやれば、RA が割り振るユニキャストアドレスとコンフリクトしないで済むな」と考え、suffix で使われないことが保障されているアドレスを探していました。
"reserved unicast" といったキーワードで調べ、
RFC2855, RFC2856, RFC 3849 , RFC 3587 などをみつけました。
自動割り当て時に suffix に使われるInterface ID のことを EUI-64 と呼ぶことを知り、
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
もみつけました。
しかし、いまだに EUI-64 で「使わないことが保障されている」64bit, もしくは上位16 bit について確認できていません。
逆に、RA の NIC の IP のひとつに、あえてノード下のカードの使用する MAC アドレスを alias として与えてみて、2つの同一 IP の別インタフェイスが発生してしまうことを確認しました。
( duplicate 、と FreeBSD の ifconfig は警告しますね)
常識/経験則的には prefix64::1 辺りならば確実にコンフリクトしないだろうと思っているのですが、保障が見つからないので困っています。
EUI-64 については別の話題も… 次記事に続きます。
> これの意図はなんですか? 別に分ける必要ないですよね。
はい、意図は「サーバ群 (特に DNSサーバ )には、固定の IP も持たせたいが、実験環境ネットワーク全体には RA でユニキャストアドレスが自動的に割り振られる。IP の衝突を避けたい」です。
今日の昼ごろに、「そうか、ratdvd というのは "ルーティンデーモン" なんだから、prefix 64 を分けられていたら ping6 が通らないのは当たり前だ。すると suffix のほうで、使われないことが保障されている 64 bit を指定してやれば、RA が割り振るユニキャストアドレスとコンフリクトしないで済むな」と考え、suffix で使われないことが保障されているアドレスを探していました。
"reserved unicast" といったキーワードで調べ、
RFC2855, RFC2856, RFC 3849 , RFC 3587 などをみつけました。
自動割り当て時に suffix に使われるInterface ID のことを EUI-64 と呼ぶことを知り、
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
もみつけました。
しかし、いまだに EUI-64 で「使わないことが保障されている」64bit, もしくは上位16 bit について確認できていません。
逆に、RA の NIC の IP のひとつに、あえてノード下のカードの使用する MAC アドレスを alias として与えてみて、2つの同一 IP の別インタフェイスが発生してしまうことを確認しました。
( duplicate 、と FreeBSD の ifconfig は警告しますね)
常識/経験則的には prefix64::1 辺りならば確実にコンフリクトしないだろうと思っているのですが、保障が見つからないので困っています。
EUI-64 については別の話題も… 次記事に続きます。
> 次記事に続きます。
次記事です
Windows XP に、FreeBSD から振り出した RA で何度かユニキャストアドレスを割り当てて実験しています。
EUI-64 は "イーサネットカードではふつう MAC アドレスを使う" とは書いてあったけれども、「MAC アドレスを使うことは保障されない」とも読めるので、毎回 EUI-64 が違うこと自体は納得できます。
問題は、6 で URL をあげた ieee.org の説明は、
EUI-64 についても上位 16bit は company_id である、と書いてあるように私には読めます。
ところが Windows XP が RA を受けて生成する下位64bit は
c85f:7f53:9f19:c4d1
f49b:372b:ff6b:a020
50f6:f97c:aee0:e95d
と、まったくばらばらです。
(ちなみに MAC アドレスは 00-08-0d-65-4c-0e と表示されています )
これは「こういうもの」で良いのでしょうか?
Microsoft が c85f, f49b, 50f6 のそれぞれを company_id として振り出してもらっている、と考えるべきなのでしょうか。
次記事です
Windows XP に、FreeBSD から振り出した RA で何度かユニキャストアドレスを割り当てて実験しています。
EUI-64 は "イーサネットカードではふつう MAC アドレスを使う" とは書いてあったけれども、「MAC アドレスを使うことは保障されない」とも読めるので、毎回 EUI-64 が違うこと自体は納得できます。
問題は、6 で URL をあげた ieee.org の説明は、
EUI-64 についても上位 16bit は company_id である、と書いてあるように私には読めます。
ところが Windows XP が RA を受けて生成する下位64bit は
c85f:7f53:9f19:c4d1
f49b:372b:ff6b:a020
50f6:f97c:aee0:e95d
と、まったくばらばらです。
(ちなみに MAC アドレスは 00-08-0d-65-4c-0e と表示されています )
これは「こういうもの」で良いのでしょうか?
Microsoft が c85f, f49b, 50f6 のそれぞれを company_id として振り出してもらっている、と考えるべきなのでしょうか。
長くなっちゃうので2つに分けますね。
>しかし、いまだに EUI-64 で「使わないことが保障されている」>64bit, もしくは上位16 bit について確認できていません。
RFC3513の8ページ下の図をみてください。「u」と書いてあるbitがuniversal/local bitです。まともなethernetカードのMACアドレスではこのbitは必ず0(IEEEからMACアドレスの割当を受けている)です。ethernetからlink-local addressを生成するとき、このbitは反転されます。すなわち、link-local addressの(もしくはRAを受けたときにつくIPv6アドレスの)下64bitでは、「u」bitは必ず1になります。
ですから、固定で割り当てたいIPv6アドレスがある場合、「u」bitを0にしておけば大丈夫です。例えば、2001:240:501::53:0 (うちのネームサーバですが)は「u」bitが0なので安全です。
>しかし、いまだに EUI-64 で「使わないことが保障されている」>64bit, もしくは上位16 bit について確認できていません。
RFC3513の8ページ下の図をみてください。「u」と書いてあるbitがuniversal/local bitです。まともなethernetカードのMACアドレスではこのbitは必ず0(IEEEからMACアドレスの割当を受けている)です。ethernetからlink-local addressを生成するとき、このbitは反転されます。すなわち、link-local addressの(もしくはRAを受けたときにつくIPv6アドレスの)下64bitでは、「u」bitは必ず1になります。
ですから、固定で割り当てたいIPv6アドレスがある場合、「u」bitを0にしておけば大丈夫です。例えば、2001:240:501::53:0 (うちのネームサーバですが)は「u」bitが0なので安全です。
>これは「こういうもの」で良いのでしょうか?
>Microsoft が c85f, f49b, 50f6 のそれぞれを company_id として振り出してもらっている、と考えるべきなのでしょうか。
Windowsがないのですが、link-local addressの下64bitはどうなってますか?
これは、Microsoft実装がRAを受けたときのアドレス割当に疑似乱数を使うことにしている、というだけです。ただ、この方針ではDNSサーバ(逆ひき正ひきとも)にRAで割り振られたアドレスを登録しようとしても不可能です。どこかに必ずMACアドレスから作られた下64bitを使うようにするスイッチがあるはずです。RFC3041サポートをonにしていませんか? していたらoffにしてください。
>Microsoft が c85f, f49b, 50f6 のそれぞれを company_id として振り出してもらっている、と考えるべきなのでしょうか。
Windowsがないのですが、link-local addressの下64bitはどうなってますか?
これは、Microsoft実装がRAを受けたときのアドレス割当に疑似乱数を使うことにしている、というだけです。ただ、この方針ではDNSサーバ(逆ひき正ひきとも)にRAで割り振られたアドレスを登録しようとしても不可能です。どこかに必ずMACアドレスから作られた下64bitを使うようにするスイッチがあるはずです。RFC3041サポートをonにしていませんか? していたらoffにしてください。
machine-Aがfe80::aaaa、machine-Bがfe80::bbbbだとします。
machine-Aからmachine-Bにtelnetするときには、
% telnet fe80::bbbb%eth0 (eth0はmachine-Aのmachine-B向きの足)
machine-Bからmachine-Aにtelnetするときには、
% telnet fe80::aaaa%eth0 (eth0はmachine-Bのmachine-A向きの足)
とする必要があります。fe80始まりのアドレスは単一ethernet link(または他の物理媒体)上でしかuniqueではないので、どっちから出るのか明示的に指定しないとだめです。
Linuxでやったことないんでこれでうまくいくかはちょっと自信ないですが、仕様どおりに実装していればこれでいけるはず。
# struct sockaddr_in6のsin6_scope_id
machine-Aからmachine-Bにtelnetするときには、
% telnet fe80::bbbb%eth0 (eth0はmachine-Aのmachine-B向きの足)
machine-Bからmachine-Aにtelnetするときには、
% telnet fe80::aaaa%eth0 (eth0はmachine-Bのmachine-A向きの足)
とする必要があります。fe80始まりのアドレスは単一ethernet link(または他の物理媒体)上でしかuniqueではないので、どっちから出るのか明示的に指定しないとだめです。
Linuxでやったことないんでこれでうまくいくかはちょっと自信ないですが、仕様どおりに実装していればこれでいけるはず。
# struct sockaddr_in6のsin6_scope_id
> daemonは設定したアドレスでlistenしてますか?
> netstatで確認しましたか?
どこの課題か判らないけど、課題で出されている ということは、出した人は出来ることは確認済み なのではと予想。telnetd入れ替えるとか、ソース見て修正いれないと対応できない課題は、多分出さないと思うけど。。。
ググッて見たら CentOS は、初期状態 telnetd無効ってなってるし、WildGeeseさんの提示したチェック項目の回答が未だ無いので、Telnetd が有効になってないとか、そういうオチを予想。
あるいは ROOT で繋ぎにいっていて蹴られてるとか。(Rootはダメっぽい)
Wiresharkでもぶち込んで、どの時点でエラーになってるか確認できると、めっちゃ近道だけど、、
それは可能かな？
> netstatで確認しましたか?
どこの課題か判らないけど、課題で出されている ということは、出した人は出来ることは確認済み なのではと予想。telnetd入れ替えるとか、ソース見て修正いれないと対応できない課題は、多分出さないと思うけど。。。
ググッて見たら CentOS は、初期状態 telnetd無効ってなってるし、WildGeeseさんの提示したチェック項目の回答が未だ無いので、Telnetd が有効になってないとか、そういうオチを予想。
あるいは ROOT で繋ぎにいっていて蹴られてるとか。(Rootはダメっぽい)
Wiresharkでもぶち込んで、どの時点でエラーになってるか確認できると、めっちゃ近道だけど、、
それは可能かな？
すみません質問します。
今日CCNA試験の問題をやっていたんですが、「拡張IPアクセスリスト」の問題で
「DNSを特定のインターフェイスからの出力をさせない設定にする」問題中でDNSの５３番ポートからのUDPパケットとTCPパケットが出力できないようにするものでした。
私はDNS（IPv4ですが）がクエリを出しているのを時々パケタイザーで監視しているのですがいつもUDPでクエリを出しています。インターネットでDNSを調べるとDNSクエリーが512バイト未満であればTCPセッションを張らないとかいてありました。
これはROOT−SERVERがDNSの更新時にROOT-SERVER全ての新しいIPアドレスをレスポンスで送るバイトを世界で13箇所アルROOT-SERVERのIPアドレスでまかなう言うにレスポンスをUDP送信バイトの上限値に設定した為とかかれていました。早速パケタイザーを起動してNSLOOKUPでROOT-SERVER.NETとクエリーを要求したらッレスポンスはちゃんと512バイト以内で帰ってきていました。
じゃあIPV6アドレスでクエリーを出すとレスポンスは512バイトを超えるんでTCPセッションをはるのかなと思い、NSLOOKUPに「set type=AAAA」と打ち込みA-ROOT-SERVER.NETと打ち込んでもエラーで帰ってきました。私のOSはWindows2000Proなのですが、IPv6パッチをあてping6も動くのですがどうもTCP/IPドライバでIPv6を生成していないようです。
前置きが長くなってしまいましたが
質問は、「DNSクエリーをIPv6のアドレスで送る時、たとえROOT-SERVERのIPv6アドレスでもクエリーが512バイトを越える時はTCPセッションでレスポンスが帰ってくるのでしょうか？」
現在の環境ではどうも検証できません。ご教授お願いします。
私の家の環境
NTTflets24Mモア---ADSLmodem---BBrouter--------L2-SW-----PC(Win2KproSP6a)
(WebCasterV110) |
|
|------PC(FedoraCore7)
|
|------PC(RedHatLinux7.2)
※NTTのプロバイダからはIPv6アドレスはもらっていないようです。
(Fedora７のIPv6アドレスが生成されていません。リンクローカルアドレス
のままです。）
今日CCNA試験の問題をやっていたんですが、「拡張IPアクセスリスト」の問題で
「DNSを特定のインターフェイスからの出力をさせない設定にする」問題中でDNSの５３番ポートからのUDPパケットとTCPパケットが出力できないようにするものでした。
私はDNS（IPv4ですが）がクエリを出しているのを時々パケタイザーで監視しているのですがいつもUDPでクエリを出しています。インターネットでDNSを調べるとDNSクエリーが512バイト未満であればTCPセッションを張らないとかいてありました。
これはROOT−SERVERがDNSの更新時にROOT-SERVER全ての新しいIPアドレスをレスポンスで送るバイトを世界で13箇所アルROOT-SERVERのIPアドレスでまかなう言うにレスポンスをUDP送信バイトの上限値に設定した為とかかれていました。早速パケタイザーを起動してNSLOOKUPでROOT-SERVER.NETとクエリーを要求したらッレスポンスはちゃんと512バイト以内で帰ってきていました。
じゃあIPV6アドレスでクエリーを出すとレスポンスは512バイトを超えるんでTCPセッションをはるのかなと思い、NSLOOKUPに「set type=AAAA」と打ち込みA-ROOT-SERVER.NETと打ち込んでもエラーで帰ってきました。私のOSはWindows2000Proなのですが、IPv6パッチをあてping6も動くのですがどうもTCP/IPドライバでIPv6を生成していないようです。
前置きが長くなってしまいましたが
質問は、「DNSクエリーをIPv6のアドレスで送る時、たとえROOT-SERVERのIPv6アドレスでもクエリーが512バイトを越える時はTCPセッションでレスポンスが帰ってくるのでしょうか？」
現在の環境ではどうも検証できません。ご教授お願いします。
私の家の環境
NTTflets24Mモア---ADSLmodem---BBrouter--------L2-SW-----PC(Win2KproSP6a)
(WebCasterV110) |
|
|------PC(FedoraCore7)
|
|------PC(RedHatLinux7.2)
※NTTのプロバイダからはIPv6アドレスはもらっていないようです。
(Fedora７のIPv6アドレスが生成されていません。リンクローカルアドレス
のままです。）
A-ROOT-SERVER.NET ではなく A.ROOT-SERVERS.NET では?
ま、それはともかく。
Windows 2000 の IPv6 スタックって MSR 製のものですか?
あれはかなり不完全なものなので、Windows ならせめて XP を使うかできれば Vista がいいかと。用意するのが辛いなら BSD 系の OS とかを使って試した方が素直だと思いますよ。
それと、IPv4 しか通ってない環境でも AAAA レコードを引く事は普通にできるわけで、問題は別のところにある気がします。
ちなみに Vista の nslookup の場合だとこんな感じです。(IPv6 で DNS に問い合わせてますが ;)
C:\Users\xxxx>nslookup -type=aaaa a.root-servers.net
サーバー: dns.example.jp
Address: [2001:xxx:xxx:xxxx::xx:x]:53
名前: a.root-servers.net
C:\Users\xxxx>
ま、それはともかく。
Windows 2000 の IPv6 スタックって MSR 製のものですか?
あれはかなり不完全なものなので、Windows ならせめて XP を使うかできれば Vista がいいかと。用意するのが辛いなら BSD 系の OS とかを使って試した方が素直だと思いますよ。
それと、IPv4 しか通ってない環境でも AAAA レコードを引く事は普通にできるわけで、問題は別のところにある気がします。
ちなみに Vista の nslookup の場合だとこんな感じです。(IPv6 で DNS に問い合わせてますが ;)
C:\Users\xxxx>nslookup -type=aaaa a.root-servers.net
サーバー: dns.example.jp
Address: [2001:xxx:xxx:xxxx::xx:x]:53
名前: a.root-servers.net
C:\Users\xxxx>
FreeBSD 6.2 の libc/resolv のコードを眺めた限りでは、TCP で問い合わせするコードはあるものの、通常の問い合わせに TCP が使われることはなさそうです。問い合わせる内容が AAAA だろうが A だろうが、また、ネットワーク層が IPv4 だろうが IPv6 だろうが関係ありません。
TCP で問い合わせること自体は可能で、bind9 付属の dig コマンドで
% dig +tcp -t a mixi.jp..
などとやれば、TCP で問い合わせしますので、リゾルバライブラリの造り次第ではあると思いますが、TCP は DNS サーバに負担がかかりますから、一般的には UDP を使うのでしょう。
通常は、DNS プライマリサーバとセカンダリサーバの間でゾーン情報全体を転送する AXFR 等の時に TCP が使われるようです。
TCP で問い合わせること自体は可能で、bind9 付属の dig コマンドで
% dig +tcp -t a mixi.jp..
などとやれば、TCP で問い合わせしますので、リゾルバライブラリの造り次第ではあると思いますが、TCP は DNS サーバに負担がかかりますから、一般的には UDP を使うのでしょう。
通常は、DNS プライマリサーバとセカンダリサーバの間でゾーン情報全体を転送する AXFR 等の時に TCP が使われるようです。
初めまして。
IPアドレスをMACアドレスから生成する方法を読んで疑問がわきました。
http://journal.mycom.co.jp/series/ipv6/005/index.html
この方法だと、重複は起きないでしょうけど48ｂｉｔしか使えないのは変わりないですよね？
まあ、v4に比べたらずっと多いIPアドレスを触れるのには変わりないですが、v6は128bit
だからすごいんだよって言っているのにちょっと看板に偽りありな気がしました。
ｘ86_64がアドレスバスを48bitしか用意しないのと同じ発想なのかなとは思いますが。
間違っているならぜひ指摘してください。
よろしくお願いします。
IPアドレスをMACアドレスから生成する方法を読んで疑問がわきました。
http://journal.mycom.co.jp/series/ipv6/005/index.html
この方法だと、重複は起きないでしょうけど48ｂｉｔしか使えないのは変わりないですよね？
まあ、v4に比べたらずっと多いIPアドレスを触れるのには変わりないですが、v6は128bit
だからすごいんだよって言っているのにちょっと看板に偽りありな気がしました。
ｘ86_64がアドレスバスを48bitしか用意しないのと同じ発想なのかなとは思いますが。
間違っているならぜひ指摘してください。
よろしくお願いします。
まあ、独立したtopicをあげるほどの大げさな話でも無いので、こちらで。
Feel6を使っているのですが、1/13頃からpacket lossが多くなってます。
一例:
gustav: {2049} ping6 ftp.netbsd.org
PING6(56=40+8+8 bytes) 2001:3e0:a01::1 --> 2001:4f8:3:7:230:48ff:fec6:9aaa
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=1 hlim=51 time=132.747 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=3 hlim=51 time=121.493 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=5 hlim=51 time=140.178 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=7 hlim=50 time=139.974 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=9 hlim=51 time=140.353 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=11 hlim=50 time=137.274 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=13 hlim=51 time=140.666 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=15 hlim=50 time=137.621 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=17 hlim=51 time=120.951 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=19 hlim=51 time=120.833 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=21 hlim=50 time=148.708 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=23 hlim=50 time=135.852 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=25 hlim=50 time=135.211 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=27 hlim=50 time=137.687 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=29 hlim=51 time=121.078 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=31 hlim=50 time=140.282 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=33 hlim=50 time=138.174 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=34 hlim=51 time=121.565 ms
^C
--- ftp.netbsd.org ping6 statistics ---
35 packets transmitted, 18 packets received, 48.6% packet loss
round-trip min/avg/max/std-dev = 120.833/133.925/148.708/8.736 ms
相手はfeel6外ばかり試してますが、どこでも半分近くのpacketが落ちてる状態です。
…という具合なのですが、他のFeel6ユーザの皆さんはどんなもんでしょうか?
うちだけかしらん?
Feel6を使っているのですが、1/13頃からpacket lossが多くなってます。
一例:
gustav: {2049} ping6 ftp.netbsd.org
PING6(56=40+8+8 bytes) 2001:3e0:a01::1 --> 2001:4f8:3:7:230:48ff:fec6:9aaa
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=1 hlim=51 time=132.747 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=3 hlim=51 time=121.493 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=5 hlim=51 time=140.178 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=7 hlim=50 time=139.974 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=9 hlim=51 time=140.353 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=11 hlim=50 time=137.274 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=13 hlim=51 time=140.666 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=15 hlim=50 time=137.621 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=17 hlim=51 time=120.951 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=19 hlim=51 time=120.833 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=21 hlim=50 time=148.708 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=23 hlim=50 time=135.852 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=25 hlim=50 time=135.211 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=27 hlim=50 time=137.687 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=29 hlim=51 time=121.078 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=31 hlim=50 time=140.282 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=33 hlim=50 time=138.174 ms
16 bytes from 2001:4f8:3:7:230:48ff:fec6:9aaa, icmp_seq=34 hlim=51 time=121.565 ms
^C
--- ftp.netbsd.org ping6 statistics ---
35 packets transmitted, 18 packets received, 48.6% packet loss
round-trip min/avg/max/std-dev = 120.833/133.925/148.708/8.736 ms
相手はfeel6外ばかり試してますが、どこでも半分近くのpacketが落ちてる状態です。
…という具合なのですが、他のFeel6ユーザの皆さんはどんなもんでしょうか?
うちだけかしらん?
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
IPv6 更新情報
-
最新のアンケート
IPv6のメンバーはこんなコミュニティにも参加しています
人気コミュニティランキング
- 1位
- お洒落な女の子が好き
- 90068人
- 2位
- 写真を撮るのが好き
- 208325人
- 3位
- 酒好き
- 170698人