令和7年度 春期 午後Ⅱ

本文の根拠

〔IPv6 におけるアドレス解決〕

要求元のノードは，求める MAC アドレスに対応する IPv4 アドレスを ARP リクエストの a フィールドに入れて，b キャストで送信する。

〔IPv6 におけるアドレス解決〕

自身の MAC アドレスを ARP c の送信元 MAC アドレスフィールドに入れて，要求元のノード宛てに送信する。

〔IPv6 におけるアドレス解決〕

IPv6 アドレスを ICMPv6 の Neighbor Solicitation（以下，NS という）メッセージに入れて，マルチキャストで送信する。

ARP（RFC 826）の手順をそのまま埋める。要求元は，MAC アドレスを知りたい相手の IPv4 アドレスを ARP リクエストの宛先 IP アドレス（Target Protocol Address）のフィールドに入れ，同じセグメントの全ノードに届くようブロードキャストで送る。該当する IPv4 アドレスをもつノードだけが，自分の MAC アドレスを送信元 MAC アドレスに入れた ARP リプライをユニキャストで返す。

本文は直後の段落で IPv6 の NDP と対比している。IPv6 では同じ問合せを NS メッセージに入れて「マルチキャストで送信する」。IPv6 にはブロードキャストが無いので，対比の相手である b はブロードキャストだと分かる。c も，NS に対する NA が「応答」に当たることから，ARP の応答であるリプライと決まる。

間違えやすい点。a は「宛先 MAC アドレス」ではない。宛先 MAC アドレスは分からないから問い合わせているのであり，フィールドに入れるのは IP アドレスである。b は空欄の後ろに「キャスト」が続くので「ブロード」だけを書く。c も「ARP c」と続くので「リプライ」（「レスポンス」「応答」と書いても意味は同じだが，ARP の用語としてはリプライ）。

本文の根拠

〔IPv6 アドレスの割当て〕

IPv6 アドレスは 128 ビットで構成され，d ビットずつを“:”で区切って表される。

図2

2001:0db8:aabb:0001:0000:0000:0000:0001 と省略せずに書いたアドレス

〔IPv6 アドレスの割当て〕

e ビットの MAC アドレスから f ビットの Modified EUI-64 形式のインタフェース識別子を生成する方法

d は図2から数えられる。省略しない表記では“:”で区切られた欄が8つあり，1欄は16進数4桁。16進数1桁は4ビットなので1欄は16ビット，8欄で128ビットになる（RFC 4291 2.2節）。

e と f は RFC 4291 の付録Aにある Modified EUI-64 の作り方である。イーサネットの MAC アドレス（48ビット）の上位24ビットと下位24ビットの間に 0xFFFE の16ビットを挟み，U/L ビットを反転して64ビットのインタフェース識別子にする。64ビットという長さは，図2でインタフェース識別子が後半4欄（16ビット×4）を占めていることとも合う。

間違えやすい点は単位。d は“:”1区切りの桁数（4桁）ではなくビット数を問うている。e・f の「EUI-64」の64がそのまま f の答えになっているので，e に 64 と書かないこと。

本文の根拠

〔IPv6 アドレスの割当て〕

①LLA はある範囲でネットワークインタフェースを一意に識別できる IPv6 アドレスであり，サブネットプレフィックスには“fe80::/64”を用いる。

〔IPv6 アドレスの割当て〕

データリンク層で通信可能な範囲にあるルータを発見する機能

リンクローカルアドレスは，名前のとおり1つのリンクの中だけで使うアドレスである。RFC 4291 2.5.6節は，リンクローカルアドレスは単一のリンク上でのアドレス付けに使うよう設計されており，ルータはリンクローカルの送信元・宛先をもつパケットを他のリンクへ転送してはならないと定めている。つまり有効範囲は，ルータを越えずに届く範囲＝データリンク層で通信できる範囲である。

本文にもこの範囲を指す言い方がある。NDP の機能の説明にある「データリンク層で通信可能な範囲」である。GUA が「インターネットを含むグローバルなネットワークで」一意なのと対比されている。

20字に収める。解答例は「データリンク層で通信可能な範囲」で15字。「同一リンク内」「同じセグメント内」「ルータを越えない範囲」も同じことを言っている。「社内ネットワーク」や「拠点内」は広すぎる（拠点の中でも L3SW を越えれば別のリンク）。

本文の根拠

〔IPv6 アドレスの割当て〕

利用予定の IPv6 アドレスがほかのノードで利用されていないか確認する重複アドレス検出機能

図3の処理(ⅰ)

(ⅰ) ノード1は，仮の LLA を生成して NS メッセージに入れて送信し，ほかのノードから NA メッセージの応答がないことを確認する。

図3の処理(ⅴ)

(ⅴ) ノード1は，RA メッセージのサブネットプレフィックスと生成したインタフェース識別子を組み合わせた仮の GUA を NS メッセージに入れて送信し，ほかのノードから NA メッセージの応答がないことを確認する。

処理(ⅰ)と(ⅴ)は，NDP の3つめの機能として本文が挙げる重複アドレス検出（DAD，RFC 4862 5.4節）である。これから使う仮のアドレスを NS に入れて送り，同じアドレスを使っているノードがあれば NA で応答が返る。応答が無ければ重複は無いと判断して，(ⅱ)(ⅵ)で正式なアドレスにする。

(ⅰ)は LLA，(ⅴ)は GUA が対象なので，どちらのアドレスにも同じ確認をしている。確認する範囲は，NS がマルチキャストで届く範囲，すなわち同じデータリンク（リンク）の中である。図3の注1のとおり，NS の宛先は要請ノードマルチキャストアドレスで，同じアドレスをもつノードだけが受け取る。

55字に収める。解答例は「同じデータリンク層上に同じIPv6アドレスを使用しているノードがいないことを確認するため」で44字。要素は「同じリンク上で」「同じ IPv6 アドレス（仮のアドレス）を」「ほかのノードが使っていないことの確認」の3つ。「アドレスの重複を検出するため」だけでは，本文の機能名を言い換えただけで，何と何が重複するかが書けていない。

本文の根拠

図2

前半の 2001:0db8:aabb:0001 がサブネットプレフィックス，後半の 0000:0000:0000:0001 がインタフェース識別子であることを示している。

図3の処理(ⅴ)

RA メッセージのサブネットプレフィックスと生成したインタフェース識別子を組み合わせた仮の GUA

〔IPv6 アドレスの割当て〕

サブネットプレフィックスには“fe80::/64”を用いる。

