spec.md

IPv6マイグレーション技術の国内標準プロビジョニング方式 【第1.1版】

IPv6普及・高度化推進協議会 IPv4/IPv6共存WG IPv6家庭用ルータSWG

Copyright (c) IPv6普及・高度化推進協議会
本文書はクリエイティブ・コモンズの 「表示 4.0 国際 (CC BY 4.0)」 により利用が許諾される。

変更履歴

• 1.0版 (2020年8月13日)
  • 初版発行
• 1.1版 (2021年10月7日)
  • 本方式の名称を規定した、サーバ応答の記述の明確化など、細部を修正した。

目次

• 1 本文書作成の背景と目的
  • 1.1 要求度を表す用語
  • 1.2 用語集
  • 1.3 本文書で規定する方式の名称とバージョン
• 2 ネットワーク構成
  • 2.1 VNE にて必要となる設備
• 3 プロビジョニング方式仕様
  • 3.1 プロビジョニングサーバの発見方法
  • 3.2 プロビジョニングサーバへの接続手段
  • 3.3 データフォーマット（プロビジョニングサーバへ送信）
  • 3.4 データフォーマット（プロビジョニングサーバから受信）
  • 3.5 プロビジョニングデータの管理
  • 3.6 プロビジョニングサーバへのアクセスシーケンス
• 4 検討メンバー

1. 本文書作成の背景と目的

日本国内において、NTT 東西によるフレッツ光ネクストの NGN IPv6 契約者数は、1,800 万契約を超過しており、NGN IPv6 普及率も 80% を超える状況となっており、IPv6 サービスの本格的な普及が進んでいる。(2021年10月時点)

IPv6 サービスの普及と同時に、各 VNE 事業者による IPv6 マイグレーション技術を使用した IPv4 over IPv6 サービスの普及が加速しているが、各 VNE 事業者が採用している IPv6 マイグレーション技術およびプロビジョニング方式が各社独自となっている為、今後、新規に IPv4 over IPv6 サービスを提供予定の VNE 事業者においても、独自方式で提供される可能性が高く、各社が独自方式を採用することによる問題が懸念される。

具体的には、家庭用ルータベンダにおいて、VNE 各社独自のプロビジョニング方式を搭載することによるサービス自動判別機能の複雑化や、開発工数・評価工数の増大による製品価格への転嫁などが想定され、エンドユーザによる間接的なコスト負担が懸念される。

本文書は、上記問題を解決することを目的として、国内標準のプロビジョニング方式の仕様を策定したものであり、特に新規 VNE 事業者に対して当該標準方式の採用を期待するものである。尚、既にサービス提供中の VNE 事業者においては、国内標準方式へ移行する上での得失を考慮した上で判断いただければ幸いである。

本国内標準方式の適用範囲は、フレッツ光ネクストに限定するものではなく、CATV ネットワークや他の通信事業者のサービスへの適用が可能なものとなっている。 尚、本国内標準方式を、国際標準として提案するか否かについては、今後の検討事項である。

本国内標準方式が、家庭用ルータベンダの製品に標準搭載され、かつ新規 VNE 事業者におけるプロビジョニング方式となるよう当該 SWG として普及啓発のための活動を行う。

1.1. 要求度を表す用語

本文書では "MUST", "SHOULD", "MAY" の単語を用いて、記述の要求度を定める。 各単語の意味は RFC2119 に従う。

• MUST : 必須。必ず必要とされる機能。
• SHOULD : 推奨。実装されることが推奨される機能。ただし、特定の状況下において妥当な理由が存在する場合は実装しないことが許容される。
• MAY : オプション。実装は付加価値的なものであるため任意でよい機能。

1.2. 用語集

• CPE
  • 本文書で規定するプロビジョニング方式を実装したルータ
• プロビジョニングサーバ
  • CPE からの要求に基づき本文書で規定する各種パラメータを応答する HTTP または HTTPS サーバ
• プロビジョニング方式対応 DNS サーバ
  • CPE が参照するフルサービスリゾルバであり、本文書で規定する専用ドメイン名に対する TXT リソースレコードの問い合わせに対し、本文書で規定するフォーマットで記述された TXT リソースレコードを返す DNS サーバ

1.3. 本文書で規定する方式の名称とバージョン

