ネットワークスペシャリスト 2025年 春期 午後II 問題

共通の文章

社内ネットワークのTIPV6対応に関する次の記述を読んで,設問に答えよ。 Q社は全国に拠点をもつ大手の電機メーカーである。Q社で利用される社内ネット ワークにはIPv4アドレスだけが割り当てられており,従業員は社内ネットワークに 接続されたPCを利用して,社内Web,電子メール,ファイル共有,チャットやWeb会 議などのサービスを提供するV社SaaS,及びインターネット上のWebサイトにアクセ スして業務を行っている。 Q社で利用しているSaaSやWebサイトのIPv6の対応状況,及び近年のIPv6普及率 の向上を踏まえ,情報システム部はIPv6の調査と社内ネットワークのIPv6対応につ いて検討することにした。TIPv6の調査と社内ネットワークのIPV6対応の検討は,情 報システム部の『P主任が担当することになった。 [社内ネットワークの概要】〕 |0社の現状の社内ネットワーク構成を図1に示す。 if ーーピコーー !社内ネットワークーー !Tatsつ 1い! !! || |! || || !||DNSサーバサーバ1 ーーーーニーーニーニーーーーニニーーーーーニーーニーニーニーーニーーニニニニニーニーニーニニーーーニーニーニニーーニニーーしーポ LOW:レイヤー2スイッチL3SW:レイヤー3スイッチ FW:ファイアウォール ISP:インターネットサービスプロバイダ 広域イーサ網:広域イーサネットサービス網 図1 Q社の現状の社内ネットワーク構成(抜粋) pam 3 es 1の概要を次に示す。 ・社内ネットワークのPC,ネットワーク機器及びサーバにはIPv4アドレスを割り当 てている。 ・ルータBにはデフォルトルート及びNAPTを設定している。 ・FWでは,ステートフルパケットインスペクションを用いたアクセス制御を行って いて,許可及び拒否した通信のログを記録している。 ・ルータB,FW及び各拠点のL3SWは,0SPFv2を用いて経路制御を行っている。 ・ルータBは,0SPFv2でデフォルトルートを配布している。 ・データセンターと各拠点との間は,レイヤー2の広域イーサ網で接続されている。 ・PCは,IPv4アドレス,デフォルトゲートウェイ及びキャッシュDNSサーバに関す る情報を,DHCPサーバから取得している。 (IPv6対応の方針〕 V社SaaSの一部及びインターネット上のWebサイトの一部は,現時点ではIPv6に 対応していない。P主任は,社内ネットワークのIPv6対応後もIPv4のネットワーク への接続を確保する必要があると考えて,社内ネットワークには,IPv4とIPv6のデ ュアルスタックのネットワークを採用する方針で,IPv6対応について検討すること にした。 【IPvY6におけるアドレス解決〕 IPv6におけるアドレス解決では,IPv4のARPに相当する機能をもつ,RFC 4861で 規定されたNeighbor Discovery Protocol(LAF,NDPという)が用いられる。 IPv4のARPによるアドレス解決では,要求元のノードは,求めるMACアドレスに対 応するIPv4アドレスをARPリクエストの| a|フィールドに入れて, [|5 ]キャストで送信する。次に,ARPリクエストを受信した,要求された IPv4アドレスをもつノードは,自身のMACアドレスをARP| c|の送信元MAC アドレスフィールドに入れて,要求元のノード宛てに送信する。 IPv6のNDPによるアドレス解決では,要求元のノードは,求めるMACアドレスに対 応するIPvV6アドレスをICMPv6のNeighbor Solicitation(LAF,NSという)メッセ ージに入れて,マルチキャストで送信する。次に,NSメッセージを受信した,要求 ー4一 されたIPvV6アドレスをもつノードは,Neighbor Advertisement(LAF,NAという) メッセージに自身のMACアドレスを入れて,要求元のノード宛てに送信する。 [IPvV6アドレスの割当て〕 NDP tk,ICMPv6 ONSメッセージ及びNAメッセージに加えてRouter Solicitation (以下,RSという)メッセージやRouter Advertisement(以下,RAという)メッセ ージなども用いて,アドレス解決以外の次の機能を実現している。 ・データリンク層で通信可能な範囲にあるルータを発見する機能 ・サブネットプレフィックスやデフォルトルータを決定するための情報を,ノード に通知する機能 ・利用予定のIPV6アドレスがほかのノードで利用されていないか確認する重複アド レス検出機能 IPv6アドレスの構造,使用方法及び自動設定については,RFC 4291で規定された IPv6アドレス体系,及びRFC 4862で規定されたSLAAC(IPv6 Stateless Address Autoconfiguration)に規定されている。 IPv6アドレスは128ビットで構成され,|d|ビットずっを“:"で区切っ て表される。26001:db8:aabb:1::1/64を例とするIPvV6アドレスの構造を図2に示す。 7トプレフィッEi 2001:0db8:aabb:0001:0000:0000:0000:0001 2 2001:db8:aabb:1::1/64を例とするIPv6アドレスの構造 IPv6アドレスには,リンクローカルユニキャストアドレス(LAF,LLAという)と グローバルユニキャストアドレス(以下,GUAという)がある。①LLAはある範囲で ネットワークインタフェースを一意に識別できるIPv6アドレスであり,サブネット プレフィックスには“fe80::/64”を用いる。GUAは,IPv6で構成されるインターネ ットを含むおグローバルなネットワークで,ネットワークインタフェースを一意に識 ーー5ーー 別できるIPvV6アドレスである。 インタフェース識別子の生成方法を次に示す。 ・疑似乱数関数を用いてランダムなインタフェース識別子を生成する方法 |sg|ビットのWACアドレスからビットのModified EUI-64 7% 式のインタフェース識別子を生成する方法 ノード1におけるNDP及びSLAACを用いたIPvV6アドレスの生成処理を図3に示す。 なお,Q社の社内ネットワークの拠点1においては,ノード1及びノード2はPCであ り,ノード3はL3SW1である。 (i)ーーーーーーーーーーーーィーーーーー>4 NSメッセージリ NA Xk yvt—Y?)es a x (ii)ーーーーーーーーーーーーィーーーーー (ii)ーーーーーーーーーーーャーーーーーx ぃーーバグ3)ーーイー re RAメッセージ (v)ーーーーーーーーーーーーャーーーーー> NSメッセージリ NAメッセージ9 TOOT移 (vi)ーーーーーーーーーーーーィーーーーー OUP,:マルチキャストアドレス宛ての通信O—>:ノード1のLA宛ての通信 抑)ノードはメッセージを破棄する。 注り宛先IPv6アドレスは要請ノードマルチキャストアドレスであり,ノード1が宛先アドレスフィールドに 入れるIPv6アドレスの下位24ビットと,宛先のノードのインタフェース識別子の下位24ビットが同じ場 合に受信される。 注?宛先IPyv6アドレスは全ノードマルチキャストアドレスである。 注3宛先IPY6アドレスは全ルータマルチキャストアドレスである。 3ノード1におけるNDP及びSLAACを用いたIPv6アドレスの生成処理 3中の処理(i)~(vi)の概要を次に示す。 (i)ノード1は,ROLLAを生成してNSメッセージに入れて送信し,ほかのノー ドからNAメッセージの応答がないことを確認する。 (ii)ノード1は,仮のLLAを正式なLLAとしてNAメッセージに入れて,全ノード —6_ マルチキャストアドレス宛てに送信する。 (ii)ノード1は,RSメッセージを全ルータマルチキャストアドレス宛てに送信す る。 (iv)RSメッセージを受信したノード3は,GUAの生成に用いるサブネットプレフィ ックス,及びデフォルトルータを決定するための情報をRKメッセージに入れて, ノード1宛てに送信する。 (v)ノード1は,RAメッセージのサブネットプレフィックスと生成したインタフ ェース識別子を組み合わせた仮のGUAをNSメッセージに入れて送信し,ほかの ノードからNAメッセージの応答がないことを確認する。 (vi)ノード1は,仮のGUAを正式なGUAとしてNAメッセージに入れて,全ノード マルチキャストアドレス宛てに送信する。 ノード1は,ノード3を経由して外部のノードと通信を行うために,処理(iv)で受 」信した,RAメッセージの送信元であるノード3のLLAを| g|に設定する。 I Q社のネットワークにおけるIPv6アドレスの割当てについて,P主任が調査した結 果の一部を次に示す。 ・Q社は,ISPから,プレフィックス長が48又は56のGUAの割当てを受けることが できる。 ・ISPから割り当てられたGUAを,プレフィックス長が64のネットワークに分割し て,利用することができる。 ・SLAACを利用して,PCのLLA GUA,及び| g|を自動で設定することができ る。 ・ルータB,FW及び各拠点のL3SWには,LLA及びGUAを静的に割り当てることができ る。 ・固定のMACアドレスからModified EUI-64形式のインタフェース識別子を生成する 方法は非推奨である。 PCのインタフェース識別子が疑似乱数関数を用いてランダムに生成される場合, ②利用者のプライバシー保護に有用であるが,PC管理の観点で考慮が必要になると —%— P主任は考えた。 [IPv6の名前解決〕 IPv4の名前解決と比べてIPv6の名前解決では,512バイトよりも大きなDNSメッ セージを送受信する可能性が高い。DNSの機能を拡張するためにRFC 6891で規定され たExtension Mechanisms for DNS version 9(LAR,EDNSという)では,スタブリ ゾルバとフルサービスリゾルバとの間,及びフルサービスリゾルバと権威DNSサーバ との間で,UP上で送受信されるDNSメッセージのサイズの上限を緩和している。 P主任は,IPVEアドレスの名前解決について,フルサービスリゾルバであるキャッ シュDNSサーバを管理する情報システム部のR係長に相談した。2人の会話を次に示 す。| P主任:社内ネットワークをIPv6に対応させることになった場合に,キャッシュDNS サーバにIPv6アドレスを割り当てる必要がありますか。 R係長:不要です。キャッシュDNSサーバはIPv4のネットワーク上でDNSメッセージ を送受信して,FQDNに対応するIPvV6アドレスを解決できます。例えば, IPv6とIPv4の両方に対応するWebサイトの名前解決を行う場合に,PCは AAAレコードとAレコードを用いて名前解決を要求することで,IPv6アド レスとIPv4アドレスの両方を取得します。 P主任:FQDNからIPv6アドレスとIPv4アドレスの両方を解決した場合,Q社のPCは どのように動作するのですか。 R係長:AAAAレコードとAレコードの応答をほぼ同じタイミングで受信した場合には, IPv6を優先して通信を行います。 P主任:IPvV6のDNSメッセージは,IPv4のDNSメッセージよりもサイズが大きくなる と考えています。UDP上で送受信されるDNSメッセージのサイズには上限が ありますが,何か対応が必要でしょうか。 R係長:0社のキャッシュDNSサーバはEDNSに対応済みです。PCから名前解決の要求 を受けたキャッシュDNSサーバが,権威DNSサーバに問い合わせる場合を例 に説明します。キャッシュDNSサーバは,まず,DNSを利用して権威DNSサ ーバのEDNSの対応可否を確認します。EDNSを利用できるときには,両方の サーバ間で調整した最大のメッセージサイズまでであれば,512バイトを超 ー8一 えるDNSメッセージであってもUWPで送受信します。DNSメッセージが最大 のメッセージサイズを超えるときや,EDNSに対応していない権威DNSサー バパと512バイトを超えるDNSメッセージを送受信するときには, で送受信することになります。 P主任が作成したDNSの通信例を図4に,V社SaaSのFQDNに対するAAAAレコード の応答例を図5に示す。 キャッシュ (i)AAAAレコードの問合せ I (ii) (iii) (iv) | (v)= 注記キャッシュDNSサーバと権威DNSサーバとの間の通信は省略する。 図4 P主任が作成したDNSの通信例(抜粋) ;;ANSWER SECTION: saas.example.com.3600 IN CNAME dual-saas.example.net. dual-saas.example.net.240 IN AAAA 2001:db8:xxxx::10 dual-saas.example.net.240 IN AAAA 2001:db8:xxxx::20 ;;AUTHORITY SECTION: example.net.172800 IN NS ns1.example.net. example.net.172800 IN NS ns2,example,net. ;;ADDITIONAL SECTION: ns,example,net.172800 IN A 198.51.100.a ns2.example.net.172800 IN A 198.51.100.B 注記1 saas.example.com.は,V 4b SaaSのFQDNである。 注記2 2001:db8:xxxx::10及び2001:db8:xxxx::20はGUAである。 注記3 198.51.190.w及び198.51.199.8はグローバルIPv4アドレスである。 5 V社SaaSのFQDNに対するAAAAレコードの応答例(抜粋) ③LIPv6のネットワークだけが不通となった場合に,利用している0SやWebブラウ ザによっては従業員が異常に気付くことができず,情報システム部に異常を連絡で ー9一 きない可能性があるとP主任は考えた。IPv6のネットワークの異常を検知するため に,データセンターに監視サーバを導入して,[PvEのインターネットへのアクセス や,各拠点のL3SWのGUAに対してping6コマンドによる監視を行うことにした。 [IPv6ネットワークの設計] P主任は,1の社内ネットワークを基に,IPv4とIVEのデュアルスタックのネ ットワークを設計した。P主任が設計した社内ネットワーク構成を図6に示す。 ーーカーー a !社内ネットワーク !i o_O (ペー| 1 |! 1 || !Be 1 :: || 3( !||DNSサーバサーバ ニニーーこここここここここさここごここここここ=にーーニニニニこここここここここさこ ネットワーク機器に割り当てるIPv6アドレス一覧 =r|a[ws|*mmc| b feezew ST ルータB hmに(0[zeyysin64| にesazed|Wmac a e80::2/64 2001:db8:yyyy:2::2/64 注記1 a~hは各ネットワーク機器のインタフェース名を示す。 注記2 2001:db8:yyyy:1::/64て2001:db8:yyyy:3::/64はGUAのサブネットプレフィックスである。 図6 P主任が設計した社内ネットワーク構成(抜粋) 6の概要を次に示す。 ・IPv4のネットワーク設計に関する変更はない。 PC,ネットワーク機器及び監視サーバには,IPv4アドレスに加えてIPv6アドレス を割り当てる。 ・ISPから0社に割り当てられるGUAを,2001:db8:yyyy::/48として設計する。 ・ルータBには,ルータAのLLAをネクストホップとするデフォルトルートを設定す る。 ・ルータB,FW及び各拠点のL3SWは,0SPFv3を用いてIPv6の経路制御を行う。 ・0SPFv3ではLLAを用いて隣接関係を確立してIPv6の経路制御を行うので,④FWと 各拠点のL3SWとの間の,PCやサーバを接続しないネットワークにGUAを割り当て る必要はないが,静的に割り当てる。 ・ルータBld,0SPFv3でデフォルトルートを配布する。 ・⑤PCは,SLAACを用いてIPv6アドレス及びデフォルトルータを設定する。 ルータB,FW及びL3SW1のIPv6の経路情報を表1に示す。 表1ルータB,FW及びL3SW1のIPv6の経路情報(抜粋) ーーにーー ルータB pe fess lewme fe Es SE!IPパケットを廃棄するためのインタフェースである。 IPv6のネットワーク設計について,P主任は情報システム部のS課長に,図6及び 表1を用いて説明した。2人の会話の一部を次に示す。 P主任:ISPには,Q社にプレフィックス長が48のGUAを割り当ててもらえることを確認 しました。図6及び表1はISPから割り当てられるGUAを2001:db8:yyyy::/48 として作成しています。TISPのルータAには,ルータBのLLAをネクストホ =i ップとする2001:db8:yyyy::/48宛ての静的経路が設定されます。 S課長:表1の経路情報について説明してください。 P主任:項番1は,ISPを経由してインターネットにアクセスするためのデフォルト ルートです。項番ld,ISPから割り当てられるプレフィックス長が48の GUAのうち,使用されないGUAが存在するので設定します。⑥項番2の経路 情報を設定しない場合,.ルーティングループが発生します。⑦項番1と項番 2の両方の経路情報に該当するIPパケットの転送では,ルータBは項番2の 経路情報を選択します。社内ネットワークの経路制御には0SPFv3を利用し ます。項番3と項番5は,拠点1のネットワーク宛ての経路情報です。項番 4と項番6は,ルータBから配布されるデフォルトルートによって登録され る経路情報です。 S課長:IPyv6のネットワークは,IPv4のネットワークと比較して情報セキュリティ 面で違いはありますか。 P主任:異なる点があります。TIPv4のネットワークではFWによるアクセス制御に加 えて,ルータBに| i|を設定しているので,インターネットから社 内ネットワークには簡単に通信できない設計になっています。TIPv6のネッ トワークでは|ij|を利用しないので,FWのアクセス制御の設計につ いては慎重に検討する必要があります。 S課長:FTWでは,インターネットから社内ネットワーク宛ての全ての通信を拒否する 設定を行えをばよいのでしょうか。 P主任:IPv6の通信では,ICMPV6メッセージを通信の制御に利用しているので, ICMPV6メッセージを拒否すると通信障害を発生させるおそれがあります。 例えば,中継する機器がMTUサイズよりも大きいサイズのIPパケットを転 送できないときに,⑧中継する機器から送信元にタイプ2のICMPv6メッセ ージである“Packet Too Big”を送信するPMTUD(Path MTU Discovery)に 利用されています。ほかにも,ICMPvV6メッセージのタイプによってはFWで 許可すべきものがあるので,調査する予定です。 P主任によるIPv6の調査とIPv6対応の検討の結果は情報システム部で承認されて, 社内ネットワークへのIPv6導入において活用されることになった。 ー12一

共通の文章

IoTシステムの設計に関する次の記述を読んで,設問に答えよ。 Y社は,LPガスメーターを製造し,全国のLPガス販売業者に販売している。この たび,Y社では,LPガス販売業者向けにLPガス使用量の遠隔検鑑サービスを開始す ることになり,遠隔検針機能をもつY社製LDLガスメーター(以下6メーターとい う),Gメーターを管理するサーバなどから構成されるlolシステムを開発すること にした。 lolシステム開発プロジェクトチームの責任者には,W課長が任命された。W課長 は,IoTシステムの要件として次の二つを設定し,プロジェクトチームのメンバーで ネットワーク技術者のX主任に,IoTシステムの機能と構成の検討を指示した。 (1)6Gメーターは全国に設置されるので,全国規模で提供可能なIoT向けの無線回 線を利用すること (2)Gメーターは電池で動作させるので,長時間の稼働を可能にすること [IoT向けの無線技術の調査と無線回線の選定] 最初に,X主任は,IoT向けの無線技術を調査し,調査結果を次のようにまとめた。 ・1oT向けには,LPWA(Low Power Wide Area)と呼ばれる,低[|a|電力の無 線通信技術が利用される。 ・LPMAは,セルラー系と非セルラー系の二つに大別される。| b|系には LoRaWAN,Sigfoxなどがあり,|c|系にはLTE-M(LTE Cat.M),NB-ToT (LTE Cat.NB1)などがある。 -LoRaWAN,Sigfoxは,日本ではSub-GHz帯の一つである920 MHz帯を利用する。920 MHz帯はWi-Fiが利用する周波数帯と同様に,| d|バンドと呼ばれる周波数 帯であるが,2.4 GHz帯と比べて電波|e|の影響が少ない。 ・LTE-M,NB-IoTは,と呼ばれる標準化プロジェクトが作成した技術仕様 を基に,通信事業者が全国規模で構築したLTE網でサービスが提供されている。 調査の結果,LTE-Mを利用すれば全国の幅広い地域でIorTシステムを稼働させるこ とができることが分かった。次に,X主任は,LTE-Mを利用したToT向けのサービス を提供している企業の中からZ社を選定し,Z社のlol向け通信サービスについて調 ーjm— 窒することにした。 (Z社のToT向け通信サービスの調査 Z社のIoT向け通信サービスは,LPWA閉域接続サービスとIPsec VPNを用いて顧客 ごとに閉域綱を構成する。 Z社のIoT向け通信サービスを利用したときのlolシステムの構成を図1に示す。 |社のToT REFER EA Ce He a ーッー Gh IP Ky KD IBS SLOOP MOET 注記Gメーター管理サーバは,6メーターと通信して検針データを収集するサーバである。 図1 Z社のlol向け通信サービスを利用したときのlolシステムの構成(抜粋) Z社は,GMWとルータとの間を専用線で接続し,Z社サービス拠点とY社サービス抗 点との間はIPsec VPNで接続することによって,Y社向けの閉域網を構成する。 図1中のIPsecルータ1で動作するIKEv2は,IPsecルータ2との間で,四つのメ ッセージの交換を| g|往復で行い,SAD(Security Association Database) を作成する。IPsecルータ1のSPD(Security Policy Database)中のセレクターに は,|h|宛てのパケットを受信したとき,SADを参照してIPsecの処理を行う ことが設定されている。 閉域網が構成されることによって,GメーターとIPsecルータ2に接続する予定の Gメーター管理サーバとの通信は,.プライベートIPアドレスで行うことができる。G メーターには,通信事業者が契約者を識別する情報を記録している|」|ヵー ドを装着する。 X主任は,Z社のlol向け通信サービスの利用料を,次の条件を基に試算した。 ・Gメーター1台当たりの1回の検針時の通信量を199バイトとし,1時間ごとに検針 を実施する。 ー16一 ・通信費は1か月の通信量1,.090バイト当たり1円とし,6メーターごとに割り当て る1回線当たりの基本料金は月額309円とする。 この条件から,Z社のlol向け通信サービスを利用すると,1か月が30日の場合, Gメーター1台当たりの検針に必要な1か月の利用料は|i|円なので,LPガ ス販売業者向けに安価な遠隔検針サービスを提供できることが分かった。 次にX主任は,GメーターとGメーター管理サーバとの間でデータを送受信するた めの通信プロトコルを検討した。TIoT向けの通信プロトコルには,RFC 7252で標準化 されたCoAP(Constrained Application Protocol)とOASIS標準メッセージングプロ トコルであるMQTT(Message Queuing Telemetry Transport)がある。CoAPは,Web システムにおけるAPIの形式である|k|アーキテクチャを採用しているので, Web技術でIoTシステムを構築する場合に適している。そこで,X主任は,CoAPにつ いて調査した。 [CoAPの調査 CoAPは,伝送効率を考慮して標準ではUPを利用し,データの保護が必要な場合 ld,RFC 9147で標準化されたDTLS(Datagram TLS)を利用することができる。 CoAPのメッセージ形式を図2に示す。 M 7 8 15 16 31 Ver:バージョン(2ビット)TS:タイプ@⑫ビット)TKL:トークン長(4ビット) 注記先頭の4バイトは固定長ヘッダーである。 2 CoAPのメッセージ形式 CoAPでは,確認が必要なメッセージ(以下,CONという),確認が不要なメッセー ジ(以下,NONという),確認応答メッセージ(LAK,ACKという),リセットメッセ ージの4種類が定義されており,図2中のタイプでメッセージ種類を指定する。CoAP サーバ及びCoAPクライアントは,CONを受信したときはACKを返送し,NONを受信し Ke RIE ACKを返送しない。 っ{7— 図2中のコードは,要求の場合,メソッドコードを示し,応答の場合,レスポンス コードを示す。メソッドコードを表1に,レスポンスコードを表2に示す。 表1メソッドコード(抜粋) 指定したリソースを取得する。 指定したリソースを作成する。 指定したリソースを削除する。 表2レスポンスコード(抜粋) リクエストが正常に処理され,指定したリソースが作成された。 リクエストが正常に処理され,指定したリソースが消去された。 リクエストが正常に処理され,指定したリソースが取得された。 メッセージIDは,要求と応答のメッセージを関連付けるとともに,メッセージの 重複を検出するのに使用される。CoAPは,|||層のプロトコルであるUDP上 での動作を前提としている。通信品質の劣るネットワークなどでは,パケットが |m|で到着したり,して出現したり,通知なしに消失したりする ことがあるので,CoAPは,メッセージTIDを利用することによって,送受信が正しく 行われるための仕組みを実装している。 トークンは,要求した情報と応答された情報を関連付けるために使用される。 CoAPクライアントはトークンの値によって,どの要求に対して応答された情報なの かを判断する。 CONとACKを用いた通信例を図3に示す。 CON[0x7d34)CON(9x81ab〕 キトーCON[0x81ab) _ (i)複数のサーバへのCON連続送信の場合(ii)ACK不達の場合 注記1 0内の0xは,xの後ろに続く数字又は文字が,16進数であることを示す。 注記2 0)内の16進数は,メッセージ1Dである。 図3 CONとACKを用いた通信例 図3中の(i)では,CoAPクライアントは,CONに対して返送されたACKによって, CONがCoAPサーバに到達して処理されたことが分かることを示している。CoAPでは, 図3中の(i)に示したように,ACKの受信を待たずに連続してCONを送信することが できる,非|”o|通信が行われる。 (ii))では,ACK不達時に,CONの再送によってCON又はACKを確実に到達させるこ とを示している。(ii)に示したように,CoAPクライアントはCONを送信後,デフォ ルトのタイムアウト時間であるaの時間ACKの受信を待ち,ACKが受信できなかった 場合は,指数|p|と呼ばれる方式で算出したbの時間経過後にCONを再送す る。図3で示したように,CoAPでは,CONに対するACKの返送及びCONの再送によっ て,パケットロスなどが発生するネットワークを利用した場合も,確実な通信を行 うことができる。 IoT向けの機器は,サーバにデータの提供を要求する場合がある。このような場合, 要求したデータと応答されたデータを関連付けるのにトークンが利用される。 機器がサーバにデータの提供を要求したときのトークンの使用例を図4に示す。 CON(0x1234]GET/data(トークン0x10) 7 4機器がサーバにデータの提供を要求したときのトークンの使用例 ー19— 図4では,機器がサーバ宛てのCONの中で,提供を求めるデータに0x10という値 のトークンを指定している。この要求を受信したサーバは,提供するデータに0x10 という値のトークンを付与して応答する。機器は,トークン値から要求したデータ としてデータAが回答されたことを知ることができる。 4中のACKには,Contentのデータも含まれている。このように,CoAPでは, ACKにContentのデータを加えて送信する,ピギーバックと呼ばれる応答方式が利用 される。 機器が連続してサーバに異なるデータの提供を要求する場合もある。 機器が連続してサーバに異なるデータの提供を要求したときの応答例を図5に示す。 (i)CON(Oxbc9@)GET/datal(トークン0x71) (ii)CON(Oxab20)GET/data2(トークン0x82) (iii CON(Oxde10)GET/data3(トークン0x90) (v)ACK(Oxab20)2.05 Content(トークン0x82)“データX” (vi)ACK(Oxde10)2.05 Content(トークン0x90)“データY” (vii)ACK(Oxde10)2.05 Content(トークン0x90)"データY” (vi)CON[9xcdf2〕2.05 Content(トークン0x71)“データ7” 注記|は,ネットワーク上でパケットが転送される過程で複製されたことを示す。 図5機器が連続してサーバに異なるデータの提供を要求したときの応答例 5中の①(iv)は,サーバが要求を受信したときにデータをすぐに送信できない 場合の応答である。(ji)を受信したサーバはデータを送信できている。(vi)は, ネットワーク上の何らかの原因によって,(vi)と重複したACKが機器に到達したこと を示している。(vii)を受信した機器は,ACKが重複したものであると判断して,対 応する処理を行う。 CoAP通信で,データの保護が必要な場合はDTLSを利用する。DTLSは,TCP通信の アプリケーション層のデータを暗号化するTLSの機能をUDPに適用した技術である。 DTLSバージョン1.3(以下,DTLS 1.3という)は,TLSバージョン1.2(以下,TLS 1.2という)と異なった方法でClientHelLoメッセージの送信を求める。 TLS 1.2とDTLS 1.3のハンドシェークの違いを図6に示す。 (i)ClientHello(i)ClientHello DUR,省略 以下,省略 (1)TLS 1.2のハンドシェーク(抜粋)(2)DTLS 1.3のハンドシェーク(抜粋) M6 TLS 1.2とDTLS 1.3のハンドシェークの違い 6中の(1)に示したTLS 1.2のハンドシェークをUP上で行うと,④攻撃者が (i)のClientHelLltoメッセージの送信元を偽装して送信した場合.TLSサーバはパ ケットサイズの大きな(ii)のServerHelloメッセージを返送することになり,TLSサ ーバがDDoS攻撃の加害者になるおそれがある。この攻撃に対処するために,(2)に示 したDTLS 1.3のハンドシェークでは,(i)のClientHelloメッセージを受信した DTLSサーバが,(ii)のHelloRetryRequestメッセージにcookieを添付して送信する。 (ji)を受信したDILクライアントは,受信したcookieを添付した(ii)の ClientHelloメッセージを再度送信する。⑤DLSサーバは,Gili)に添付された cookieを検査し,cookieが不正な場合は対応する処理を行う。 無線回線の選定及びGメーターと社拠点に導入するGメーター管理サーバとの間 で利用するCoAPの調査が終わったので,X主任は,ToTシステムの機能と構成の検討 に取り掛かった。 (lolシステムの機能と構成の検討] まず,X主任は,Gメーター開発技術者からGメーターが送受信できる情報の説明 を受け,次の2点の主要な機能を実現するための方式を検討した。 ー21一 (1)遠隔検針 (2)異常通知 Gメーター管理サーバは数万台のGメーターを管理することを前提に,6メーター でCoAPクライアント機能を,Gメーター管理サーバでCoAPサーバ機能を動作させる ことにした。 X主任が考えた,6メーターの動作を次に示す。 (1)について,6メーターは1時間ごとにLPガスの流量積算値を測定して,測定時 刻と測定値(以下,測定データという)をメモリに記録し,毎日午前9時の測定の後, ⑥ランダムな時間経過後に,前日に測定した1時間ごとの測定データを24回に分け てGメーター管理サーバに送信する。⑦LPガスの流量積算値の測定又は測定データ 送信後,次の測定を行う時刻までの間は,Gメーターはスリープ状態になる。 (2)について,Gメーターはウェイクアップして測定を行うタイミングを利用して Gメーター自身の稼働状態をチェックし,異常を検各したときに異常内容をGメータ ーー管理サーバに送信する。 X主任は,Gメーターの動作を基に,Gメーターと6Gメーター管理サーバとの間の通 信方法をまとめた。Gメーターと6Gメーター管理サーバとの間の通信の概要を図7に, Gメーターによる測定と測定データの送信タイミングを図8に示す。 (1)遠隔検針の通信(2)異常通知の通信 CON〔9x11ab〕POST/0時測定データCON(0x1234)POST/異常情報 oe CON〔9x99ef]POST/23時測定データ M7 6メーターと6メーター管理サーバとの間の通信の概要 ー22一 EE<a aC ne 1 i a 6Gメーター管理サーバ——} V:測定”:測定データの送信 図8 Gメーターによる測定と測定データの送信タイミング 図7中の(1)及び図8に示したように,Gメーターは,毎日午前9時の測定を行っ た後,1時までの間のランダムな時間経過後に,1時間ごとに記録した1日分24件の 測定データを,それぞれPOSTメソッドでGメーター管理サーバに送信する。これに kot,図7中の(1)では,GメーターがPOSTメソッドを24回発行することになる。 ⑧CoAPでやり取りされるIPパケットの数は,HTTPバージョン1.1を利用して同様の 方法で測定データを送信する場合と比べると少ないので,測定データの通信時間は 短くて済む。 図7で示したCoAP通信でDTLSを利用すると,Gメーターで実施する通信処理の負 荷が,Gメーターの性能に影響与えるおそれがある。そこで,X主任は,⑨今回開 発するIorTシステムでは,DTLSを利用しなくてもCoAP通信のセキュリティは確保さ れると判断し,DTLSは利用しないことにした。 Gメーターは図8に示した動作を行うので,時計機能の実装が必要になる。Gメー ターに精度の高いリアルタイムクロックを実装しても,⑩Gメーターを長時間稼働さ せると時刻の誤差が無視できないほど大きくなるおそれがある。そこで,X主任は, OGメーターに時刻の誤差を抑えるための処理を組み込むことにした。 これらの検討を基に,X主任は,IoTシステムの構成を設計した。X主任が設計し たIoTシステムの構成を図9に示す。 ー23一 :NN LPWA サービス —-HES,ane LTE-M IP pee LPガス Y社サービス拠点販売業者hz 人 = リーニーCO! 1 4=} 96! :faz Mg te L2W:レイヤー2スイッチFW:ファイアウォール 注記1図中の網掛けは,CoAP通信を行う機器を示す。 注記2 Gメーターh1 ld,LPガス販売業者h1社が所有するGメーターであり,Gメーターhz は,LPガス販売業者hz社が所有するGメーターである。 図9 X主任が設計したIoTシステムの構成(抜粋) 図9中のY社サービス拠点のサーバは,NTPサーバとの間で時刻同期を行う。 Gメーター管理サーバは,全Gメーターから1日分の測定データを受信した後に, 2時からGメーターごとにLPガス消費量などを集計する。集計したデータはLPガス 販売業者別に情報提供サーバに送信される。情報提供サーバは,受信した情報をLP ガス販売業者向けに公開する。 Gメーターから送信される異常情報は,Gメーター管理サーバを介して情報提供サ ーバに送信される。情報提供サーバは,LPガス販売業者宛ての異常通知メールを作 成し,メールサーバに送信する。 lolシステムの機能と構成の検討が完了したので,X主任は,検討結果をW課長に 報告した。W課長は,報告内容を基に,IoTシステム開発の概要を経営会議で提案し た。提案内容が承認され,lolシステム開発プロジェクトが本格的に開始されること (cove.