LLA は fe80::/64 に，ノードが生成したインタフェース識別子（下位64ビット）を付けたものである。fe80::8:800:200c:417a の“::”を展開すると fe80:0000:0000:0000:0008:0800:200c:417a となり，下位64ビットのインタフェース識別子は 0008:0800:200c:417a である。

処理(ⅴ)は，RA で受け取ったサブネットプレフィックスと，生成済みのこのインタフェース識別子を組み合わせる。2001:db8:aabb:1::/64 の上位64ビット 2001:0db8:aabb:0001 に 0008:0800:200c:417a を続けると 2001:0db8:aabb:0001:0008:0800:200c:417a。先頭の0を省略すると 2001:db8:aabb:1:8:800:200c:417a，プレフィックス長は RA のプレフィックスと同じ 64 になる。

間違えやすい点。インタフェース識別子を取り出すとき，fe80 の後ろの“::”が0の欄を3つ分表していることに注意する（欄の数を数えて8欄にそろえる）。書くときは“::”で0の連続を省略できるが，このアドレスには0だけの欄が無いので省略する箇所は無い。

本文の根拠

図3の処理(ⅳ)

(ⅳ) RS メッセージを受信したノード3は，GUA の生成に用いるサブネットプレフィックス，及びデフォルトルータを決定するための情報を RA メッセージに入れて，ノード1宛てに送信する。

〔IPv6 アドレスの割当て〕

ノード1は，ノード3を経由して外部のノードと通信を行うために，処理(ⅳ)で受信した，RA メッセージの送信元であるノード3の LLA を g に設定する。

外部（他のネットワーク）宛ての通信を託す先のルータを設定する，という文脈なので，g はデフォルトルータ（デフォルトゲートウェイ）である。IPv4 で DHCP から受け取っていたデフォルトゲートウェイに当たる。

本文の(ⅳ)の説明に「デフォルトルータを決定するための情報を RA メッセージに入れて」とある。RFC 4861 6.3.4節のとおり，ホストは RA を受け取ると，その送信元アドレス（ルータのリンクローカルアドレス）をデフォルトルータの一覧に加える。ノード3（L3SW1）の LLA がデフォルトルータになるのはこのためである。後の箇条書きの「SLAAC を利用して，PC の LLA，GUA，及び g を自動で設定することができる」も同じ語が入る。

解答例は「デフォルトルータ」又は「デフォルトゲートウェイ」。IPv6 の規格（RFC 4861）の用語はデフォルトルータで，本文もこの語を使っているが，IPv4 で一般的なデフォルトゲートウェイでも同じ機能を指すので正解になる。「ネクストホップ」は経路ごとの転送先のことで，ここでは不十分。

本文の根拠

〔IPv6 アドレスの割当て〕

固定の MAC アドレスから Modified EUI-64 形式のインタフェース識別子を生成する方法は非推奨である。

〔IPv6 アドレスの割当て〕

PC のインタフェース識別子が疑似乱数関数を用いてランダムに生成される場合，②利用者のプライバシー保護に有用であるが，PC 管理の観点で考慮が必要になると P 主任は考えた。

MAC アドレスから作るインタフェース識別子は，どのネットワークにつないでも同じ値になるので，通信の相手や経路上の第三者がその PC を追跡できる。これが非推奨とされる理由である（RFC 8064 は，安定したインタフェース識別子に MAC アドレスを埋め込まないよう勧めている）。ランダムに生成すればこの追跡を防げるので，プライバシー保護に役立つ。

裏返すと，管理する側にとっても IPv6 アドレスから PC を突き止めにくくなる。IPv4 では DHCP サーバが IPv4 アドレスを払い出していたので，どの PC にどのアドレスを渡したかを把握できた。SLAAC でランダムに作るアドレスは PC が自分で決めるので，FW のログなどに残った IPv6 アドレスがどの PC のものかを調べにくい。これが「PC 管理の観点」での考慮点である。

20字に収める。解答例は「PCを特定しづらくなるから」で13字。講評はこの設問の正答率が低かったとしている。下線の前半（プライバシー保護）の理由を書いてしまうと，設問が問う「考慮が必要になる」理由にならない。

採点講評（IPA）

設問2では，(6)の正答率が低かった。プライバシー保護を目的として，IPv6のインタフェース識別子だけでなくMACアドレスをランダムに生成するケースも増えているので，PCがもつ識別子をランダムにすることによって得られるメリットと，新たに発生する課題について理解を深めてほしい。

本文の根拠

〔IPv6 の名前解決〕

EDNS を利用できるときには，両方のサーバ間で調整した最大のメッセージサイズまでであれば，512 バイトを超える DNS メッセージであっても UDP で送受信します。

〔IPv6 の名前解決〕

DNS メッセージが最大のメッセージサイズを超えるときや，EDNS に対応していない権威 DNS サーバと 512 バイトを超える DNS メッセージを送受信するときには，h で送受信することになります。

DNS は通常 UDP で送受信し，UDP で運べる大きさは EDNS が無ければ 512 バイト（RFC 1035 4.2.1節），EDNS があれば双方が通知したサイズまで（RFC 6891 6.2.3節）である。これを超える応答は，サーバが途中で切って TC（切り詰め）ビットを立てて返し，受け取った側は TCP で問い合わせ直す（RFC 7766）。

本文は，UDP で送れる場合を先に述べ，「最大のメッセージサイズを超えるとき」と「EDNS に対応していない権威 DNS サーバと 512 バイトを超える」ときを並べている。どちらも UDP の上限を超える場合なので，残る送受信の手段は TCP である。

間違えやすい点。「TCP 53番ポート」までは要らない。フラグメント（IP の分割）で送る，と考えるのは誤りで，DNS は大きなメッセージを TCP に切り替えて送る。

本文の根拠

図5

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 の3行。

図5

example.net. 172800 IN NS ns1.example.net.，example.net. 172800 IN NS ns2.example.net. の2行。

図5 注記1

saas.example.com. は，V 社 SaaS の FQDN である。

ANSWER SECTION から追う。saas.example.com. は CNAME（別名）で，正式な名前は dual-saas.example.net. である。その dual-saas.example.net. に AAAA レコードが2件あるので，V 社 SaaS の IPv6 アドレスは 2001:db8:xxxx::10 と 2001:db8:xxxx::20 の両方である。

権威 DNS サーバは AUTHORITY SECTION の NS レコードで分かる。AAAA レコードをもつ名前は example.net. ゾーンにあり，その NS が ns1.example.net. と ns2.example.net. である。ADDITIONAL SECTION の A レコード（198.51.100.α，β）は，この2台の IPv4 アドレスを添えたもの（グルー）で，FQDN ではない。

