NGN を利用しながらIPv4通信するサービス機能です

どういうこと？

　前提知識として、NGN と呼ばれるフレッツが提供するネットワークは、IPv6通信プロトコルによるIPoE方式を採用しています。
　簡単に言えば、IPv4パケットは流れません。
　それでは、現状レガシー染みた雰囲気を帯びたIPv4のみでサービスしているウェブサイトやメールサーバなどを利用できなくなります。
　当然、大混乱とブーイングの嵐になります。

　そこで、IPv6 IPoE のネットワークにパケットを流し込む時に、IPv4パケットをIPv6パケットにカプセル化（IPv4パケットをIPv6パケットに変換）して流す作業が成されます。
　これでIPv6 IPoE ネットワークへパケットを流す事は出来ますが、では？そのパケットは、何処を宛先にするのでしょうか？
　この宛先がVNE 事業者が提供する設備です。　有名な所だとJPNE社で、IPv4パケットを含んだIPv6パケットを受け取ると、それを梱包を解いて実際の宛先に向けてIPv4パケットを流す事になります。
　その際に差出元となるIPv4アドレスをVNE 設備が割り付けて宛先のIPv4アドレスへ送出する仕組みとなっているようです。
　結果、IPv4通信が実現されるのですが、この時に割り当てるIPv4アドレスは、複数の利用者がIPv4アドレスを共有するためにNAT 利用が困難化する事になるそうです。

　色々書きましたが、俯瞰的に観るとNGN がIPoEを採用するという事は、ボトルネックとなっていたPPPoE設備をVNE 事業者が提供する形態（設計）になっている姿になっており、 実際にもVNE 事業者との間は、PPPoE によるIPv4トンネルインターフェースになっている模様です。

で？ 何で内のプロバイダだとIPv4通信が内側でNATを挟むと通信できないの？

　不思議な症状に遭遇しています。

　［Node］→［HGW］→PPPoE→［VNE］→IPv4網→［Server］
　この構成だとNodeからServerまでIPv4通信が可能です。

　［Node］→［NAT-Router（FreeBSD NAT:pf）］→［HGW］→PPPoE→［VNE］→IPv4網→［Server］
　この構成だとTcpdump によればTCP のAck が返送されてきません。
　しかしicmp4 ping はパケットが返送されてくる不思議な症状が生じています。

よし。ではクラウド側からみたパケットを確認しようか

　と、言うわけで、最近は一家に一台、一人一つのVPS が基本となり、いつでも思い立った時にVPS でサーバ構築するのが常識となりました。（誇大妄想）
　50分くらい掛けて、Azure にVMを立てて、検証環境を構築して実験しました。　本当に構築自体は、かなり簡単でした。（事実：個人的感想です）

【実験結果】TCP コネクションが確立されてhttpリクエストが通りましたよ…。

　？？？・？？・・・・・・・・・・・・・・・・・！？

　通った。。。通ったよ。。。
　どういうことだ！

【検証中の経過観察】

　気持ちを落ち着けるために、状況を整理します。

  1. Apche24をインストール
    2. →　「pkg install apache24」で何事もなくクリア。　手順にconnect()できなくする余地は、見当たらない。
  2. Apache24のコンフィグレーション
    3. →　ほぼデフォルト。　サーバアクセスにおいてhttpにおいて表示するサーバ名しか変更していない。　connect()不能要因は、見当たらない。
  3. 取り敢えず、pingを飛ばす
    4. →　通らない。　取り敢えず、無視してhttpレイヤで実験
  4. httpを飛ばす
    5. →　通らない。　ここまでは期待通り。　しかしpingが通らない点が現状と矛盾する。
  5. ウェブコンソールからファイアウォール規則を追加（まずはicmp）
    6. →　pingが通らない。　F/W規則、適用されてなくね？
    →　ウェブコンソールだとルール追加の後にnic に反映するステップが存在した。　規則を適用。
    →　pingが通る。　「ファイアウォール規則が原因」だった。
  6. ウェブコンソールからファイアウォール規則を追加（次にhttp）
    7. →　え…？　通った。。。　ああ。プロキシ経由で繋いだのか。（ほっ、よかった）
  7. プロキシを不活性に切替。　httpリクエストをリトライ
    8. →　…？　通る。　ああ。キャッシュされていてリクエストが届いてない。　クラウド側のtcpdump に表示ないしね（…）
  8. プロキシ停止。　ブラウザ再起動。　リトライ
    9. →　…通った。　what?
    →　netstatで確認。　宛先とローカルを結ぶコネクションの状態が「TIMEWAIT」（SYN_SENTではない）。
    　ブラウザにはキチンとサーバに設置したhtmlが表示されている…。

実験結果を省みた結論

　biglobeのメールサーバは、VNE 設備の中にあるんじゃね？

　と、お茶を濁した惚けた事を書きましたが、実際の所は、二重にNAT されている場合は、 パケットループを防ぐ為に二重のNAT にあることを検査してVNE 設備側で弾いているのだろうと推測します。
　こういうNAT 構成だと、やろうと思えば、TTLを最大値近くに設定してIPv4パケットをループさせることでネットワークを飽和させることが可能と思われるからです。
　自分自身の宛先に対してICMPv4でpingなりudp なりを飛ばした場合、パケットループを検出しにくいように見えます。
　これは、IPoE 環境下で、static NAT している宛先にping やIPv4 パケットを飛ばし、それが二重NAT の内側では、単純にパケットをリレーするようにしていたらどうなるでしょうか？
　恐らくは、そういう事だと推測します。

　終わり。