ユビキタスネットワーク 其の六 20171113
IPヘッダの続き
3行目
4行目
送信元IPアドレスが書かれている。
5行目
宛先のIPアドレスが書かれている。
6行目
ここから先はIPオプションと呼ばれる。
IPレコードルートオプション
途中のルータのアドレスを記録するもの。
IPフォワーディング
IPが送信要求を受け、宛先アドレスを受け取った際に、どのように動けばいいのかを参照しなければならない。そこで、登場するのが、ルーチングテーブル。この中には宛先アドレスとそのアドレスに対する指示が対応付けられて入っている。IPは宛先アドレスでルーチングテーブルを参照。次の指示をもらう。
ルーチングテーブルの構造
主な内容は次の通り。
- 宛先アドレス
- ネットマスク:サブネット部分を1、それ以外を0にしたもの
- ゲートウェイ:送信先に送るために必要な次のノードのアドレスが入っている
- インターフェース:ゲートウェイに送るために使うもの
- メトリックス:エントリの優先度
これらの組の集合になっている。各組合せのことをエントリと呼ぶ。
参照の方法
- 参照された宛先アドレスとネットマスクのANDを取る
- その結果とルーチングテーブルにある宛先アドレスが一致したものを選択
- 複数ヒットした場合は、ネットマスクの1の数が最大のものを選ぶ
- それでも決められない場合は、メトリックスが最小のものを選ぶ
- 選択したエントリのインターフェースから出力する
ARP
PCから自宅のLANを使ってルータに接続する場合を考える。
これまでのIPヘッダやルーチングテーブルには宛先のIPアドレスは入っていても、MACアドレスは入っていない。なので、ルータのMACアドレスがわからない。ルータに向けて通信することができない。
こんな時に活躍するのがARP。これを使って目的のSTAに送ることができる。手順は次の通り。
雑ですがこんなことが起こっているようです。
最初に送るARP要求メッセージには、送信元のIPアドレスとMACアドレス、ターゲットのIPアドレスとMACアドレスを書ける領域があります。ARP要求時はターゲットのMACアドレスは空。ARP応答の送信元MACアドレスの部分に目当てのMACアドレスが入っているという算段です(応答時の送信元はターゲットだから)。
ARPキャッシュ
ARPのような仕組みがあっても、送信時に毎回この手順を踏んでいたらさすがにめんどくさい。ということで、20分間IPアドレスとMACアドレスの対応を記録できるARPキャッシュが各接続端末に導入されている。
ARP要求段階で、送信元IPアドレスとMACアドレスの対応はブロードキャストされている。そのため、同一LANに接続されているSTAはその対応を知ることができる。これにより、IPアドレスとMACアドレスの対応を効率的にARPキャッシュに保存できる。