07MACアドレスとは
MACアドレスとは、「Media Access Control Address」の略で、ネットワークに接続されたデバイスが持つ固有の識別番号のことを指します。 このアドレスは、デバイスのネットワークインターフェースカード（NIC）に工場出荷時に割り当てられ、通常は変更されることはありません。MACアドレスは通常、16進数を用いた形式で表され、「00:1A:2B:3C:4D:5E」のように6つのグループに分けられます。これらはコロン（:）またはハイフン（-）で区切られます。MACアドレスの最初の3つのグループ（例では「00:1A:2B」）によりデバイスの製造者を識別できます。残りの3つのグループ（例では「3C:4D:5E」）は製造者が割り当てる固有の番号で、同じ製造者から出された異なるデバイスを識別します。
IPアドレスとMACアドレスの違い
ネットワーク上でのデータの送受信において、各デバイスにはIPアドレスとMACアドレスが割り当てられますが、これらのアドレスは異なる目的で使用されます。IPアドレスはデータパケットが最終的に到達すべき場所を指し示し、MACアドレスはデータがネットワーク上で移動する際に通過する各デバイス、すなわち各乗り換え駅を示します。これにより、データはネットワーク内を効率的かつ正確に移動し、正しいデバイスに届けられます。IPアドレスとMACアドレスは、互いに補完しあいながらネットワーク上でのデータの正確な送受信を可能にします。これらの違いを理解するために、新宿駅から新大阪駅への列車移動を例にして説明します。
IPアドレスの役割
IPアドレスは、列車移動の開始地点である新宿から、最終目的地である新大阪までの全体のルートを指し示します。このアドレスは、データパケットが最終的に到達すべきデバイスの位置、つまりデータが届けられるべき「郵便住所」のようなものです。たとえ途中で乗り換えが必要であっても、IPアドレスは終点の新大阪駅までの切符として機能します。
MACアドレスの役割
一方、MACアドレスは、新宿から新大阪への旅の中で、データパケットが通過する必要がある具体的な目的地、つまり乗り換え駅を示します。例えば、新宿から東京、そして東京から新大阪へと進む場合で説明すると
- 新宿から東京への移動: この区間でデータパケットが向かうべき次の目的地は東京駅です。東京駅のMACアドレスが指定され、新宿駅のネットワークデバイスはこのアドレスに基づいてデータパケットを東京へと送ります。
- 東京から新大阪への移動: 東京駅に到着したデータパケットは次に新大阪へと進みます。この区間での目的地は新大阪駅で、新大阪駅のMACアドレスが次の目的地として設定されます。
IPアドレスとMACアドレスの実践的な運用を知ろう
前節では、MACアドレスとIPアドレスの基本的な説明と、その違いについて詳しく説明しました。本節では、実際のネットワーク間での通信を通じて、これらのアドレスがどのように運用されているかを観察し、理解を深めます。
ネットワーク構成
今回は北海道、東京、大阪、福岡にそれぞれ仮想ネットワークを構成し、各地点にIPアドレスを振り分けています。各地点のネットワークは以下のように設定されています．
| 地点 | インターフェース | IPアドレス |
|---|---|---|
| 北海道 | hokkaido-tokyo | 172.0.2.1/24 |
| 東京 | tokyo-hokkaido | 172.0.2.254/24 |
| 東京 | tokyo-osaka | 174.0.2.1/24 |
| 大阪 | osaka-tokyo | 174.0.2.254/24 |
| 大阪 | osaka-fukuoka | 176.0.2.1/24 |
| 福岡 | fukuoka-osaka | 176.0.2.254/24 |
各地点はルーターとして機能し、次の地点へのデータパケットを適切に転送します。ルーターはネットワーク間のトラフィックを管理し、パケットの経路を決定する重要な役割を担っています。
通信シナリオの設定
北海道にあるデバイスから福岡のデバイスへデータパケットを送信します。このプロセスを監視するため、通信疎通を確認する際に使用する**ping** コマンドでデータパケットを送信し、通信をトレースする際に使用する**tcpdump** コマンドでパケットの中身を確認します。pingコマンド、tcpdumpコマンドについては本節以降に説明しますので、今はMACアドレスとIPアドレスの運用の違いについて着目してください。ネットワーク構成は以下の通りです。
// todo 図がとても分かりにくい
IPアドレスとMACアドレスの運用の違い（確認用）
IPアドレスは、ネットワーク上でデバイスを識別するための論理アドレスです。データが北海道から福岡に送信される際、パケットの送信元および宛先IPアドレスは一貫して北海道（172.0.2.1）と福岡（176.0.2.254）のままです。
一方、MACアドレスは、データリンク層での通信に使用される物理アドレスです。各ネットワークセグメントごとにデータが次のルーターに転送される際、MACアドレスはそのルーターのインターフェースに応じて変更されます。これにより、データがネットワークを通じて正確に伝達されます。では、これらの現象を実際に確認していきましょう．
ping コマンドによるパケット送信
北海道のデバイスから福岡のデバイスへICMPエコーリクエストを送信した際の実行結果です。 これにより、データパケットが指定されたIPアドレスに正確に到達するかを確認します。
$ ip netns exec hokkaido ping 176.0.2.254 -c 3
PING 176.0.2.254 (176.0.2.254) 56(84) bytes of data.
64 bytes from 176.0.2.254: icmp_seq=1 ttl=62 time=0.075 ms
64 bytes from 176.0.2.254: icmp_seq=2 ttl=62 time=0.177 ms
64 bytes from 176.0.2.254: icmp_seq=3 ttl=62 time=0.175 ms
--- 176.0.2.254 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2035ms
rtt min/avg/max/mdev = 0.075/0.142/0.177/0.047 msこの結果から、全てのエコーリクエストが成功し、パケットロスがないことが確認できます。IPアドレスは通信全体を通して一貫しており、正確なルーティングが行われています。
【コラム】pingコマンドとは
pingコマンドは、ネットワーク上のデバイスとの通信が正常に行われているか
どうかを確認するためのコマンドです。
pingコマンドは、指定した宛先にICMP（Internet Control Message Protocol）エコーリクエストを送信し、相手からの応答（エコーリプライ）を待ちます。
通信がうまくいくと、通信相手からのパケットが返ってきます。
通信がうまくいかない場合、パケットが返ってこず、エラーメッセージが表示されます。このプロセスにより、ネットワーク接続の状態やパケットの往復時間（ラウンドトリップタイム）を確認することができます。先ほどのPingコマンドの実行例では，パケットの往復時間が表示されたログが出力されていることや
「0% packet loss」の表示があることから，指定した通信相手との通信が正常に行われていることが確認できます
tcpdump コマンドによるパケットトレース
北海道から東京間と大阪から福岡間、それぞれパケットの通り道を指定して tcpdumpコマンドを用いてパケットの中身を確認していきます．pingコマンドの実行前に、TCPDUMPコマンドを使って各リンクのパケットをキャプチャしました。
東京〜北海道間でのパケットの中身
root@b9f15438cc2c:/# ip netns exec tokyo tcpdump -i tokyo-hokkaido -e
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tokyo-hokkaido, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:04:25.930081 5a:5f:2e:fb:8b:7a (oui Unknown) > e6:48:4d:c2:49:18 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.0.2.1 > 176.0.2.254: ICMP echo request, id 50518, seq 1, length 64
13:04:25.930143 e6:48:4d:c2:49:18 (oui Unknown) > 5a:5f:2e:fb:8b:7a (oui Unknown), ethertype IPv4 (0x0800), length 98: 176.0.2.254 > 172.0.2.1: ICMP echo reply, id 50518, seq 1, length 64
13:04:26.952915 5a:5f:2e:fb:8b:7a (oui Unknown) > e6:48:4d:c2:49:18 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.0.2.1 > 176.0.2.254: ICMP echo request, id 50518, seq 2, length 64
13:04:26.953069 e6:48:4d:c2:49:18 (oui Unknown) > 5a:5f:2e:fb:8b:7a (oui Unknown), ethertype IPv4 (0x0800), length 98: 176.0.2.254 > 172.0.2.1: ICMP echo reply, id 50518, seq 2, length 64
13:04:27.974180 5a:5f:2e:fb:8b:7a (oui Unknown) > e6:48:4d:c2:49:18 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.0.2.1 > 176.0.2.254: ICMP echo request, id 50518, seq 3, length 64
13:04:27.974329 e6:48:4d:c2:49:18 (oui Unknown) > 5a:5f:2e:fb:8b:7a (oui Unknown), ethertype IPv4 (0x0800), length 98: 176.0.2.254 > 172.0.2.1: ICMP echo reply, id 50518, seq 3, length 64
| フィールド | 値 | 説明 |
|---|---|---|
| 送信元IPアドレス | 172.0.2.1 | パケットを送信したデバイスのIPアドレス |
| 送信先IPアドレス | 176.0.2.254 | パケットの宛先デバイスのIPアドレス |
| 送信元MACアドレス | 5a:5f:2e:fb:8b:7a | パケットを送信したネットワークインターフェースのMACアドレス |
| 送信先MACアドレス | e6:48:4d:c2:49:18 | パケットの宛先ネットワークインターフェースのMACアドレス |
大阪〜福岡間でのパケットの中身
root@b9f15438cc2c:/# ip netns exec osaka tcpdump -i osaka-fukuoka -e
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on osaka-fukuoka, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:04:25.930106 96:44:62:72:48:64 (oui Unknown) > ae:c8:da:13:6a:f6 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.0.2.1 > 176.0.2.254: ICMP echo request, id 50518, seq 1, length 64
13:04:25.930127 ae:c8:da:13:6a:f6 (oui Unknown) > 96:44:62:72:48:64 (oui Unknown), ethertype IPv4 (0x0800), length 98: 176.0.2.254 > 172.0.2.1: ICMP echo reply, id 50518, seq 1, length 64
13:04:26.952978 96:44:62:72:48:64 (oui Unknown) > ae:c8:da:13:6a:f6 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.0.2.1 > 176.0.2.254: ICMP echo request, id 50518, seq 2, length 64
13:04:26.953030 ae:c8:da:13:6a:f6 (oui Unknown) > 96:44:62:72:48:64 (oui Unknown), ethertype IPv4 (0x0800), length 98: 176.0.2.254 > 172.0.2.1: ICMP echo reply, id 50518, seq 2, length 64
13:04:27.974241 96:44:62:72:48:64 (oui Unknown) > ae:c8:da:13:6a:f6 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.0.2.1 > 176.0.2.254: ICMP echo request, id 50518, seq 3, length 64
13:04:27.974292 ae:c8:da:13:6a:f6 (oui Unknown) > 96:44:62:72:48:64 (oui Unknown), ethertype IPv4 (0x0800), length 98: 176.0.2.254 > 172.0.2.1: ICMP echo reply, id 50518, seq 3, length 64| フィールド | 値 | 説明 |
|---|---|---|
| 送信元IPアドレス | 172.0.2.1 | パケットを送信したデバイスのIPアドレス |
| 送信先IPアドレス | 176.0.2.254 | パケットの宛先デバイスのIPアドレス |
| 送信元MACアドレス | 96:44:62:72:48:64 | パケットを送信したネットワークインターフェースのMACアドレス |
| 送信先MACアドレス | ae:c8:da:13:6a:f6 | パケットの宛先ネットワークインターフェースのMACアドレス |
まとめ
上記が、北海道から福岡にパケットを送った際に、北海道〜東京間、大阪〜福岡間のパケットをトレースした結果になります。この結果から、パケットの送信元および宛先のIPアドレスは全ての区間で一貫していることがわかります。一方、MACアドレスは各区間ごとに変わります。これにより、ネットワーク内の異なるセグメント間でデータが正確に転送されていることが確認できます。
トレースした結果の比較
| 区間 | 送信元IPアドレス | 送信先IPアドレス | 送信元MACアドレス | 送信先MACアドレス |
|---|---|---|---|---|
| 北海道〜東京間 | 172.0.2.1 | 176.0.2.254 | 5a:5f:2e:fb:8b:7a | e6:48:4d:c2:49:18 |
| 大阪〜福岡間 | 172.0.2.1 | 176.0.2.254 | 96:44:62:72:48:64 | ae:c8:da:13:6a:f6 |
送信対象の特定手法
次に、前章で述べたパケットの送信プロセスにおいて、IPアドレスからMACアドレスへの変換がどのように行われるのかを具体的に見ていきましょう。この変換は、データを物理的に隣接するデバイスに正確に送信するために必要なステップです。前章で確認した通り、IPアドレスはインターネット全体での通信経路を指定するために使われますが、実際のデータの転送は、各デバイスの物理的なアドレスであるMACアドレスを基に行われます。ここでは、この重要な変換プロセスを支えるプロトコル、すなわちARP（IPv4の場合）とNDP（IPv6の場合）について詳しく解説します。
IPv4の時（ARP）
ARP（Address Resolution Protocol）は、IPアドレスからMACアドレスへの対応を解決するためにIPv4ネットワークで使用されます。具体的なプロセスは次のように進みます：
- 送信者は通信相手のIPアドレスを知っていますが、そのMACアドレスが分からない場合、ARPリクエストをネットワーク上にブロードキャストします。
- このARPリクエストは、ネットワーク上のすべてのデバイスに届き、指定されたIPアドレスを持つデバイスがARPリプライを送り返します。
- ARPリプライには、対象のデバイスのMACアドレスが含まれています。これにより、送信者はIPアドレスとMACアドレスの対応を知ることができ、データを正確に送信できるようになります。
実際の通信を確認してみよう（ARP）
北海道にあるデバイスから福岡のデバイスへデータパケットを送信します。ping コマンドでデータパケットを送信し、tcpdump コマンドでパケットの中身を確認します。今回は東京〜北海道間の通信をトレースして、ARPがどのような通信を行なっているか確認していきましょう．
pingコマンドの実行
root@b9f15438cc2c:/home/shell# ip netns exec hokkaido ping 176.0.2.254 -c 3
PING 176.0.2.254 (176.0.2.254) 56(84) bytes of data.
64 bytes from 176.0.2.254: icmp_seq=1 ttl=62 time=0.195 ms
64 bytes from 176.0.2.254: icmp_seq=2 ttl=62 time=0.196 ms
64 bytes from 176.0.2.254: icmp_seq=3 ttl=62 time=0.134 ms
--- 176.0.2.254 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2043ms
rtt min/avg/max/mdev = 0.134/0.175/0.196/0.029 ms東京〜北海道間のパケットの状態
phpCopy code
root@b9f15438cc2c:/# ip netns exec tokyo tcpdump -i tokyo-hokkaido -e
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tokyo-hokkaido, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:22:29.964602 5a:5f:2e:fb:8b:7a (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 172.0.2.254 tell 172.0.2.1, length 28
13:22:29.964634 e6:48:4d:c2:49:18 (oui Unknown) > 5a:5f:2e:fb:8b:7a (oui Unknown), ethertype ARP (0x0806), length 42: Reply 172.0.2.254 is-at e6:48:4d:c2:49:18 (oui Unknown), length 28この結果から分かることは、東京から北海道に送信されたARPリクエストと、それに対するARPリプライというものが通信として発生しているようです．それぞれ説明すると
- ARPリクエスト:
13:22:29.964602の行に示されるように、東京のネットワークインターフェース5a:5f:2e:fb:8b:7aはブロードキャストアドレス（全てのノードに送信）に対して「172.0.2.254のMACアドレスを教えてください」と要求しています。 - ARPリプライ:
13:22:29.964634の行で、北海道のネットワークインターフェースe6:48:4d:c2:49:18が東京のネットワークインターフェースに対して「172.0.2.254のMACアドレスはe6:48:4d:c2:49:18です」と返答しています。
IPv6の時（近隣探索プロトコル）
IPv6では、ARPの代わりに近隣探索プロトコル（Neighbor Discovery Protocol, NDP）が使用されます。このプロトコルは、IPv6ネットワーク内のデバイス同士がお互いの存在を確認し、IPアドレスからMACアドレスへの対応を解決するために設計されています。NDPは次のように機能します：
- Neighbor Solicitation（NS）メッセージの送信（Type 135）：通信元ノードが通信相手のIPv6アドレスに対応するMACアドレスを知りたい場合、NSメッセージを送信します。
- Neighbor Advertisement（NA）メッセージの応答（Type 136）：通信相手のノードは、受け取ったNSメッセージに対してNAメッセージで応答し、自身のMACアドレスを通知します。
実際の通信を確認してみよう（NDP）
ARPの時と同じ条件でパケットの中身を確認してみましょう
pingコマンドの実行
root@b9f15438cc2c:/home/shell# ip netns exec hokkaido ping6 2001:db8:0:1::2 -c 3
PING 2001:db8:0:1::2(2001:db8:0:1::2) 56 data bytes
64 bytes from 2001:db8:0:1::2: icmp_seq=1 ttl=64 time=1.55 ms
64 bytes from 2001:db8:0:1::2: icmp_seq=2 ttl=64 time=0.086 ms
64 bytes from 2001:db8:0:1::2: icmp_seq=3 ttl=64 time=0.130 ms
--- 2001:db8:0:1::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2021ms
rtt min/avg/max/mdev = 0.086/0.587/1.546/0.678 ms東京〜北海道間のパケットの状態
phpCopy code
root@b9f15438cc2c:/# ip netns exec tokyo tcpdump -i tokyo-hokkaido icmp6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tokyo-hokkaido, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:25:41.820584 IP6 2001:db8:0:1::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:db8:0:1::2, length 32
13:25:41.821264 IP6 2001:db8:0:1::2 > 2001:db8:0:1::1: ICMP6, neighbor advertisement, tgt is 2001:db8:0:1::2, length 32この結果から分かることは、東京から北海道に送信されたNDP近隣要請と、それに対するNDP近隣広告というものが通信として発生しているようです．それぞれ説明すると
- NDP近隣要請（Neighbor Solicitation）:
13:25:41.820584の行で、東京のネットワークインターフェース2001:db8:0:1::1はマルチキャストアドレスff02::1:ff00:2に対して「2001:db8:0:1::2のMACアドレスを教えてください」と要求しています。 - NDP近隣広告（Neighbor Advertisement）:
13:25:41.821264の行で、北海道のネットワークインターフェース2001:db8:0:1::2が東京のネットワークインターフェースに対して「2001:db8:0:1::2のMACアドレスはこのアドレスです」と返答しています。
コメントを残す