間違えやすい点。設問は「全て」に下線を引いている。AAAA も NS も2件ずつあるので，片方だけでは足りない。saas.example.com. の権威サーバ（example.com. の NS）はこの応答に載っていないので，図にない名前を推測で書かないこと。FQDN は末尾のドットまで図5のとおりに書く。

本文の根拠

〔IPv6 の名前解決〕

AAAA レコードと A レコードの応答をほぼ同じタイミングで受信した場合には，IPv6 を優先して通信を行います。

〔IPv6 の名前解決〕

IPv6 と IPv4 の両方に対応する Web サイトの名前解決を行う場合に，PC は AAAA レコードと A レコードを用いて名前解決を要求することで，IPv6 アドレスと IPv4 アドレスの両方を取得します。

〔IPv6 の名前解決〕

③IPv6 のネットワークだけが不通となった場合に，利用している OS や Web ブラウザによっては従業員が異常に気付くことができず，情報システム部に異常を連絡できない可能性があると P 主任は考えた。

デュアルスタックの PC は，IPv6 と IPv4 の両方のアドレスを取得し，IPv6 を優先して接続を試みる。IPv6 で接続できないと，IPv4 で接続し直す。これをフォールバックといい，OS やブラウザは待ち時間を短くするために両方を並行して試す仕組み（Happy Eyeballs，RFC 8305）を実装している。

本文の R 係長の説明のとおり，PC は AAAA と A の両方を取得しており，IPv6 だけが不通なら IPv4 で同じ Web ページが開く。利用者から見ると普段どおり使えるので，異常に気付かない。講評も「IPv4 で同じ Web ページにアクセスできることがあり，異常に気付きづらい」と書いている。本文が下線の直後で監視サーバを置くことにしたのはこのためである。

45字に収める。解答例は「IPv4にフォールバックしてSaaSの同じWebページにアクセスするから」で36字。「IPv4 に切り替わる」ことと「同じページが見える（利用者から違いが分からない）」ことの両方を入れる。講評はこの設問の正答率が低かったとしている。

採点講評（IPA）

設問3では，(3)の正答率が低かった。IPv4とIPv6のデュアルスタックのネットワークでは，IPv6のネットワークに障害が発生しても，IPv4で同じWebページにアクセスできることがあり，異常に気付きづらい。IPv6のネットワークを設計する際には，監視方法についても考慮が必要になることを理解してほしい。

本文の根拠

図6 アドレス一覧

ルータA：a は fe80::1/64，GUA は未割当て。ルータB：b は fe80::2/64，未割当て。c は fe80::1/64，未割当て。FW：d は fe80::2/64，未割当て。

図6の概要

ルータB には，ルータA の LLA をネクストホップとするデフォルトルートを設定する。

図6の概要

OSPFv3 では LLA を用いて隣接関係を確立して IPv6 の経路制御を行うので

a〜d は，ルータA とルータB の間，ルータB と FW の間のインタフェースである。LLA はリンクの外へ転送されない（RFC 4291 2.5.6節）ので，GUA を付けなければ，インターネットのどこからもこれらのインタフェースを宛先にしたパケットは届かない。ルータや FW そのものを外部からの攻撃（管理画面へのアクセスなど）にさらさないために，GUA を割り当てない。

それでも経路制御は成り立つ。本文のとおり，ルータB のデフォルトルートはルータA の LLA をネクストホップにしており，ISP のルータA もルータB の LLA をネクストホップにした静的経路をもつ。OSPFv3 も LLA で隣接関係を結ぶ（RFC 5340）。転送に必要なのはネクストホップの LLA だけなので，GUA は無くてよい。

50字に収める。解答例は「インターネットからルータA，ルータB及びFWにアクセスできないようにするため」で38字。守る対象（ルータA，ルータB，FW）と，何から（インターネットから）を書く。「GUA が不要だから」は理由であって目的ではない。

本文の根拠

図6の概要

④FW と各拠点の L3SW との間の，PC やサーバを接続しないネットワークに GUA を割り当てる必要はないが，静的に割り当てる

〔IPv6 の名前解決〕

データセンターに監視サーバを導入して，IPv6 のインターネットへのアクセスや，各拠点の L3SW の GUA に対して ping6 コマンドによる監視を行うことにした。

経由するネットワーク機器を調べるコマンドは traceroute（IPv6 では traceroute6）である。traceroute6 はホップリミットを1から順に増やしてパケットを送り，途中の機器が返す ICMPv6 Time Exceeded（RFC 4443 3.3節）の送信元アドレスを並べて経路を表示する。

このとき返ってくる送信元アドレスが，機器ごとに決まった GUA であれば，表示されたアドレスからどの機器を通ったかがすぐ分かる。静的に割り当てるのは，アドレスが変わらず，一覧（図6の表）と突き合わせられるようにするためである。監視サーバから拠点の L3SW へ ping6 を打つ運用とも組み合わせて，障害のあった区間を切り分けやすくなる。

45字に収める。解答例は「traceroute6を利用して調べるときに各機器を識別しやすくする。」で35字。設問が指定するコマンド名を必ず入れる。講評はこの設問の正答率は平均的だったとして，traceroute が切り分けに役立つことを挙げている。

採点講評（IPA）

設問4では，(2)の正答率は平均的であった。tracerouteコマンドは，pingコマンドと同様にネットワークの状態確認やトラブルシューティングにおいて非常に有用なツールである。障害発生時の切り分けや早期復旧にも役立つので，ネットワーク関連のコマンドやツールを使いこなすスキルを身に付けてほしい。

本文の根拠

図6の概要

⑤PC は，SLAAC を用いて IPv6 アドレス及びデフォルトルータを設定する。

図3の処理(ⅲ)

(ⅲ) ノード1は，RS メッセージを全ルータマルチキャストアドレス宛てに送信する。

図3の処理(ⅳ)

(ⅳ) RS メッセージを受信したノード3は，GUA の生成に用いるサブネットプレフィックス，及びデフォルトルータを決定するための情報を RA メッセージに入れて，ノード1宛てに送信する。

SLAAC で PC が GUA とデフォルトルータを決めるには，ルータから RA を受け取る必要がある。PC は起動時に RS を全ルータマルチキャストアドレス宛てに送り，これを受けたルータが RA を返す（RFC 4861 6.2.6節）。拠点1では，ノード3が L3SW1 なので，各拠点の L3SW がこの役を担う。

