ユビキタスネットワーク 其の六 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キャッシュに保存できる。
ユビキタスネットワーク 其の五 20171106
IPv4
NICが管理しているアドレスで4バイトで構成されている。接続されている端末一つ一つにユニークなアドレスが割り振られている。イメージだけだと、IEEEが管理しているMACアドレスみたいな感じです。PCを買ってきたらすぐに振らなければならない。
NICが決めるところをnet-id、ユーザーが決めるところをhost-idと呼ぶ。
IPv4のクラス
net-idとhost-idの割り振り方はクラスという単位で区別されている。
- クラスA：0+(net-id : 7bit)+(host-id : 24bit)
- クラスB：10+(net-id : 14bit)+(host-id : 16bit)
- クラスC：110+(net-id : 21bit)+(host-id : 8bit)
- クラスD：1110+(マルチキャストグループID : 28bit)
- クラスE：1111から始まる（将来のためにとっておく）
基本はクラスAからクラスCで、ここには企業が割り当てられている。しかし、2011年に枯渇。
マルチキャストアドレス
クラスD。IPTV（ネットテレビ、生放送など）で用いられている。受信しているSTAに割り当てられるアドレス。
一度にどれだけのSTAが受信しているかわからないので、ルータ経由で、受信を希望しているSTAに割り当てられる。
IPアドレスの割り当て方
host-id部分に異なる値を割り当てることで、全ての通信インターフェース割り当てられる。ここでは、LANのことをサブネットと呼ぶことにする。IPv4を割り当てられた企業組織は、host-id部分を「サブネットid」と「ホストid」に分けて利用することで、自社内すべてのSTAにIPアドレスを割り当てている。というのも、IPv4は1組織に1つしか割り当てられないからだ。
- host-idの上位：サブネットid
- host-idの下位：ホストid
つまり、IPv4をもらったときは「net-id+host-id」という構造だったが、運用段階になると「net-id+サブネットid+ホストid」という構造になる。したがって、net-id+サブネットid部分を区別することが必要になり、サブネットidまでの長さをIPアドレスの後ろに「（IPアドレス）/（サブネットidまでの長さ）」のような、スラッシュで区切った形で表現している。
特殊なIPアドレス
- 0.0.0.0：IPアドレスが割り当てられていない場合の送信元
- 127.0.0.1：ループバックアドレス（自分宛）
- 255.255.255.255：リミテッドブロードキャストアドレス（LAN内のすべてのSTA宛）
- host-idが全て1：ネットワーク指定のブロードキャストアドレス
- ホストidが全て1：サブネット指定のブロードキャストアドレス（セキュリティ面でアウト。DoS攻撃される可能性あり）
プライベートアドレス
家庭、個別組織で用いられるアドレス。クラスはA~Cまで存在する。外部サーバやネットワークに接続するときは、グローバルアドレスに変換する必要がある。
オールホストグループアドレス
224.0.0.1。同じサブネットのすべてのSTAを表すアドレス。リミテッドブロードキャストアドレスと同じ機能を持つ。
IPv4ヘッダ
1行に4バイトあり、これが基本的に5行ある。したがって、基本的にIPヘッダは20byte。ここからは、各行に関して一つずつ書いていく。
1行目
- 0~3bit：バージョン
- 4~7bit：ヘッダ長
- 8~15bit：サービスタイプ
- 16~31bit：パケット長
ヘッダ長
取りうる値は0~15までの値なのだが、ヘッダ長を4byte単位で指定しているため、この値に4byteをかけた値が本当のヘッダ長になる。したがって、ヘッダ長の最大値は15×4=60byte。
パケット長
ヘッダとデータを含むIPデータグラム長をバイト単位で示している。
2行目
この行にあるのは、IPフラグメンテーションのために使われるもの。IPフラグメンテーションとは、大きなデータを送るときに複数パケットに分割することなのだが、ばらばらに分けたデータグラムを復元するときにいろいろなパラメータが必要になる。この行では、そのようなパラメータを扱っている。
IPは最大で1500byteまでしか一度に転送できないため、このフラグメンテーションが必要になる。特に、UDPを使っている通信では、データが1500byte以上になるかがわからないため、必要になる（TCPを使っている場合は、データ長が最大1500byteであることがわかっているので問題ない）。
識別子
ただデータを分割するのではなく、どのデータから分割されたものなのかがわからないと、正しく復号することができない。そこで、同じデータから分割されたものには、同じ識別子が与えられる。復元する際は、この識別子を見て行う。
モアフラグ
分割されたデータがどこで終わるのかがわからないと、いつまでたっても復元は終わらない。そこで、分割されたデータのうち、途中のものを1、最後のものを0とするモアフラグを導入している。これにより、モアフラグが0の分割データを扱ったときに、そのデータの復元は終了したと確認できる。
フラグメント・オフセット
どんな順序で分割されたデータが並んでいたのかを識別するもの。注意したいのは、フラグで3bit分取られてしまうこと。したがって、ここに出てくる値は本来の値を8で割ったものになる。真値を知りたい場合は、ここの値に8をかける。
フラグメントされない場合
分割する必要がない場合は、
- 識別子は固有の値
- モアフラグは0
- フラグメント・オフセットは0
になる。
