それでもDLNAをロケーションフリー化する方法 part2
手順
DLNAをロケフリ化する、
つまりルータを超えて外部のネットワークからDLNA機器を利用するには、
DLNAがLAN内で動く仕組みを解析し、
ルーターのWAN側でも同様にパケットが流れるように、
ルーターを設定してやればOK。
（言うは易し、なんだけど）
DLNAの仕組み
DLNAは、
デジタル家電（テレビやレコーダー）がシームレスにつながるために、
独自のプロトコルを作るのではなく、
既存のプロトコルや規格（UPnPやCODEC）の組み合わせを指定している規定集のようなもの。
そしてHTTPベースなので、ウェブで扱いやすい。
DLNA機器の認証手順
UPnP(Universal Plug and Play)のDA（Device Arvchitecture）という規格で、
サーバとクライアントがつながるようになっている。
UPnP DAでは、SSDP（Simply Discovery Protocol)というプロトコルで
239.255.255.250へUDP 1900番ポートのマルチキャストパケットを投げる。
その後、返答が帰ってきたIPアドレスとMACアドレスを
交換する、っぽい。
なぜ「っぽい」か？
DLNAの詳細仕様は、業界団体のメンバーでないと分からないブラックボックス仕様のため、
流れているパケットからの推測（とネットに公開されてるの論文）に過ぎない。
VPNの構築
というわけで、DLNAをロケフリ化するためには、
まずVPNを構築し、
そしてマルチキャストパケットを中継してやれば良いはず。
より厳密には、
IPSecで２拠点のVPNを貼り、
IGMPプロクシでマルチキャストパケットを中継してやれば
動くはず。
動くルーター、動かないルーター
ネット上では、IPSec+IGMPプロクシでDLNAが動いたという
情報があったが、
私が試したIX2015では動かなかった。
参考：
(OFFLINE) Community Message
設定が悪いのかもしれない。
あるいはIGMPプロクシの動作原理が、
ルーターによって異なるそうなので、
DLNA機器との相性かもしれない。
IX2015でも、DLNA機器からのSSDPパケットが流れてきたのは確認できたが、
DLNAサーバを見つけることはできなかった。
DLNAの仕様が公開されてないため、
真偽は不明だが、
「DLNAは同一セグメントに限る」という記述もよく目にする。
もし真実なら、192.168.1.xxと192.168.2.xxのようにセグメントが異なると、
ダメなわけで、IX2015のIPSec+IGMPの組み合わせでは動かないことになる。
はたまたDLNA機器によって、微妙に動作が異なるのかもしれない。
ともかく、動きませんでした、ちゅーこと。
EtherIPなら確実にDLNAが動く
でも心配ご無用。
マルチキャストパケット云々は、
OSI参照モデルのL３層（ネットワーク層）のこと。
だけど、より上位のL2層（データリンク層）をVPNでつなぐ
EtherIPなら無問題！
OSI参照モデルのことは、正直全然分からないけど、
ともかくL2層なら動くらしい。
L2-VPNの規格はEtherIPのほかに、L2TPもメジャーっぽい。
お手軽なところでは、SoftEtherとかUT-VPN,Packetive-ether,
広域イーサネクスト等（あれ？全部同じ開発者だぞ）
設定方法
幸いIX2000/3000シリーズは設定事例集が豊富なので、
VPN初心者でもなんとか設定できた。
ごく普通に設定すれば動くはずなので、
設定は省略
参考サイト
機器は見つかったけど、再生ができない場合
はい、ハマリました！
今、あなたDLNAの深みに完全にハマっちゃいました。
DLNAで再生できないコンテンツがある理由
地上デジタル放送等では、著作権保護のため
DTCP-IPという暗号化がされています。
DTCP-IPのライセンス認証された機器（大手家電メーカーのものなら大抵認証済み、一部液晶モニタ等では認証されない可能性あり）では、
DLNAはDTCP-IPで暗号化されたファイルを再生することができますが、
TTLが３以下、
RTTが7msec以内という制限があります。
つまり、ルーター（ブリッジやハブも含まれるかも）は２段まで、
パケットの往復遅延は7msec以内。
RTTが7msec以内の壁
VPNを使えば、TTLの制限はクリアできるものの、
遅延を抑えることはできません。
WimaxやLTEのような次世代通信でも、
無線の遅延が大きいのでアウト。
ADSLや光ファイバーのような有線でも、
２拠点の物理的距離が近く、
遅延の少ないプロバイダを選ぶ必要があります。
あまりに冷徹で、厳しい規制に思わず「ですます」調になってしまいましたわ。
ネットワークの遅延を減らす方法
プロバイダを変えると、5msecくらいは早くなった（経験談）。
東京ー大阪でpingを打って
18〜20msecだったのが、
プロバイダを変えたら14〜16msecに。
ちなみに、
20msecと遅かったのはBIGLOBE同士の場合。
一見同じプロバイダにしたほうが早そうなのに、
遅いのがBIGLOBEクオリティ。
RTTの理論値と限界
プロバイダに起因する遅延もあるとはいえ、
２拠点の物理的距離が離れていればいるほど、
信号がたどる距離が長くなるわけで、
パケットの遅延も大きくなる。
バックボーンは光ファイバなので、
光速で計算すれば、東京-大阪間で2msec以下、と思いがちだが、
実際には光ファイバーのなかを屈折して進み、
さらに中継機器もあるので、
なにをどうやっても東京-大阪間で10msecを切ることはできないようだ。
参考
http://d.hatena.ne.jp/kawango/20110107
http://www.pc-blend.com/internet.html
ひとまず結論
遅延を短くする方法
では、ネットワークの遅延を短くする方法はないのか？
ISDNやADSLならより高速な回線にすることがあげられる。
それでもダメな場合でも、
フレッツ光ならIPv6でプロバイダを経由しない通信ができる場合がある。
フレッツ・v6オプションなら低遅延
2011年８月に開始された
「フレッツv6オプション」を使うと、
フレッツ光の端末間通信を、NGN内（フレッツ網）で
折り返し通信ができるようになる。
NGNの折り返し通信ができると、
それまでISP（プロパイダ）をいちいち介していたのが、
不要になり、
無駄な経路が減るのでパケット遅延の大幅な改善見込まれる。
もちろん通信速度の高速化する。
こんないいことづくめのオプションをいままで使えなかったのは、
IPv4の枯渇という建前になっているが、
そんなのはずっと以前から分かっていた。
むしろソフトバンクが光の道構想で
NTTにちょっかい出したから、
NTTも重い腰を動かしたのじゃないだろうか。
ありがとう孫正義。
フレッツv6オプションでVPNを構築する
NGNはIPv6なので、
VPNもIPv6に対応したものである必要がある。
DLNAはIPv4なので、
IPv6のEtherIP（L2層VPN）で、
IPv4overIPv6モードで通信をすれば良い。
IPv4overIPv6は、IPv4のパケットをカプセル化して、IPv6パケットとして流す方式。
胃で溶けずに腸で効く薬のようなもの。
IX2000/3000シリーズはEtherIPのIPv4overIPv6にも対応。
ただし未検証。
なぜかって？
もっとカンタンな方法があるからさ。
IPv6 IPoE接続でVPNを構築
つい先日解禁されたばかりのIPv6 IPoE接続。
それまではNGNで折り返し通信のできないIPv6 PPPoE接続しか
サービスが提供されてなかった。
そんなわけで、設定マニュアルの情報も少なく、
初心者にはお手上げ。
第一、IPv4overIPv6のEtherIPトンネリングで、
DLNAに必要なパケットがすべて伝達されるのかも、
実際やってみないと分からない。
広域イーサネクストでフレッツ光 IPoEのL2層VPN
広域イーサネクストというソフトを使うと、
フレッツ光回線対向なら、カンタンにVPNが構築できるらしい。
HPの記述はDLNA対応も謳っており、
NTTの交換局の経路すら最適化するなど眉唾な記述もあるが、
ものは試し。
次の記事では、実際に試してみたいと思う。
広域イーサネクストのトピック
詳細は次回に譲るが、
結論からいえば、繋がらなかった。
原因はONUとルータが一体型になっており、
IPv6パケットのフィルタ設定がうまく動かないからだと思われる。
それと、広域イーサネクストのウェブサイトでは、
NTT西日本では「IPoE接続対応プロバイダの契約が必須」となっているが、
これは誤り。
NTTの当初の発表では必須だったが、現在はＮＴＴ東日本同様、
プロバイダ契約なしで、オプションのみ申し込める。
ただし、NTTの東西をまたぐ場合は、やはりIPoE対応プロバイダの契約が必要になる。
東日本NGN--プロバイダ回線--西日本NGNという流れになるため。
東西のNGNは基本的に独立している。
特定のポートは開いているという情報もあるが、
速度は出ない模様。
基本的には高額なVPNオプションが必要になってしまい、本末転倒。