本文の図3がこの手順そのもので，(ⅲ)で PC が RS を送り，(ⅳ)で L3SW1 がサブネットプレフィックスとデフォルトルータを決める情報を RA で返す。設問は「ICMPv6 のメッセージ名を用いて」とあるので，RS と RA の名前を使って書く。

40字に収める。解答例は「PCが送信したRSメッセージに対してRAメッセージを応答する。」で31字。L3SW は RS を受けなくても定期的に RA を送る（RFC 4861 6.2.4節）が，本文の図3の流れに沿って RS への応答として書けばよい。

本文の根拠

図6 アドレス一覧

ルータA：a は fe80::1/64，GUA は未割当て。ルータB：b は fe80::2/64，未割当て。c は fe80::1/64，未割当て。FW：d は fe80::2/64，未割当て。e は fe80::1/64，2001:db8:yyyy:1::1/64。f は fe80::1/64，2001:db8:yyyy:2::1/64。L3SW1：g は fe80::2/64，2001:db8:yyyy:2::2/64。h は fe80::1/64，2001:db8:yyyy:3::1/64。

図6の概要

ルータB には，ルータA の LLA をネクストホップとするデフォルトルートを設定する。

S 課長との会話

項番3と項番5は，拠点1のネットワーク宛ての経路情報です。項番4と項番6は，ルータB から配布されるデフォルトルートによって登録される経路情報です。

LLA は同じリンク上でしか意味をもたないので，ネクストホップは「隣の機器の，こちら側のインタフェースの LLA」，出口は「自分の，そのリンクにつながるインタフェース」になる。fe80::1 が a にも c にも e にもあるように，LLA はリンクごとに重複してよい。

項番1（ルータB のデフォルトルート）はルータA へ向かう。隣はルータA の a（fe80::1），出口はルータB の b。ア＝fe80::1，イ＝b。項番3（ルータB から拠点1の 2001:db8:yyyy:3::/64）は FW へ向かう。隣は FW の d（fe80::2），出口は c。ウ＝fe80::2，エ＝c。項番4（FW のデフォルトルート）はルータB へ向かう。隣はルータB の c（fe80::1），出口は d。オ＝fe80::1，カ＝d。項番5（FW から 3::/64）は L3SW1 へ向かう。隣は L3SW1 の g（fe80::2），出口は f。キ＝fe80::2，ク＝f。項番6（L3SW1 のデフォルトルート）は FW へ向かう。隣は FW の f（fe80::1）で，出口は表にあるとおり g。ケ＝fe80::1。

間違えやすい点。自分のインタフェースの LLA をネクストホップに書いてしまうこと（出口が c なら，ネクストホップは c の向かいの d）。拠点宛ての経路でも，ネクストホップに GUA（2001:db8:yyyy:2::2 など）ではなく LLA を書く。OSPFv3 が LLA で経路を交換するからである（RFC 5340）。

本文の根拠

P 主任の説明

ISP のルータA には，ルータB の LLA をネクストホップとする 2001:db8:yyyy::/48 宛ての静的経路が設定されます。

表1 項番1・2

項番1 ルータB，静的経路制御，::/0，ネクストホップは［ ア ］，出口は［ イ ］。項番2 ルータB，静的経路制御，2001:db8:yyyy::/48，ネクストホップはなし，出口は Null（注1）。

P 主任の説明

⑥項番2の経路情報を設定しない場合，ルーティングループが発生します

未使用の GUA（たとえば 2001:db8:yyyy:ff::1）宛てのパケットをたどる。ルータA は /48 の静的経路に従ってルータB へ送る。ルータB には，社内で使っている /64（1::〜3::）の経路はあるが，未使用のサブネットの経路は無い。項番2が無ければデフォルトルート（項番1）に当たり，ルータA へ送り返す。ルータA はまた /48 でルータB へ送る。これがルーティングループである。

ループは永遠には続かない。IPv6 ヘッダーのホップリミット（RFC 8200。IPv4 の TTL に当たる）は，ルータが転送するたびに1減り，0になったパケットは廃棄される（ICMPv6 Time Exceeded を返す。RFC 4443 3.3節）。項番2の Null 経路があれば，ルータB は /48 の中の未使用アドレス宛てをその場で捨てるので，往復は起きない。

35字に収める。解答例は「ホップリミットが0になるまで相互に転送し合い，廃棄する。」で28字。「ルータA とルータB の間で行き来する」ことと「ホップリミットが0で廃棄される」ことの両方を書く。

本文の根拠

P 主任の説明

⑦項番1と項番2の両方の経路情報に該当する IP パケットの転送では，ルータB は項番2の経路情報を選択します

表1 項番1・2

項番1 ルータB，静的経路制御，::/0，ネクストホップは［ ア ］，出口は［ イ ］。項番2 ルータB，静的経路制御，2001:db8:yyyy::/48，ネクストホップはなし，出口は Null（注1）。

ルータは，宛先に当てはまる経路が複数あるとき，プレフィックス長が最も長い（最も具体的な）経路を選ぶ。これをロンゲストマッチ（最長一致）という。

項番1の ::/0 はプレフィックス長0で全ての宛先に当てはまる。項番2の 2001:db8:yyyy::/48 は長さ48で，Q 社のアドレスだけに当てはまる。両方に当たるパケット（Q 社のアドレス宛て）では，長い /48 の項番2が選ばれる。さらに社内で使っている /64（項番3など）があれば，そちらがもっと長いので優先され，項番2は「使っていない残り」だけを受け持つ。

25字に収める。解答例は「ロンゲストマッチによって選択されるから」で19字。「プレフィックス長が長い経路が優先されるから」でも同じ意味になる。どちらも静的経路なので，アドミニストレーティブディスタンスやメトリックの比較で決まるのではない。

本文の根拠

図1の概要

ルータB にはデフォルトルート及び NAPT を設定している。

S 課長との会話

IPv4 のネットワークでは FW によるアクセス制御に加えて，ルータB に i を設定しているので，インターネットから社内ネットワークには簡単に通信できない設計になっています。

現状のルータB には，図1の概要に書かれているとおり NAPT が設定されている。NAPT（RFC 3022）は，社内のプライベートアドレスとポート番号を，グローバルアドレス1つと別のポート番号に対応付けて変換する。対応表は社内から外へ出た通信で作られるので，外から始まる通信には変換先が無く，社内に届かない。これが「簡単に通信できない」理由である。

