IPv6設定のためのコマンド類の疑問点がほぼ解明したので
Rev11.00.19からRev.11.00.20へfirmwareをアップデートした
Rev11.00.19からRev.11.00.20へfirmwareをアップデートした
NVR-500のrtadv send機能動作と制限についてで幾つかの調査事項が判明した。
(1)2つ以上のproxy定義prefixを設定できない
・proxy設定されたprefixがどのようなタイミングで広告されるのか
下記のようにpp2でispへIPv6PPPoE接続され配布されたprefix（proxy定義）とフレッツ・ネクストから広告されたprefix値と同じprefix値（静的定義で）をrtadv sendでlan1へ広告している
ipv6 prefix 2 dhcp-prefix@pp2::/64
ipv6 prefix 10 2408:XXXX:YYYY:110::/64
ipv6 lan1 rtadv send 2 10 o_flag=on
「ipv6 prefix #」で指定されたprefix値を直接変更した場合（rtadv sendを変更しない）は、prefixに指定された「validlifetime」値で変更される。確認していないが、変更前のprefixと変更後のprefixが広告され、変更前のprefixのvalidlifetimeが過ぎると変更前のprefixが広告されなくなる。
「ipv6 lan1 rtadv」を変更した場合、変更後直ちに繁栄されるが、proxy定義のprefix値は、proxy定義のprefixが更新されたタイミングで反映される。plalaのIPv6PPPoEで配布されるprefixは、dhcpv6で取得される。dhcpv6の更新タイミングは、14400（T1=7200,T2=12600）と定義されているため、定期的なリース更新タイミングは、120分（7200秒）となる。この更新タイミングで、prefix値が広告されることになるため、最大2時間となり、ほぼ、パケットモニタ結果と一致する。
フレッツ・ネクスト（PR-S300SE）から得るprefix値は、dhcpv6-pdリース期間14400（T1=7200,T2=11520）のため最大2時間で広告されるようになる。
「ipv6 lan1 rtadv send」を変更後、直ちに広告されるprefix値を反映させるには、dhcpv6のリース更新を強制的に実施する必要がある。
PR-S300SEからのdhcpv6-pdは、「ipv6 lan2 dhcp service client」を再発行することで実現できる。また、plalaのIPv6PPPoE接続pp2は、この接続を再接続させることで実現される。
(3)mtu値の広告オプション設定値に疑問がある
・詳細なmtu設定基準を確認する
再現性を見つけられないため、リブートすることになった。
2012/3/6 22:13:20(Rev. 11.00.17->11.00.19)にfirmware updateでリブートして以来リブートをしていなかったが、リブートを実施した。
2012/9/2 14:19:19(Rev. 11.00.19->11.00.19)
結果、mtu=1280が広告されていたが、lan1（広告対象インターフェース）のmtu=1500と同じmtu値が広告されるようになった。
これで、残された確認事項は、
（２）DNSサーバやドメイン情報をDHCPv6での提供が動作しない場合がある
・RAのo_flagオプションで起動されるDHCPv6動作の詳細を確認すること（ヤマハ確認中）
(1)2つ以上のproxy定義prefixを設定できない
・proxy設定されたprefixがどのようなタイミングで広告されるのか
下記のようにpp2でispへIPv6PPPoE接続され配布されたprefix（proxy定義）とフレッツ・ネクストから広告されたprefix値と同じprefix値（静的定義で）をrtadv sendでlan1へ広告している
ipv6 prefix 2 dhcp-prefix@pp2::/64
ipv6 prefix 10 2408:XXXX:YYYY:110::/64
ipv6 lan1 rtadv send 2 10 o_flag=on
「ipv6 prefix #」で指定されたprefix値を直接変更した場合（rtadv sendを変更しない）は、prefixに指定された「validlifetime」値で変更される。確認していないが、変更前のprefixと変更後のprefixが広告され、変更前のprefixのvalidlifetimeが過ぎると変更前のprefixが広告されなくなる。
「ipv6 lan1 rtadv」を変更した場合、変更後直ちに繁栄されるが、proxy定義のprefix値は、proxy定義のprefixが更新されたタイミングで反映される。plalaのIPv6PPPoEで配布されるprefixは、dhcpv6で取得される。dhcpv6の更新タイミングは、14400（T1=7200,T2=12600）と定義されているため、定期的なリース更新タイミングは、120分（7200秒）となる。この更新タイミングで、prefix値が広告されることになるため、最大2時間となり、ほぼ、パケットモニタ結果と一致する。
フレッツ・ネクスト（PR-S300SE）から得るprefix値は、dhcpv6-pdリース期間14400（T1=7200,T2=11520）のため最大2時間で広告されるようになる。
「ipv6 lan1 rtadv send」を変更後、直ちに広告されるprefix値を反映させるには、dhcpv6のリース更新を強制的に実施する必要がある。
PR-S300SEからのdhcpv6-pdは、「ipv6 lan2 dhcp service client」を再発行することで実現できる。また、plalaのIPv6PPPoE接続pp2は、この接続を再接続させることで実現される。
(3)mtu値の広告オプション設定値に疑問がある
・詳細なmtu設定基準を確認する
再現性を見つけられないため、リブートすることになった。
2012/3/6 22:13:20(Rev. 11.00.17->11.00.19)にfirmware updateでリブートして以来リブートをしていなかったが、リブートを実施した。
2012/9/2 14:19:19(Rev. 11.00.19->11.00.19)
結果、mtu=1280が広告されていたが、lan1（広告対象インターフェース）のmtu=1500と同じmtu値が広告されるようになった。
これで、残された確認事項は、
（２）DNSサーバやドメイン情報をDHCPv6での提供が動作しない場合がある
・RAのo_flagオプションで起動されるDHCPv6動作の詳細を確認すること（ヤマハ確認中）
JPCERTから「MS-CHAP v2 の認証情報漏えいの問題に関する注意喚起」が広報された。
nvr-500とiPhoneでpptp vpnを設定していたのを止めた。
nvr-500には、IPsec機能が無い。困った。。。
nvr-500とiPhoneでpptp vpnを設定していたのを止めた。
nvr-500には、IPsec機能が無い。困った。。。
NVR-500でIPv6PPPoEインターネット接続とIPv6フレッツ網への同時接続設定で要となる「ipv6 interface rtadv send」コマンドについて、「NVR500でIPv6利用の問題点」で幾つか掲げた(Rev.11.00.19)。
(1)2つ以上のproxy定義prefixを設定できない
(2)DNSサーバやサーチリスト情報をDHCPv6での提供が動作しない場合がある
(3)mtu値の広告オプション設定値に疑問がある
これらの詳細について少し確認したので、以下にメモしておく
（2012年7月30日 Rev.11.00.20がリリースされている）
------------------------------------------------------
(1)2つ以上のproxy定義prefixを設定できない
PR-S300SEからDHCPv6で得られたprefix(a)を
ipv6 prefix 1 dhcp-prefix@lan2::/64
IPv6PPPoE接続から得られるprefix(b)を
ipv6 prefix 2 dhcp-prefix@pp2::/64
PR-S300SEのlan側に広告されたprefix(c)を
ipv6 prefix 3 ra-prefix@lan2::/64
(a)のprefix値と同じprefixを静的に定義
ipv6 prefix 10 2408:XXXX:YYYY:110::/64
(b)のprefix値と同じprefixを静的に定義
ipv6 prefix 20 2400:AAAA:BBBB:4c00::/64
とすると下記の通り二つ以上のproxy定義のprefix広告が出来ない。
proxy定義のprefix一つと静的定義のprefix（複数可）を同時に広告することはできる（ヤマハ確認済み）
× ipv6 lan1 rtadv send 1 2 o_flag=on
× ipv6 lan1 rtadv send 2 3 o_flag=on
○ ipv6 lan1 rtadv send 1 20 o_flag=on
○ ipv6 lan1 rtadv send 2 10 o_flag=on
○ ipv6 lan1 rtadv send 3 20 o_flag=on
○ ipv6 lan1 rtadv send 10 20 o_flag=on
実際にこのコマンドを変更してlan1側に広告されるprefixを確認してみると広告されたり、されなかったりする。よくよく調べてみると設定通りのprefix値内容で広告されるまで「時間」がかかることが判った。
下記例では、1時間ちょっとであるが、条件によって2時間近くかかる場合がある。
広告するprefix値を変化させた後、広告されるまで十分な時間を置く必要がある。テストでprefix設定を変化させる場合に注意が必要である。
図(1)-1 ipv6 lan1 rtadv send 1 20 o_flag=on（広告されるまで1時間31分）
図(1)-2 ipv6 lan1 rtadv send 2 10 o_flag=on（広告されるまで1時間12分）
図(1)-3 ipv6 lan1 rtadv send 3 20 o_flag=on（広告されるまで11分）
proxy設定されたprefixがどのようなタイミングで広告されるのか調査が必要（ヤマハ問合せ中---2012/9/9 調査完了）
（２）DNSサーバやドメイン情報をDHCPv6での提供が動作しない場合がある
NVR-500のDHCPv6サーバ機能では、IPv6PPPoE接続のDHCPで取得した情報やPR-S300SEからDHCPv6で取得した情報を広告しているときだけ、広告中prefixと同時に取得した情報をDHCPv6サーバ機能で提供することができる。NVR-500に設定したリカーシブDNSをDHCPv6サーバ機能で提供することができない（ヤマハ確認済み）
「ipv6 interface rtadv send」の「o_flag=on」オプションを設定して下記広告時に取得できるdhcpv6情報を確認してみた
ipv6 lan1 rtadv send 1 20 o_flag=on（フレッツ接続されたPR-S300SEからDHCPで得たprefix情報を広告）
フレッツのドメイン・サーチリストが得られている。DNSアドレスは、PR-S300SEのアドレスになるはずであるが、NVR-500のIPv6PPPoE接続に使われるアドレスが設定されている。結果的に、NVR-500のリカーシブサーバ機能が提供されていることになる（ヤマハ確認中）
ipv6 lan1 rtadv send 2 10 o_flag=on（IPv6PPPoE接続のDHCPで得たprefix情報を広告）
IPv6PPPoE接続では、DNSサーチリストが提供されていないためDNSサーバアドレスだけが返されるはずだが、NVR-500のIPv6PPPoE接続に使われるアドレスが設定されている。
ipv6 lan1 rtadv send 3 20 o_flag=on（PR-S300SEのRAから得たprefix情報を広告）
PR-S300SEのRAからは、prefix情報しか得ていない。o_flag=onが設定されているがNVR-500からDHCPv6 Requestの発生は無い。raで受けたprefix情報を「rtadv send」で広告する場合、mtu値オプション設定は動作しない。受けたraにmtuオプションが設定されている場合は、その値が引き継がれ広告される(ヤマハ確認済み）。
PR-S300SEのraにmtu値広告が含まれていない。この場合、NVR-500がmtu値をどのような値に設定するか不明である。コマンド仕様に従うなら「rtadv send」で指定したinterfaceのmtu値が使われる事になる。mtu=1500となっているので仕様通りと推定される。
また、このRAを受けたルータや端末は、DHCPv6でDNSなどの情報取得動作をしていない。結果、DNS情報を返さないはずであるが、NVR-500には、IPv6PPPoE接続に使われるアドレスが設定されている。不思議（ヤマハ確認中）。
ipv6 lan1 rtadv send 10 20 o_flag=on（静的に定義されたprefix情報を広告）
この場合は、DHCPv6 Requestを行ってもNVR-500は、DHCPv6 Replyを返さない。静的に定義されたprefix情報を広告しているときでも、NVR-500のリカーシブDNSサーバ用アドレス情報をo_flag=onオプションに従ってReplyして欲しい。
(3)mtu値の広告オプション設定値に疑問がある
「ipv6 interface rtadv send」でmtuオプションを設定しない場合、mtu=autoとなり、インターフェースのmtu値が適応されるとコマンド仕様に記載されている。
図(1)-1、図(1)-2、図(1)-3でNVR-500から広告するmtu値を確認するとそれぞれmtu=1280、mtu=1280、mtu=1500となっている。
広告するinterfaceのmtuであれば、NVR-500のlan1なのでmtu=1500となるはず。IPv6PPPoE接続やPR-S300SEからDHCPv6で得た接続先interfaceのmtuであれば、図(1)-1ではmtu=1500（lan2のmtu）、図(1)-2ではmtu=1454（pp02のmtu）、図(1)-3ではmtu=1500（lan2のmtu）が予測される。詳細なmtu設定基準を確認する必要がある（ヤマハ確認中--- 2012/9/9 確認済み）。
raでprefixを受け「rtadv send」でそのraを広告する場合（ 図(1)-3 ）は、mtu値の変更が出来ない仕様であることを確認している（ヤマハ確認済み）
(1)2つ以上のproxy定義prefixを設定できない
(2)DNSサーバやサーチリスト情報をDHCPv6での提供が動作しない場合がある
(3)mtu値の広告オプション設定値に疑問がある
これらの詳細について少し確認したので、以下にメモしておく
（2012年7月30日 Rev.11.00.20がリリースされている）
------------------------------------------------------
(1)2つ以上のproxy定義prefixを設定できない
PR-S300SEからDHCPv6で得られたprefix(a)を
ipv6 prefix 1 dhcp-prefix@lan2::/64
IPv6PPPoE接続から得られるprefix(b)を
ipv6 prefix 2 dhcp-prefix@pp2::/64
PR-S300SEのlan側に広告されたprefix(c)を
ipv6 prefix 3 ra-prefix@lan2::/64
(a)のprefix値と同じprefixを静的に定義
ipv6 prefix 10 2408:XXXX:YYYY:110::/64
(b)のprefix値と同じprefixを静的に定義
ipv6 prefix 20 2400:AAAA:BBBB:4c00::/64
とすると下記の通り二つ以上のproxy定義のprefix広告が出来ない。
proxy定義のprefix一つと静的定義のprefix（複数可）を同時に広告することはできる（ヤマハ確認済み）
× ipv6 lan1 rtadv send 1 2 o_flag=on
× ipv6 lan1 rtadv send 2 3 o_flag=on
○ ipv6 lan1 rtadv send 1 20 o_flag=on
○ ipv6 lan1 rtadv send 2 10 o_flag=on
○ ipv6 lan1 rtadv send 3 20 o_flag=on
○ ipv6 lan1 rtadv send 10 20 o_flag=on
実際にこのコマンドを変更してlan1側に広告されるprefixを確認してみると広告されたり、されなかったりする。よくよく調べてみると設定通りのprefix値内容で広告されるまで「時間」がかかることが判った。
下記例では、1時間ちょっとであるが、条件によって2時間近くかかる場合がある。
広告するprefix値を変化させた後、広告されるまで十分な時間を置く必要がある。テストでprefix設定を変化させる場合に注意が必要である。
図(1)-1 ipv6 lan1 rtadv send 1 20 o_flag=on（広告されるまで1時間31分）
図(1)-2 ipv6 lan1 rtadv send 2 10 o_flag=on（広告されるまで1時間12分）
図(1)-3 ipv6 lan1 rtadv send 3 20 o_flag=on（広告されるまで11分）
proxy設定されたprefixがどのようなタイミングで広告されるのか調査が必要（ヤマハ問合せ中---2012/9/9 調査完了）
（２）DNSサーバやドメイン情報をDHCPv6での提供が動作しない場合がある
NVR-500のDHCPv6サーバ機能では、IPv6PPPoE接続のDHCPで取得した情報やPR-S300SEからDHCPv6で取得した情報を広告しているときだけ、広告中prefixと同時に取得した情報をDHCPv6サーバ機能で提供することができる。NVR-500に設定したリカーシブDNSをDHCPv6サーバ機能で提供することができない（ヤマハ確認済み）
「ipv6 interface rtadv send」の「o_flag=on」オプションを設定して下記広告時に取得できるdhcpv6情報を確認してみた
ipv6 lan1 rtadv send 1 20 o_flag=on（フレッツ接続されたPR-S300SEからDHCPで得たprefix情報を広告）
フレッツのドメイン・サーチリストが得られている。DNSアドレスは、PR-S300SEのアドレスになるはずであるが、NVR-500のIPv6PPPoE接続に使われるアドレスが設定されている。結果的に、NVR-500のリカーシブサーバ機能が提供されていることになる（ヤマハ確認中）
ipv6 lan1 rtadv send 2 10 o_flag=on（IPv6PPPoE接続のDHCPで得たprefix情報を広告）
IPv6PPPoE接続では、DNSサーチリストが提供されていないためDNSサーバアドレスだけが返されるはずだが、NVR-500のIPv6PPPoE接続に使われるアドレスが設定されている。
ipv6 lan1 rtadv send 3 20 o_flag=on（PR-S300SEのRAから得たprefix情報を広告）
PR-S300SEのRAからは、prefix情報しか得ていない。o_flag=onが設定されているがNVR-500からDHCPv6 Requestの発生は無い。raで受けたprefix情報を「rtadv send」で広告する場合、mtu値オプション設定は動作しない。受けたraにmtuオプションが設定されている場合は、その値が引き継がれ広告される(ヤマハ確認済み）。
PR-S300SEのraにmtu値広告が含まれていない。この場合、NVR-500がmtu値をどのような値に設定するか不明である。コマンド仕様に従うなら「rtadv send」で指定したinterfaceのmtu値が使われる事になる。mtu=1500となっているので仕様通りと推定される。
また、このRAを受けたルータや端末は、DHCPv6でDNSなどの情報取得動作をしていない。結果、DNS情報を返さないはずであるが、NVR-500には、IPv6PPPoE接続に使われるアドレスが設定されている。不思議（ヤマハ確認中）。
ipv6 lan1 rtadv send 10 20 o_flag=on（静的に定義されたprefix情報を広告）
この場合は、DHCPv6 Requestを行ってもNVR-500は、DHCPv6 Replyを返さない。静的に定義されたprefix情報を広告しているときでも、NVR-500のリカーシブDNSサーバ用アドレス情報をo_flag=onオプションに従ってReplyして欲しい。
(3)mtu値の広告オプション設定値に疑問がある
「ipv6 interface rtadv send」でmtuオプションを設定しない場合、mtu=autoとなり、インターフェースのmtu値が適応されるとコマンド仕様に記載されている。
図(1)-1、図(1)-2、図(1)-3でNVR-500から広告するmtu値を確認するとそれぞれmtu=1280、mtu=1280、mtu=1500となっている。
広告するinterfaceのmtuであれば、NVR-500のlan1なのでmtu=1500となるはず。IPv6PPPoE接続やPR-S300SEからDHCPv6で得た接続先interfaceのmtuであれば、図(1)-1ではmtu=1500（lan2のmtu）、図(1)-2ではmtu=1454（pp02のmtu）、図(1)-3ではmtu=1500（lan2のmtu）が予測される。詳細なmtu設定基準を確認する必要がある（ヤマハ確認中--- 2012/9/9 確認済み）。
raでprefixを受け「rtadv send」でそのraを広告する場合（ 図(1)-3 ）は、mtu値の変更が出来ない仕様であることを確認している（ヤマハ確認済み）
NVR-500のRouter Advertisement設定「ipv6 interface rtadv send」を設定するとMTU値も広告する。PR-S300SEのRAで設定したとき「mtu=auto」「mtu=1454」「mtu=off」のいずれの設定をしてもmtu値1500が広告されていた。何故なのかは判っていない。
PR-S300SEのDHCPv6-PD機能で設定した場合は、「mtu=auto」でmtu値が1280で広告されている。
コマンド仕様では、autoの場合インターフェースのmtuが採用される。NVR-500のipv6インターフェースmtuは、「ipv6 interface mtu」で初期値1500となっているので1280に何故なるのか？
現在設定されているIPv6のmtu値を確認するコマンドも判らない。
各インターフェース（PlalaのIPv6PPPoE接続-1454、サービス情報サイトIPv6IPoE-1280?）で得られる最小のmtuに設定されるのか？
サービス情報サイトのIPv6 mtu値が1280である理由は、以下の事実からの推定である
「ipv6 interface rtadv send」で「mtu=1454」と「mtu=1280」に設定してサービス情報サイトのフレッツ速度計測（IPv6）サイトを確認してみた。
mtu=1454の場合
計測ができない
mtu=1280の場合
計測ができる
この結果サービス情報サイトのフレッツ速度計測には、mtu値が1280である必要があると推定した。
pingでデータ長を指定してフラグメントしない設定でmtu値を確認する手段が知られている。IPv6では、フラグメントしないのが標準なのでmtu値を超えると応答しないことで確認が出来ると思う。
IPv6では、ヘッダー40バイトとICMPヘッダー8バイトなので「ping -6 -l 1232 target.address」で応答があると推定して「ping -6 -l 1232 flets-east.jp」としてみるが応答しない。
データ長を色々変化させた結果、下記のような結果となった。
mtu=560（=512+40+8）？
PR-S300SEのDHCPv6-PD機能で設定した場合は、「mtu=auto」でmtu値が1280で広告されている。
コマンド仕様では、autoの場合インターフェースのmtuが採用される。NVR-500のipv6インターフェースmtuは、「ipv6 interface mtu」で初期値1500となっているので1280に何故なるのか？
現在設定されているIPv6のmtu値を確認するコマンドも判らない。
各インターフェース（PlalaのIPv6PPPoE接続-1454、サービス情報サイトIPv6IPoE-1280?）で得られる最小のmtuに設定されるのか？
サービス情報サイトのIPv6 mtu値が1280である理由は、以下の事実からの推定である
「ipv6 interface rtadv send」で「mtu=1454」と「mtu=1280」に設定してサービス情報サイトのフレッツ速度計測（IPv6）サイトを確認してみた。
mtu=1454の場合
計測ができない
mtu=1280の場合
計測ができる
この結果サービス情報サイトのフレッツ速度計測には、mtu値が1280である必要があると推定した。
pingでデータ長を指定してフラグメントしない設定でmtu値を確認する手段が知られている。IPv6では、フラグメントしないのが標準なのでmtu値を超えると応答しないことで確認が出来ると思う。
IPv6では、ヘッダー40バイトとICMPヘッダー8バイトなので「ping -6 -l 1232 target.address」で応答があると推定して「ping -6 -l 1232 flets-east.jp」としてみるが応答しない。
データ長を色々変化させた結果、下記のような結果となった。
mtu=560（=512+40+8）？
アクセス
トータル
