Orz日記 by Akio Morita

_ [SAD][LHC]軌道比較: TRACK vs TWISS(その2)

SAD上のLHC latticeで TrackParticles[]と Twiss[]で求めた軌道を比較して結果

どうやら、CODの不一致の原因はMULTエレメントで軌道を 蹴っているかどうかに依存している模様

にもかかわらず、(MARK DRIFT MULT DRIFT)なビームラインでは TrackPatciles[]とTwiss[]の軌道が一致している...なにゆぇ Orz

_ [SAD][LHC]軌道比較: TRACK vs TWISS(その3)

発現条件の特定に成功した。

• MULTエレメントを含むビームライン
• MULTエレメントがL=0かつNot[K0 == 0 && SK == 0]

のときに Twiss[]と TrackParticles[]の軌道が食い違う。 多分、thin elementな場合のコードに抜けがあると思われる。 (thin elementを特別扱いしていなければ、K0/SK0による キックが現れるはず)

おおよその目星は付いたので、次は MULTエレメントの実装の精読か...

_ [FreeBSD]11.1 RELEASE builds begin

どうやら、予定通りにRELEASE buildの生成作業が開始されて模様

よほど致命的な問題でも起きない限り、7月中に11.1-RELEASEが出てくるはず

_ [FreeBSD][IPv6]IPv4 over IPv6 (MAP-E)

別FIB上で、試してみた

まずは、IPv6のWAN側のGlobal Unicast Addressから、MAP-Eに必要なパラメータを手に入れる (例えば、 http://ipv4.web.fc2.com/map-e.html )

• 境界リレー(BR)のIPv6 Address
• 加入者側終端(CE)のIPv6 AddressとIPv4 Address
• PSID offset/PSID length/PSIDの三つ組(ポート変換のパラメータ)

IPv4アドレスが不足気味なので、CE IPv4 addressは固定値になる模様

最低限の設定は、以下の通り

• gif tunnel構築 (CE-IPv6-address -> BR-IPv6-address) / upすることを忘れずに
• pfctlにnat on gif from <lan-ip4> to any -> CE-IPv4-address map-e-portset PSID-offset/PSID-length/PSIDを追加 (nat-anchorへ差し込む)
• WAN側IPv6インターフェースに CE-IPv6-addressを追加
  • 追加しないとgifで通信できない (BR側からCE-IPv4-addressとport番号内のPSIDから誘導されるCE-IPv6-addressへカプセル化されたパケットが送られてくる)
• IPv4 default routeにgif0を設定 (とりあえず、試験用の別fibで実装)

setfibして、fetch等でIPv4系にリクエストすると、IPv4 over IPv6(MAP-E)経由で降りてきた

ただし、手元の実験だとbind-addressオプションでLAN側のIPから発信しないとうまく通信出来ない？

どうやら起こっているのは、以下の状況の模様

• gifトンネルのこちら側に、CE-IPv4-addressを付ける - 送出時のソースにCE-IPv4-addressが選択され、natルールのfromマッチから漏れる変換されないので、MAP-Eの規約を満たしたsrc portが選択されない (戻りのパケットが別のCEへ送られる)
• gifトンネルにIPv4アドレスを付けない - 送出時のソースアドレスに0.0.0.0が選択され、natで変換されないケースでは戻り先が不明、変換されてもnatで逆変換した後の戻し先が分からない Orz

したがって、gifトンネルを保持するホストからIPv4 over IPv6 (MAP-E)で通信を行うには、下記の条件が必要

• gifトンネルのこちら側に、到達可能なIPv4アドレスを付ける必要がある (natで逆変換した戻りパケットがルーティング出来る)
• gifトンネルのこちら側に付けたIPv4アドレスは、natの変換対象でなければならない (MAP-Eではsrc portが制限されている)
  • CE-IPv4-addressを使う場合、natのfromマッチルールにinterface addressを追加する必要がある
    • ルール記述的にこちらの設定が素直
  • LAN内のprivate addressのaliasを割り付ける (nat動作的には、LAN側のnetworkからの通信と同様に処理できる)
    • このケースでは、natルールの定義でトンネル終端アドレスをインターフェース名で参照出来ない

CE-IPv4-addressをgifトンネルに張り付ける場合の、pf natルール (<lan-ip4>は、LAN内のアドレス集合)

nat on gif# from gif#:0 to any -> gif#:0 map-e-portset offset/length/PSID
nat on gif# from <lan-ip4> to any -> gif#:0 map-e-portset offset/length/PSID

実運用では、変換し損ねた内部アドレスが漏れないように、境界でのアドレスクラスフィルタリングを実施すること

運用上の考察

• IPv4のdefault gatewayをMAP-EとPPPoEの接続状況に応じて切り替える必要がある
  • 特にリンクダウン時の取扱いが必要
• 外部から着信したIPv4パケットを着信したリンクに送り返す必要がある
  • IPv4サービスを提供するPPPoE側から入ってくるパケットはPPPoE側に返す必要がある
  • pfのreply-toオプションで接続状態にリンクを含める or 外部着信サービスのFIBを切り替える
  • reply-toオプションベースなら、accept anchorにリンク固有の着信ルールを追加する？
• IPv4パケットに対するMAP-EトンネルのMTUは、IPv6トランスポート層があるので短くなるが、PPPoEのようにmpd側でTCP MSSが修正されない
  • 他のインターフェース経由のTCP通信を中継する場合には、MSSを修正する必要がある
  • gifトンネルのデフォルトMTUは、1280オクテットなのも注意 (適当な値に再設定することも要検討)
    • OCN MAP-E/IPv6 WAN MTU 1500の環境での実測だと、gif tunnel上のIPv4 MTUは1460オクテット(1500 - 40/IPv6ヘッダ)で理論通り
    • フレッツ網上のIPv4 PPPoEのMTU 1454より少し広い模様
• IPv6 WANインターフェースをproto ipencapなBR-CE間の通信が通過する
  • BR/CEアドレスは、gifトンネル側にあるが、pf.confのインターフェース名+修飾子ではgifトンネルのパラメータは参照出来ないので、ルールを記述するなら明示的にBR/CE IPv6アドレスを記述する必要がある
  • CE->BRの送信トラフィックに関しては、pass outな総括ルールがあれば、通信が続く限りkeep-stateされるはずなので、内側から外へ行くケースではあまり問題にならないはず
  • BR->CEの着信トラフィックを確実に受信するには、anchorへpass in quick on gif inet6 proro ipencap from BR to CEなルールを挿入すること

当面の作業目標

• anchorルールで、reply-toオプション付きのacceptルールを運用開始する(自動設定系を作る)
• PPPoEデーモン(mpd)からdefault routeの設定を分離して、linkup/down時に自前でdefault routeの追加・削除を行う
  • multi FIB構成をサポートする
  • 各FIBのdefault routeの設定状況・経路に応じて、default routeの更新を行うか否かを選択する機能を実装する
    • 例えば、gif側(MAP-E)がdefault routeの際にはdefault routeを更新しないなど