IPv6 では，全ての PC に GUA を割り当てるので，アドレス変換をしない。インターネットから社内の PC の GUA を宛先にしたパケットがそのまま届きうるので，FW のアクセス制御だけが防壁になる。本文が「慎重に検討する必要があります」と言うのはこのためである。

間違えやすい点。「NAT」と答えると，アドレスだけを1対1で変換する方式も含み，本文の図1の概要にある語とも違う。本文に出てくる語をそのまま使って NAPT と書く。

本文の根拠

P 主任の説明

例えば，中継する機器が MTU サイズよりも大きいサイズの IP パケットを転送できないときに，⑧中継する機器から送信元にタイプ2の ICMPv6 メッセージである“Packet Too Big”を送信する PMTUD（Path MTU Discovery）に利用されています。

IPv6 では，ルータはパケットを分割（フラグメント）しない。送信元だけが分割できる（RFC 8200 4.5節）。そこで送信元は，経路上で通せる最大のパケットサイズ，つまり経路上の各リンクの MTU のうち最も小さい値（パス MTU）を知っておく必要がある。これを求めるのが PMTUD（RFC 8201）である。

送信元が大きなパケットを送り，途中の機器が次のリンクの MTU を超えると判断すると，Packet Too Big（ICMPv6 タイプ2，RFC 4443 3.2節）にそのリンクの MTU を入れて送信元へ返す。送信元はその値に合わせて送り直し，これを繰り返して最小の MTU に行き着く。FW がこの ICMPv6 を拒否すると，送信元は MTU を知ることができず，大きなパケットだけが届かない障害になる。

20字に収める。解答例は「通信経路における最小のMTU」で14字。「パス MTU」と答えても同じ意味だが，何を指すか（経路上の最小の MTU）まで書くほうが確実。

本文の根拠

〔IoT 向けの無線技術の調査と無線回線の選定〕

IoT 向けには，LPWA（Low Power Wide Area）と呼ばれる，低 a 電力の無線通信技術が利用される。

〔IoT 向けの無線技術の調査と無線回線の選定〕

LPWA は，セルラー系と非セルラー系の二つに大別される。b 系には LoRaWAN，Sigfox などがあり，c 系には LTE-M（LTE Cat.M1），NB-IoT（LTE Cat.NB1）などがある。

〔IoT 向けの無線技術の調査と無線回線の選定〕

920 MHz 帯は Wi-Fi が利用する周波数帯と同様に，d バンドと呼ばれる周波数帯であるが，2.4 GHz 帯と比べて電波 e の影響が少ない。

〔IoT 向けの無線技術の調査と無線回線の選定〕

LTE-M，NB-IoT は，f と呼ばれる標準化プロジェクトが作成した技術仕様を基に，通信事業者が全国規模で構築した LTE 網でサービスが提供されている。

a は LPWA の Low Power を訳した「低消費電力」の「消費」。b と c は，携帯電話網（セルラー網）を使うかどうかで分ける。LTE-M・NB-IoT は通信事業者の LTE 網（セルラー網）を使うのでセルラー系，LoRaWAN・Sigfox は自前の基地局やゲートウェイで 920MHz 帯を使うので非セルラー系。本文は b に LoRaWAN，c に LTE-M を置いているので，b＝非セルラー，c＝セルラーの順になる。

d は，産業・科学・医療（Industrial, Scientific and Medical）用に割り当てられた ISM バンド。Wi-Fi の 2.4GHz 帯はこれに当たり（ITU 無線通信規則 5.150），無線局の免許なしで多くの機器が使う。本文は 920MHz 帯も同様に ISM バンドと呼ばれるとしている。e は，同じ周波数を多くの機器が使うことで起きる電波の「干渉」。2.4GHz 帯は Wi-Fi や Bluetooth，電子レンジなどが混み合うのに対し，920MHz 帯はそれより空いている。f は，LTE などの移動体通信の技術仕様を作る標準化プロジェクト 3GPP（3rd Generation Partnership Project）。LTE-M と NB-IoT は 3GPP の Release 13 で仕様化された。

講評は d と f の正答率が低かったとしている。b と c は順番を取り違えやすい（空欄の直後に並ぶ技術名で決める）。e は「減衰」と迷うが，本文は 2.4GHz 帯との比較で「影響が少ない」としており，周波数が混み合うことによる問題なので干渉である。

採点講評（IPA）

設問１では，dとfの正答率が低かった。Wi-Fiなどで利用する2.4GHz帯と920MHz帯はISM（Industrial Scientific and Medical）バンドに割当てられていること，LTEなどの移動体通信の技術仕様は3GPPで作成されていることは覚えておいてほしい。

本文の根拠

〔Z 社の IoT 向け通信サービスの調査〕

図1中の IPsec ルータ1で動作する IKEv2 は，IPsec ルータ2との間で，四つのメッセージの交換を g 往復で行い，SAD（Security Association Database）を作成する。

〔Z 社の IoT 向け通信サービスの調査〕

IPsec ルータ1の SPD（Security Policy Database）中のセレクターには，h 宛てのパケットを受信したとき，SAD を参照して IPsec の処理を行うことが設定されている。

〔Z 社の IoT 向け通信サービスの調査〕

G メーターには，通信事業者が契約者を識別する情報を記録している i カードを装着する。

〔Z 社の IoT 向け通信サービスの調査〕

G メーター1台当たりの1回の検針時の通信量を 100 バイトとし，1時間ごとに検針を実施する。

〔Z 社の IoT 向け通信サービスの調査〕

通信費は1か月の通信量 1,000 バイト当たり1円とし，G メーターごとに割り当てる1回線当たりの基本料金は月額 300 円とする。

〔Z 社の IoT 向け通信サービスの調査〕

CoAP は，Web システムにおける API の形式である k アーキテクチャを採用しているので，Web 技術で IoT システムを構築する場合に適している。

g：IKEv2 は IKE_SA_INIT と IKE_AUTH の2つの交換で SA を作る。それぞれ要求と応答の1往復なので，4つのメッセージを2往復でやり取りする（RFC 7296 1.2節）。h：IPsec ルータ1が IPsec で保護して送るのは，G メーターから Y 社サービス拠点へ向かうパケット，つまり図1で IPsec ルータ2の先にある G メーター管理サーバ宛てのパケットである。i：通信事業者が契約者を識別する情報を記録したカードは SIM（Subscriber Identity Module）カード。