本文書で規定する方式の名称は HB46PP (HTTP-Based IPv4 over IPv6 Provisioning Protocol) とする。将来の改版に備えて方式のバージョンを明記する場合には、本文書で規定する方式をバージョン "1" とする。バージョンは整数値で表し、仕様の互換性が失われる変更を加える場合に増加させる。

2. ネットワーク構成

全体概念図

                             +----------+
                             |DNS Server|
                             +-----+----+
                                   |
                                .--+--.                        .-----.
                               /       \     +----------+     /       \
      .-----.     +-------+   /  IPv6-  \    | Center   |    /  IPv4-  \
     / Local \    |       +--(  Network  )---+ Equipment|---(  Internet )
    /         \   |  CPE  |   \         /    +----------+    \         /
   (   Home-   )--+       |    \       /                      \       /
    \ Network /   +-------+     --+---'                        ---+--'
     \       /                     |
      `-----'               +------+-----+
                            |Provisioning|
                            |   Server   |
                            +------------+

シーケンス(概要)

                      DNS   プロビジョニング
    CPE              サーバ     サーバ           センタ装置      IPv4ノード
    |                  |         |                |               |
    | プロビサーバ発見    |         |                |               |
    |=================>|         |                |               |
    |                  |         |                |               |
    |    プロビサーバ応答 |         |                |               |
    |<=================|         |                |               |
    |                  |         |                |               |
    | パラメータ要求     |         |                |               |
    |===========================>|                |               |
    |                  |         |                |               |
    |               パラメータ応答 |                |               |
    |<===========================|                |               |
    |                  |         |                |               |
    |             IPv4 over IPv6 通信              |   IPv4 通信   |
    |<===========================================>|<=============>|
    |                  |         |                |               |
    |                  |         |                |               |

2.1. VNE にて必要となる設備

• DNS キャッシュサーバ (特定 FQDN のリソースレコードに対する DNS 設定)
• 本方式に準拠したプロビジョニングサーバ (http or https)
• IPv4 over IPv6 センタ装置 (IPv6 マイグレーション技術対応)

3. プロビジョニング方式仕様

3.1. プロビジョニングサーバの発見方法

プロビジョニングサーバの発見は以下 FQDN に対する DNS の名前解決にて行う。

4over6.info

プロビジョニングサーバの URL とサポートする接続方式を TXT リソースレコードにより取得する。 TXT リソースレコードにおけるフォーマットは下記の通りとし(両端の二重引用符は含まない)、複数記述はせず単一の応答のみを返すこととする。

"v=v6mig-1 url=https://vne.example.jp/rule.cgi t=b"

各項目については下記の通り。

• v : バージョンを示す。v6mig-1 を固定値とする。
• url : プロビジョニングサーバの URL を示す。
• t : 証明書検証の要否を示す。
  • a : 証明書検証を行わない。
    • url の scheme が http の場合は t=a とすること(MUST)
  • b : 証明書検証を行う。

3.2. プロビジョニングサーバへの接続手段

プロビジョニングサーバへの接続手段は、VNE 事業者にて以下の中から選択可能である。

• a) http を利用する。
• b) https を利用するが、証明書検証を行わない。
• c) https を利用し、自己署名のサーバ証明書を使用する。
• d) https を利用し、認証局発行のサーバ証明書を使用する。

https を利用する場合は、TLS の server_name 拡張(SNI)を用いてサーバ名を通知すること(SHOULD)。

各々の接続手段におけるメリット、デメリットを以下に示す。

• a) http
  • メリット
    1. サーバ証明書が不要
  • デメリット
    1. 通信内容が暗号化されないため、通信内容を容易に解読することが可能。
  • 備考
    • 有効だが、安全性の検討が必要。
    • ※公開情報を配布するのであれば考慮不要。
• b) https 自己署名のサーバ証明書を使用 ※証明書検証を行わない
  • メリット
    1. サーバ証明書の管理は不要
    2. 通信内容が暗号化される。
  • デメリット
    1. サーバ証明書をクライアント側で検証できない。
    2. サーバのなりすまし防止ができない為、送信情報が解読される可能性あり。
  • 備考
    • 運用コストが低い。
• c) https 自己署名のサーバ証明書を使用 ※証明書検証を行う
  • メリット
    1. 通信内容が暗号化される。
    2. サーバ証明書をクライアント側で検証可能。
    3. サーバのなりすまし防止が可能。
  • デメリット
    1. サーバ証明書の管理(有効期限)が必要。
    2. クライアント側に CA 証明書が必要。※ CPE で証明書を保持する必要あり。
  • 備考
    • 安全性は確保できるが危殆化のリスクあり。各社の CA 証明書の管理コスト発生。
• d) https 認証局発行のサーバ証明書を使用
  • メリット
    1. 通信内容が暗号化される。
    2. サーバ証明書をクライアント側で検証可能。
    3. サーバのなりすまし防止が可能。
  • デメリット
    1. サーバ証明書の管理(有効期限、費用等)が必要。
    2. クライアント側にCA証明書が必要。
  • 備考
    • 理想的だが、運用上の課題(運用によってはサービス停止リスク)がある。
    • サーバ証明書をクライアント側でチェックしない場合、自己署名のサーバ証明書使用と同様のデメリットあり。

3.3. データフォーマット（プロビジョニングサーバへ送信）

プロビジョニングサーバへのプロビジョニング情報要求は、HTTP/HTTPS リクエストの GET メソッドを用いてリクエストを行う。 クライアントは、プロビジョニングサーバに IPv6 でアクセスすること(MUST)。

※送信タイミングについては、「プロビジョニングサーバへのアクセスシーケンス」を参照。

GET /config?<パラメータ名>=<値>&<パラメータ名>=<値>&... HTTP/1.1

リクエストを行う際、以下の情報をパラメータとして付与し、CPE からプロビジョニングサーバへ送信する。 なお、プロビジョニングサーバは未知のパラメータをエラーとせず、無視すること。

• vendorid
  • ベンダーOUI、および、任意コード24文字を以下のフォーマットで送信する(MUST)。
    • 「ベンダーOUI(16進数表記6文字)」＋「-」＋「任意文字(0-9,a-z,A-Z,_のみ)最大24文字」
  • ベンダーOUIのみをMUSTとし、ハイフン以降の値の付与は任意とする。
  • ex) vendorid=acde48-v6pc_swg_hgw
• product
  • CPE 本体の製品名を値として送信する(MUST)。
  • 値は ASCII 半角英数字、ハイフン、アンダースコアで構成される 32 文字以下とする。
  • ex) product=V6MIG-ROUTER
• version
  • CPE のファームウェアバージョンを送信する(MUST)。
  • 値は、数字またはアンダースコアからなる最大 32 文字の文字列とする ([0-9_]{1,32})。
    • ピリオドの代わりにアンダースコアを利用すること。
  • ex) version=1_32
• capability
  • CPE のサポートするマイグレーション技術を送信する(MUST)。
  • サポートする以下のマイグレーション技術を , で接続した文字列を送信する。
    • 464xlat CPE は 464XLAT をサポートする。
    • dslite CPE は DS-Lite をサポートする。
    • ipip CPE は IPIP トンネル接続をサポートする。
    • lw4o6 CPE は Lightweight 4over6 をサポートする。
    • map_e CPE は MAP-E をサポートする。
    • map_t CPE は MAP-T をサポートする。
    • hubspoke CPE は MAP-E の Hub&Spoke 方式をサポートする。
    • mesh CPE は MAP-E の MESH 方式をサポートする。
  • ex) capability=map_e,dslite,lw4o6,hubspoke
• token
  • CPE が過去にプロビジョニングサーバに接続したことがあり、その際にプロビジョニング情報の一部として token を取得している場合、CPE はその token の値をリクエストパラメータとして送信することが望ましい(MAY)。
  • サーバは token の値を CPE の識別に利用する。
  • 詳細については 3.4 節の token パラメータの説明を参照すること。
• user
  • サーバが CPE の認証を行う場合のユーザ名。
  • 値は ASCII 半角英数字、ハイフン、アンダースコアで構成される 32 文字以下とする。
  • CPE は、user と pass の設定インタフェースを持つ場合、プロビジョニングサーバのサーバ名も入力できるようにすること(SHOULD)。
  • CPE は、user, pass と同時にサーバ名が入力された場合は、プロビジョニングサーバとの接続方法が https であり、かつサーバ証明書の検証を行った場合で (t=b)、かつ url に指定されたサーバ名がユーザが入力したサーバ名と一致した場合にのみ user, pass を送ること。 それ以外の場合にはその user, pass を送信してはならない(MUST NOT)。
  • CPE は、user, pass と同時にサーバ名が入力されなかった場合は、任意のリクエストにおいて user, pass を送信して良い。
• pass
  • サーバが CPE の認証を行う場合のパスワード。
  • user を送信する場合は pass も送らなければならない(MUST)。 user を送信しない場合は pass を送ってはならない(MUST NOT)。
  • 値は ASCII 半角英数字、ハイフン、アンダースコアで構成される 32 文字以下とする。

プロビジョニングサーバは、リクエストに応じて以下の応答を返す。

• リクエストを受理する場合はステータスコード 200 で応答し、3.4 節で規定する JSON データを返す。
• リクエストを他のサーバに転送する場合は、ステータスコード 307 で応答し、Location ヘッダにて次サーバを指示する。
• リクエストの送信元 IP アドレスが未知のものである場合は、ステータスコード 403 もしくは 404 で応答する。
• リクエストの送信元 IP アドレスからプロビジョニング情報の提供範囲外と判断され、かつ token による認証に成功しない場合は、order: [] として利用可能な接続方式が無いことを通知する。
• user/pass による認証に失敗し、そのためにクライアントに提供すべき接続方式が無いと判断される場合は、order: [] として通知する。
• その他、クライアントに提供すべき接続方式が無いと判断される場合は、order: [] として通知する。

CPE は、200 と 307 以外の HTTP ステータスコードをエラーとして扱って良い。

3.4. データフォーマット（プロビジョニングサーバから受信）

プロビジョニング情報を格納するデータフォーマットは、RFC7598 にて定義されているフォーマットをベースとした JSON フォーマットとし、不足するパラメータ等については独自に追加を行っている。JSON フォーマットの仕様は RFC8259 に従う。

CPE は、JSON オブジェクトの未知のキーは無視してよい(MAY)。

以下にデータフォーマットを示す。

{
  "enabler_name": "A VNE",
  "service_name": "Highspeed 4over6",
  "isp_name": "ISP-A",
  "ttl": 86400,
  "token": "640756965820d3b9025b6941f9590af6802830ba58663fe8f043dc92b576f17a",
  "auth": "ok",
  "order": [ "464xlat", "map_e", "dslite" ],
  "map_e": {
    "version": 0,
    "mesh": true,
    "br": "2001:db8:1::1",
    "rules": [
      {
        "ipv6": "2001:db8:1:2000::/52",
        "ipv4": "203.0.113.0/24",
        "ea_length": 12,
        "psid_offset": 4
      }
    ]
  },
  "dslite": {
    "aftr": "aftr.example.net"
  },
  "lw4o6": {
    "lwaftr": "lwaftr.example.net",
    "ipv6": "2001:db8:3:100::/56",
    "ipv4": "203.0.113.16",
    "psid": 3,
    "psid_length": 8,
    "psid_offset": 6
  },
  "map_t": {
    "dmr": "2001:db8:5::/64",
    "rules": [
      {
        "ipv6": "2001:db8:5:100::/56",
        "ipv4": "203.0.113.32/28",
        "ea_length": 8,
        "psid_offset": 4
      }
    ]
  },
  "464xlat": {
    "nat64prefix": "2001:db8:6::/96"
  },
  "ipip": [
    {
      "ipv6_local": "2001:db8:7:100::7",
      "ipv6_remote": "2001:db8:7::1",
      "ipv4": "203.0.113.0/29"
    }
  ]
}

Object Value

• enabler_name
  • NGN 上でのサービスでは VNE 名
    • JPNE, IMF, NTTコミュニケーションズ, BIGLOBE等
  • NGN 以外でのサービスでは ISP 名
    • au、J-COM等
  • 両端の " を含めて 256 バイト以下の文字列である。
• service_name
  • IPv4 over IPv6 VNE サービス名
  • VNE が指定のサービス名を設定する。
  • NGN 以外でのサービスの場合は、設定しないこと。
  • 両端の " を含めて 256 バイト以下の文字列である。
• isp_name (オプション)
  • IPv4 over IPv6 ISP サービス名
  • service_name < isp_name の関係にすること。
  • 両端の " を含めて 256 バイト以下の文字列である。
• ttl
  • プロビジョニング情報の有効期間。単位は秒。
  • 値は 604800 (7日間)以下でなければならない(MUST)。
• token (オプション)
  • サーバが CPE を識別するためのトークン。
  • token を受け取った CPE は、次回以降のリクエストにおいて token パラメータを送信することが期待される(3.3節参照)。
  • 値は 256 ビット整数を数字と英小文字からなる 16 進数で表した 64 文字の文字列とする。
• auth (オプション)
  • user/pass による認証の結果を表す。
    • (値なし)
      • サーバは user/pass による認証を期待していない。
    • req
      • リクエストに user/pass が含まれていなかったが、user/pass を送信することでサーバは追加のパラメータを返す可能性がある。
    • bad
      • リクエストに user/pass が含まれていたが、認証に失敗した。
    • ok
      • リクエストに user/pass が含まれており、認証に成功した。
• order
  • マイグレーション方式を優先度順に並べたもの。プロビジョニングデータに複数の方式が記述されている場合、CPE は order に記述された順序で各方式の利用を試みる。
  • マイグレーション方式には以下の文字列のいずれかを指定する。
    • 464xlat, dslite, ipip, lw4o6, map_e, map_t
  • なお、CPE は、order の設定によらずユーザが固定的に設定できるモードを備えることが望ましい。
• map_e (オプション)
  • MAP-E プロトコルのパラメータ。
• map_e / version (オプション)
  • MAP-E プロトコルのバージョン。
    • 0 or 項目なし : draft-ietf-softwire-map-03
    • 1 : RFC7597
  • 省略した場合は 0 を意味する。
• map_e / mesh (オプション)
  • RFC7597 に記載の MAP-E の Hub-and-spoke モードと Mesh モードを指定する。
    • 0 or 項目なし : Hub-and-spoke mode (CE - BR only)
    • 1 : Mesh mode (CE - BR and CE - CE)
• map_e / br
  • BR の IPv6 アドレス。
• map_e / rules
  • MAP-E のルールを表す。
  • Hub-and-spoke/Mesh モード時ともに、フォーマットとしては 256 ルールを受け入れること(MUST)。
  • Hub-Spoke モード時は、ルールの最大数は 256 ルールを受け入れること(MUST)。
  • 動作要件として、Mesh モード時は 256 ルールで動作すること(SHOULD)。
• map_e / rules / ipv6
  • FMR の IPv6 プリフィックス
• map_e / rules / ipv4
  • FMR の IPv4 プリフィックス
• map_e / rules / ea_length
  • EA ビット長
• map_e / rules / psid_offset
  • PSID オフセット
• dslite (オプション)
  • DS-Lite プロトコルのパラメータ。
• dslite / aftr
  • AFTR の DNS 名もしくは IPv6 アドレス。
• lw4o6 (オプション)
  • Lightweight 4over6 プロトコルのパラメータ。
• lw4o6 / lwaftr
  • lwAFTR の DNS 名もしくは IPv6 アドレス。
• lw4o6 / ipv6
  • Operator Assigned IPv6 Prefix
• lw4o6 / ipv4
  • IPv4 external (public) address for NAPT44
• lw4o6 / psid
  • Restricted port set to use for NAPT44
• lw4o6 / psid_length
  • PSID のビット長
• lw4o6 / psid_offset
  • PSID オフセット値
• map_t (オプション)
  • MAP-T プロトコルのパラメータ。
• map_t / dmr
  • DMR のアドレス
• map_t / rules
  • MAP-T のルール。
  • 最大数は 200 ルール。
• map_t / rules / ipv6
  • FMR の IPv6 プリフィックス
• map_t / rules / ipv4
  • FMR の IPv4 プリフィックス
• map_t / rules / ea_length
  • EAビット長
• map_t / rules / psid_offset
  • PSID オフセット
• 464xlat (オプション)
  • 464XLAT プロトコルのパラメータ。
• 464xlat / nat64prefix
  • NAT64 プリフィックス。
• ipip (オプション)
  • RFC2473 IPIP トンネルに関するパラメータ。
• ipip / ipv6_local
  • IPIP トンネルの CPE 側 IPv6 アドレス。
• ipip / ipv6_remote
  • IPIP トンネルのプロバイダ側 IPv6 アドレス。
• ipip / ipv4
  • IPIP トンネルの IPv4 固定アドレスとそのプリフィックス長。

3.5. プロビジョニングデータの管理

プロビジョニングサーバから正常に取得した各種パラメータ情報について、当該 CPE に必要な情報を不揮発領域に格納することができる(MAY)。 サーバ障害時などプロビサーバへの到達性が無い場合に、不揮発領域に格納されている情報を使う(MAY)。 この機能を持つ CPE は、不具合発生時に備えて、格納された情報を不揮発領域から消去する手段を備える(SHOULD)。

3.6. プロビジョニングサーバへのアクセスシーケンス

以下にプロビジョニングサーバへのアクセスシーケンスおよび状態遷移を示す。

• a) 開始
• b) DNS クエリーで TXT リソースレコードの情報を取得する
• c) プロビジョニングサーバのアドレスと通信方式が取得できたか
  • c.1) 取得できた場合
    • d) へ
  • c.2) NODATA もしくは NXDOMAIN で取得できなかった場合
    • CPE にマイグレ技術が動作している場合、機能を無効にする
    • 1-3 時間のランダムな時間を待つ
    • a) へ
  • c.3) NODATA もしくは NXDOAIN 以外の理由で取得できなかった場合
    • 1-10分のランダムな時間を待つ
    • a) へ
• d) プロビジョニングサーバへ CPE 情報を送信する
• e) プロビジョニングサーバから情報を取得する
• f) プロビジョニングサーバから返答があったか
  • f.1) 返答がある場合
    • g) へ
  • f.2) 返答がない場合
    • 10-30 分間のランダムな時間を待つ
    • a) へ
• g) プロビジョニング情報を解析する
• h) ステータス確認をする
  • h.1) 有効なプロビジョニングデータの場合
    • i) へ
  • h.2) エラーの場合
    • 10-30 分間のランダムな時間を待つ
    • a) へ
• i) 以前にマイグレ技術が設定されて有効か
  • i.1) 有効な場合
    • 以前の設定から変更があれば j) へ
    • 以前の設定から変更がなければ k) へ
  • i.2) 無効な場合
    • j) へ
• j) プロビジョニングデータに合わせて、CPE を設定する
• k) プロビジョニングデータに TTL が設定されているか
  • k.1) 設定されている場合
    • TTL で指定された時間が経過するか、もしくは自身の IPv6 アドレスの変化を検出するまで待つ
    • a) へ
  • k.2) 設定されていない場合
    • 20-24 時間が経過するか、もしくは自身の IPv6 アドレスの変化を検出するまで待つ
    • a) へ

プロビジョニングサーバは、CPE の IPv6 アドレスに応じてプロビジョニングデータの内容を変化させる場合がある。そのため、CPE は自身の IPv6 アドレスの変化を検出した際には、プロビジョニングデータを再取得すること(SHOULD)。

4. 検討メンバー

下記に検討メンバーを示す。所属の50音順に従っている。

• エヌ・ティ・ティ・コミュニケーションズ株式会社 藤崎 智宏（部会長）
• ＮＥＣプラットフォームズ株式会社 川島 正伸（部会長）
• 株式会社インターネットイニシアティブ 佐原 具幸（部会長）
• 株式会社アイ・オー・データ機器 田畑 敬司
• 株式会社アイ・オー・データ機器 吉田 幸男
• 株式会社朝日ネット 押川 眞一郎
• 株式会社朝日ネット 関本 義久
• 株式会社朝日ネット 村山 昌平
• インターネットマルチフィード株式会社 津辻 文亮
• インターネットマルチフィード株式会社 川口 慎司
• ＮＥＣプラットフォームズ株式会社 大石 智雄
• ＮＥＣプラットフォームズ株式会社 前田 康貴
• ＮＥＣプラットフォームズ株式会社 中村 敏夫
• ＮＥＣプラットフォームズ株式会社 平野 郁也
• エレコム株式会社 島田 純平
• 日本ネットワークイネイブラー株式会社 久保田 聡
• 日本ネットワークイネイブラー株式会社 佐藤 信一
• 株式会社ネクステック 大石 憲且
• 株式会社ネクステック 高津戸 敦
• 株式会社バッファロー 山田 大輔
• 株式会社バッファロー 稲田 哲也
• 東日本電信電話株式会社 田中 一直
• ビッグローブ株式会社 長田 成人
• ビッグローブ株式会社 上杉 健治
• ヤマハ株式会社 下薗 大樹
• ヤマハ株式会社 太田 将博