tinydns
- v6パッチが当ててある場合は、env/IPにカンマ区切りでIPv6アドレスを追加すればOK
- AAAAレコードの定義が独特なので各自対処のこと(0省略なし・コロン区切りなし)
  - tinydns-dataに処理させるMakefile側でsedとかを使って整形するのが現実的か？

axfrdns (TCP response for tinydns)
- tinydnsと違いtcpserverからの起動なので、IP毎にtcpserverを立てる形式になる
  - v6パッチ付きucspi-tcpが必要
  - 最悪、intedから起動するのも有り
- アクセス制御でprefixlenを指定出来ないので、実用的には48bit prefixもしくは64bit prefix毎にallow/denyを設定することになる

firewall
- 境界でアドレス偽装パケットを弾いている場合、v4アドレス向けのnot address-range形式のdenyルールがv6パケットに適用されてないか要確認 (DNS通信試験時に嵌った)

rtadvd'およびDHCPv6 serverを立ち上げて、LAN側からIPv6アドレスを取得出来るところまでは確立

だが、外に出れない Orz

LAN側からWAN側にNTPv6でprefix変換して送出したパケットが戻ってこれない状況

原因は、回線側のルーターからNTPv6でprefix変換されてWAN側アドレスに対して近傍探索が届くが、WAN側のインターフェースに存在しないアドレスなので、応答しないため、回線側からWAN側インターフェースへの通信が開始されない模様

動かすには、NTPv6同様のaddress prefix付け替え対応なND Proxyが必要？
- Prefix Delegationで受けたときのND動作はどうなるのだろう？
NTPv6は標準化されたけど、IETF的には推奨してないらしぃ(おぃおぃ)

素直にNAT66で繋ごうにも、ipfwにNAT66は未実装な罠 Orz (pfは実装済みぽぃ)

回線側のサポートがあれば、DHCPv6-PDでWAN側からprefix delegationをもらってLAN側prefixを設定できるが、光電話契約してないので無理 (KAMEの影響か、BSD系の設定例はWIDE DHCP clientを使ったものが多い様だ)

回線契約形態で、prefix delegationの振り出し状態が変わるということは、ND動作を考えると、回線側のルータ設定も連動して変更されていて、prefix block単位でroutingされているのかなぁ…

NAT66のためだけにipfwからpfへ切り替えるのも面倒くさそう…(YAMAHAルーター買ってくるか？)

まあ、socket pid/gid filteringは止めたのでipfwでないと困る理由もなくなったのだが

DHCPやlink localな通信を先に許可した後、残りの通信に対してLAN側に割り当て済みのアドレステーブルを使って

なフィルターを仕掛けているが、DHCPv6-PDでglobal-prefixをLAN側に告知した場合、globalな通信に関したWAN側と同じprefixが付くのでフィルターに引っかかってしまう

global-prefixをもらってくるか、さもなくばglobal IF同様にglobal-unicastを通過させるしかないか…

global-prefixを抜き取るアイデアとしては、rtsoldを改造して、M/O/Rオプションで外部scriptを起動するように、RA-prefixを受け取った時に外部scriptを起動させるという案がある