j は計算する。1台の1日の通信量は 100 バイト × 24 回＝2,400 バイト，30 日で 72,000 バイト。1,000 バイト当たり1円なので通信費は 72 円。基本料金 300 円を足して 372 円になる。k：CoAP は Web と同じくリソースを URI で指定し，GET・POST・DELETE などのメソッドで操作する REST の考え方に沿っている（RFC 7252 の冒頭は“RESTful”な環境向けの Web 転送プロトコルと説明している）。本文の表1にもメソッドコードが並んでいる。

間違えやすい点。g は「メッセージの数（4）」ではなく往復の数を問うている。h は IP アドレスではなく機器名で答える（本文には IP アドレスが出てこない）。j は基本料金の足し忘れと，1日24回（1時間ごと）の掛け忘れに注意。k は空欄の後ろが「アーキテクチャ」なので REST でも意味は通るが，解答例は RESTful。

本文の根拠

〔CoAP の調査〕

CoAP は，l 層のプロトコルである UDP 上での動作を前提としている。通信品質の劣るネットワークなどでは，パケットが m で到着したり，n して出現したり，通知なしに消失したりすることがあるので

〔CoAP の調査〕

CoAP では，図3中の(ⅰ)に示したように，ACK の受信を待たずに連続して CON を送信することができる，非 o 通信が行われる。

〔CoAP の調査〕

ACK が受信できなかった場合は，指数 p と呼ばれる方式で算出した b の時間経過後に CON を再送する。

l：UDP は TCP と並ぶトランスポート層のプロトコル。m・n：RFC 7252 の4節は，CoAP が UDP のような信頼性の無いトランスポートに載るため，メッセージが順序どおりでなく到着したり，重複して現れたり，通知なく失われたりしうると述べている。本文の文はこれに当たり，m は「順不同」，n は「重複」。

o：図3の(ⅰ)では，サーバ1への CON の ACK を待たずにサーバ2へ CON を送っている。応答を待たずに次へ進むやり方は非同期通信である（RFC 7252 の冒頭も CoAP が非同期のメッセージ交換を扱うとしている）。p：RFC 7252 4.2節では，CON を送ったら ACK_TIMEOUT（既定2秒）に乱数係数（既定1.5まで）を掛けた時間だけ待ち，届かなければ再送し，再送のたびに待ち時間を2倍にする。これが指数バックオフ（exponential back-off）で，図3(ⅱ)の a が最初の待ち時間，b がその後の待ち時間に当たる。

講評は p の正答率が低かったとしている。講評のとおり，バックオフはイーサネット（CSMA/CD の衝突後の再送）でも使われる考え方である。o は空欄の前に「非」があるので「同期」だけを書く。m は「順番どおりでない」の意味を3字で表した「順不同」。

採点講評（IPA）

設問３では，(1）のp及び(6)の“判断できること”の正答率が低かった。pのバックオフは，再送時の成功率を高めるためにイーサネットでも利用されている技術なので，覚えておいてほしい。DTLSのハンドシェークに対する攻撃には複数のパターンが考えられるが，“判断できること”では，cookieの作成方法を基に，正答を導き出してほしい。

本文の根拠

図5

(ⅰ) 機器からサーバへ CON〔0xbc90〕GET /data1（トークン 0x71）。

図5

(ⅳ) サーバから機器へ ACK〔0xbc90〕。

図5

(ⅷ) サーバから機器へ CON〔0xcdf2〕2.05 Content（トークン 0x71）“データ Z”。

〔CoAP の調査〕

CoAP クライアントはトークンの値によって，どの要求に対して応答された情報なのかを判断する。

(ⅳ)は(ⅰ)と同じメッセージ ID 0xbc90 の ACK だが，データ（Content）が付いていない空の ACK である。サーバは「要求は受け取った」とだけ返し，データの用意ができてから改めて送る。RFC 7252 5.2.2節の Separate Response（分離応答）で，後から送る応答は新しい CON になる。

図5で後から来るのは(ⅷ)の CON〔0xcdf2〕で，2.05 Content とデータ Z を運んでいる。メッセージ ID は 0xcdf2 で(ⅰ)とは違うが，トークンが 0x71 で(ⅰ)のトークンと同じである。本文のとおり，どの要求への応答かはトークンで判断するので，(ⅷ)が(ⅰ)への応答だと分かる。(ⅸ)の ACK は，機器がこの CON を受け取ったことをサーバに知らせている。

理由は15字に収める。解答例は「トークン値が一致するから」で12字。「メッセージ ID が一致するから」は誤り。メッセージ ID はメッセージ1つごとの確認（CON と ACK の対応）に使うもので，分離応答では変わる。

本文の根拠

図5

(ⅱ) 機器からサーバへ CON〔0xab20〕GET /data2（トークン 0x82）。

図5

(ⅴ) サーバから機器へ ACK〔0xab20〕2.05 Content（トークン 0x82）“データ X”。

〔CoAP の調査〕

このように，CoAP では，ACK に Content のデータを加えて送信する，ピギーバックと呼ばれる応答方式が利用される。

(ⅱ)の CON はメッセージ ID 0xab20，トークン 0x82 である。これに対する ACK は同じメッセージ ID をもつ(ⅴ)で，2.05 Content とデータ X が載っている。要求を受けてすぐデータを送れたので，ACK にデータを載せて返すピギーバック応答（RFC 7252 5.2.1節）になっている。

本文の図4の説明と同じ形である。図4でも CON〔0x1234〕に対して ACK〔0x1234〕が 2.05 Content とデータ A を運んでいた。対照的に(ⅰ)への ACK である(ⅳ)はデータを載せていないので，下線①の「すぐに送信できない場合」に当たる。

間違えやすい点。(ⅱ)に対応するかどうかはメッセージ ID（0xab20）で見る。トークン 0x82 も一致するが，ACK と CON を結び付けるのはメッセージ ID である。(ⅵ)と(ⅶ)は(ⅲ)への応答なので選ばない。

本文の根拠

図5

(ⅵ) サーバから機器へ ACK〔0xde10〕2.05 Content（トークン 0x90）“データ Y”。(ⅶ) ACK〔0xde10〕2.05 Content（トークン 0x90）“データ Y”が機器に届く。

〔CoAP の調査〕

メッセージ ID は，要求と応答のメッセージを関連付けるとともに，メッセージの重複を検出するのに使用される。

〔CoAP の調査〕

(ⅶ)は，ネットワーク上の何らかの原因によって，(ⅵ)と重複した ACK が機器に到達したことを示している。

(ⅵ)と(ⅶ)はどちらもメッセージ ID が 0xde10 である。本文のとおり，メッセージ ID はメッセージの重複を検出するのに使う。同じ ID の ACK を2度受け取ったので，後の(ⅶ)は重複だと判断できる。

処理の側は，RFC 7252 4.5節の考え方どおり，同じメッセージは一度だけ処理する。(ⅵ)を受け取った時点で(ⅲ)の要求は完了しており，データ Y も取得済みである。(ⅶ)を改めて処理するとデータを二重に扱うことになるので，(ⅶ)は処理済みのものとして捨てる（無視する）。ACK に対してさらに ACK を返すことは無い。

それぞれ30字に収める。解答例は理由が「二つのパケットのメッセージIDが同じだから」で21字，処理が「受信した(ⅶ)のACKは処理済みなので無視する。」で24字。理由に「トークンが同じ」と書くのは不十分。トークンは要求と応答を結ぶもので，別々のメッセージでも同じ値になりうる（(ⅲ)の CON と(ⅵ)の ACK も同じトークン）。

本文の根拠

〔CoAP の調査〕

④攻撃者が(ⅰ)の ClientHello メッセージの送信元を偽装して送信した場合，TLS サーバはパケットサイズの大きな(ⅱ)の ServerHello メッセージを返送することになり，TLS サーバが DDoS 攻撃の加害者になるおそれがある

〔CoAP の調査〕

CoAP は，伝送効率を考慮して標準では UDP を利用し

UDP にはコネクションの確立が無いので，送信元 IP アドレスを偽ったパケットでもサーバはそのまま受け付けて応答する。攻撃者は ClientHello の送信元 IP アドレスを攻撃対象のホストの IP アドレスに書き換えて送る。サーバの ServerHello（証明書などを含む大きな応答）は攻撃対象に届く。小さな要求で大きな応答を送らせるので，攻撃者の送信量より多くのトラフィックを攻撃対象に浴びせられる。

第三者のサーバに応答を「反射」させて攻撃対象を狙うこの手法をリフレクション攻撃（応答が大きくなる点を強調してアンプ攻撃，増幅攻撃とも）という。RFC 9147 5.1節も，偽った送信元アドレスで接続開始のメッセージを送り，サーバを増幅器として使う攻撃を挙げている。本文の「TLS サーバが DDoS 攻撃の加害者になる」はこのことである。

内容は40字に収める。解答例は「送信元IPアドレスを，攻撃対象のホストのIPアドレスに偽装する。」で32字。「何を」（送信元 IP アドレスを）「何に」（攻撃対象のホストのアドレスに）の両方を書く。「送信元を偽装する」だけでは下線の言い換えにしかならない。

本文の根拠

〔CoAP の調査〕

(ⅰ)の ClientHello メッセージを受信した DTLS サーバが，(ⅱ)の HelloRetryRequest メッセージに cookie を添付して送信する。(ⅱ)を受信した DTLS クライアントは，受信した cookie を添付した(ⅲ)の ClientHello メッセージを再度送信する。

〔CoAP の調査〕

⑤DTLS サーバは，(ⅲ)に添付された cookie を検査し，cookie が不正な場合は対応する処理を行う。

図6

(ⅳ) DTLS サーバから DTLS クライアントへ ServerHello，以下，省略。

サーバは cookie を(ⅱ)でクライアントの IP アドレス宛てに送る。正しい cookie を添えた(ⅲ)が返ってくるのは，(ⅱ)を実際に受け取れた相手，つまり(ⅰ)の送信元 IP アドレスに本当にいるクライアントだけである。送信元を偽った攻撃者には(ⅱ)が届かないので，正しい cookie を返せない。RFC 9147 5.1節も，cookie によって攻撃者・クライアントが cookie を受け取れることを強制し，偽った IP アドレスによる DoS 攻撃を難しくすると説明している。

cookie が不正なら，(ⅰ)の送信元は偽装されていた疑いがある。大きな ServerHello（(ⅳ)）を送れば④の攻撃に加担するので，送らずにハンドシェークを打ち切る。RFC 9147 5.1節は，不正な cookie の ClientHello を受けたサーバは illegal_parameter アラートでハンドシェークを終了しなければならないとしている。

それぞれ30字に収める。解答例は判断できることが「(ⅰ)の送信元が，偽装されたものでないこと」で21字，対応が「(ⅳ)を送信せず，ハンドシェークを終了する。」で22字。講評は「判断できること」の正答率が低かったとし，cookie の作成方法（相手の IP アドレスに結び付けて作る）から考えるよう求めている。「cookie が改ざんされていない」では，何を確かめたのかが言えていない。

採点講評（IPA）

設問３では，(1）のp及び(6)の“判断できること”の正答率が低かった。pのバックオフは，再送時の成功率を高めるためにイーサネットでも利用されている技術なので，覚えておいてほしい。DTLSのハンドシェークに対する攻撃には複数のパターンが考えられるが，“判断できること”では，cookieの作成方法を基に，正答を導き出してほしい。

本文の根拠

〔IoT システムの機能と構成の検討〕

G メーター管理サーバは数万台の G メーターを管理することを前提に

〔IoT システムの機能と構成の検討〕

⑥ランダムな時間経過後に，前日に測定した1時間ごとの測定データを 24 回に分けて G メーター管理サーバに送信する

〔IoT システムの機能と構成の検討〕

毎日午前0時の測定を行った後，1時までの間のランダムな時間経過後に，1時間ごとに記録した1日分 24 件の測定データを，それぞれ POST メソッドで G メーター管理サーバに送信する。

G メーターは数万台あり，どれも午前0時に測定する。測定の直後に一斉に送信すると，数万台分の通信が同じ瞬間に G メーター管理サーバと閉域網（LTE 網，IPsec VPN）に集中する。1台ずつ 0時〜1時の間のランダムな時刻にずらせば，送信が1時間に散らばり，負荷がならされる。

本文は「数万台」を前提に置き，送信を「1時までの間のランダムな時間経過後」としている。さらに1台当たり 24 回に分けて送るので，同時に送れば数十万件の要求が重なる。集中すれば，サーバの処理が追いつかなかったり，パケットが失われて CoAP の再送が重なり，さらに混み合ったりする。

35字に収める。解答例は「Gメーター管理サーバやネットワークへの負荷の集中が避けられる。」で31字。サーバとネットワークの両方を挙げ，「集中を避ける（分散させる）」ことを書く。

本文の根拠

要件(2)

(2) G メーターは電池で動作させるので，長時間の稼働を可能にすること

〔IoT システムの機能と構成の検討〕

⑦LP ガスの流量積算値の測定又は測定データ送信後，次の測定を行う時刻までの間は，G メーターはスリープ状態になる。

G メーターは電池で動くので，電池の持ちがそのまま稼働時間になる。測定も送信もしていない時間に回路や無線を止めておけば，電力をほとんど使わない。1時間ごとの測定と1日1回の送信の間の大半をスリープにすることで，消費電力を抑えられる。

本文冒頭の要件(2)が「電池で動作させるので，長時間の稼働を可能にすること」としており，スリープはこの要件に応えるための動作である。LPWA が「低消費電力」の無線通信技術である（設問1の a）のも同じ狙いである。

25字に収める。解答例は「Gメーターの消費電力を抑えることができる。」で21字。「電池が長持ちする」「長時間稼働できる」も同じ効果だが，消費電力を抑えることが直接の効果で，長時間稼働はその結果である。

本文の根拠

〔IoT システムの機能と構成の検討〕

これによって，図7中の(1)では，G メーターが POST メソッドを 24 回発行することになる。

〔IoT システムの機能と構成の検討〕

⑧CoAP でやり取りされる IP パケットの数は，HTTP バージョン 1.1 を利用して同様の方法で測定データを送信する場合と比べると少ないので，測定データの通信時間は短くて済む。

〔CoAP の調査〕

CoAP は，伝送効率を考慮して標準では UDP を利用し

HTTP/1.1 は TCP の上で動く。TCP では，データを送る前に3ウェイハンドシェーク（SYN，SYN/ACK，ACK）でコネクションを確立し，終わったら FIN と ACK でコネクションを切断する（RFC 9293）。データそのもの以外に，このためのパケットがやり取りされる。

CoAP は UDP を使うので，コネクションの確立も切断も無い。図7の(1)では1件の測定データにつき CON と ACK の2パケットで済む。HTTP/1.1 で同様に 24 件を送れば，その都度（あるいは少なくとも最初と最後に）コネクションの確立と切断のパケットが加わり，数が多くなる。講評もこの点に着目するよう求めている。

35字に収める。解答例は「TCPコネクション確立とコネクション切断の処理が行われるから」で30字。確立と切断の両方を書く。講評はこの設問の正答率が低かったとしている。「ヘッダーが大きいから」はパケットの大きさの話で，パケットの数が多くなる理由ではない。

採点講評（IPA）

設問４では，(3)の正答率が低かった。CoAPとHTTPバージョン1.1では利用するトランスポート層のプロトコルが異なる。TCPでは，UDPでは行われないコネクションの確立とコネクションの切断のためのパケットが発生することに着目して，正答を導き出してほしい。

本文の根拠

〔Z 社の IoT 向け通信サービスの調査〕

Z 社は，GW とルータとの間を専用線で接続し，Z 社サービス拠点と Y 社サービス拠点との間は IPsec VPN で接続することによって，Y 社向けの閉域網を構成する。

図9 注記1

図中の網掛けは，CoAP 通信を行う機器を示す。

〔IoT システムの機能と構成の検討〕

⑨今回開発する IoT システムでは，DTLS を利用しなくても CoAP 通信のセキュリティは確保されると判断し，DTLS は利用しないことにした

CoAP 通信を行うのは，図9で網掛けされた G メーターと G メーター管理サーバだけである。その間の経路は，LTE-M の LPWA 閉域接続サービス，GW とルータの間の専用線，インターネット上は IPsec VPN で，Z 社が Y 社向けに作った閉域網の中に収まっている。

閉域網の外の第三者は CoAP のパケットに触れられず，インターネットを通る区間も IPsec で暗号化されている。DTLS で G メーターと管理サーバの間を改めて暗号化しなくても，盗聴や改ざんから守られていると判断できる。本文が DTLS を使わない理由として挙げる G メーターの処理負荷とも両立する。

30字に収める。解答例は「CoAP通信は，Y社向けの閉域網の中で行われるから」で25字。「IPsec VPN で暗号化されるから」だけでは，LTE-M と専用線の区間が抜ける。閉域網という本文の語を使うと全区間をまとめて言える。

本文の根拠

〔IoT システムの機能と構成の検討〕

G メーターは図8に示した動作を行うので，時計機能の実装が必要になる。

〔IoT システムの機能と構成の検討〕

G メーターは1時間ごとに LP ガスの流量積算値を測定して，測定時刻と測定値（以下，測定データという）をメモリに記録し，毎日午前0時の測定の後

〔IoT システムの機能と構成の検討〕

2時から G メーターごとに LP ガス消費量などを集計する。

G メーターは自分の時計に従って，毎正時に測定し，午前0時の測定の後に送信する。時計が進んだり遅れたりすると，測定がずれた時刻に行われ，記録される測定時刻も実際とずれる。送信も0時〜1時の間から外れうる。

本文の運用は時刻を前提にしている。G メーター管理サーバは2時から集計を始めるので，時計が大きく遅れた G メーターの送信は集計に間に合わない。1時間ごとの測定値も，時刻がずれていれば正しい時間帯の使用量にならない。

30字に収める。解答例は「測定と送信が誤った時刻に行われることになる。」で22字。測定と送信の両方を挙げる。「時刻がずれる」だけでは下線⑩の言い換えで，ずれによって何が起きるかが書けていない。

本文の根拠

〔IoT システムの機能と構成の検討〕

⑪G メーターに時刻の誤差を抑えるための処理を組み込むことにした

図9 の説明

図9中の Y 社サービス拠点のサーバは，NTP サーバとの間で時刻同期を行う。

図9 注記1

図中の網掛けは，CoAP 通信を行う機器を示す。

時刻の誤差を抑えるには，正しい時刻をもつ相手から時刻を受け取り，自分の時計を合わせ直せばよい。本文によれば，Y 社サービス拠点のサーバは NTP サーバと時刻同期しているので，G メーター管理サーバは正確な時刻をもっている。

G メーターが通信できるのは CoAP で G メーター管理サーバとだけである（図9の網掛け）。NTP サーバは DMZ にあり，G メーターから直接は使わない構成になっている。そこで，G メーターが CoAP の GET で管理サーバから現在時刻を取得し，それで自分の時計を更新する。1日1回の送信の機会などに行えば，誤差が積み重なる前に正せる。

40字に収める。解答例は「Gメーター管理サーバから現在時刻を取得して，Gメーターの時刻を更新する。」で36字。「どこから」（G メーター管理サーバから）と「何をするか」（時刻を取得して更新する）を書く。設問は「CoAP 通信を利用した処理」としているので，「NTP で同期する」は条件に合わない。