最後に紹介する役割は，IPパケットが壊れていないかを調べることだ。

捨てても送信元に知らせない

　もし，パケットを送っている途中で雑音などが混入し，届いたIPパケットの中身が壊れていたら…。IPはこうした事態も想定している。あて先に届ける途中であっても，IPパケットが壊れていることが判明したら，その時点でパケットを捨てるのである。受信側パソコンのIPだけでなく，途中のルーターのIPでも壊れていることを見つけたら即座に捨てる。

　壊れたパケットを先に転送しても意味がないからだ。IPはパケットを捨てても，そのことを送信元に知らせない。パケットのどこが壊れているかわからないので，ヘッダー中の送信元アドレスも信用できないからである。

図9　ここで登場するIPヘッダー
IPヘッダー中には，届いたパケットのヘッダー部分が壊れていないかを確かめる「チェックサム」，次に処理を引き継ぐモジュールを表す「プロトコル番号」が書かれている。長さはそれぞれ，16ビット，8ビットである。
図10　壊れていないか確かめるメカニズム
完成直前のヘッダーを16ビットずつに区切って計算をする。その結果をヘッダーに書き込む。受信したマシンは，受け取ったヘッダー全体（チェックサムを含む）から同じように計算をする。ヘッダーの中身が送信時と変わっていなければ0になる。0にならなければ，ヘッダーが壊れていることになるので捨てる。
図11　データを引き継ぐ先を見つけ出すメカニズム
受信側パソコンのIPは「プロトコル番号」の値を読み取り，値に応じて処理を引き継ぐ先を決める。

演算結果がゼロならOK

　では，IPヘッダーが壊れていないかをどのように確認するのか。話を簡単にするためにLAN上のパソコンが直接通信するケースを考える。

　実は，IPがパケットを確認するのはヘッダー部分だけである。ここが壊れていたら，ムダなパケットでインターネット全体に悪影響を及ぼすかもしれないからである。一方のデータ部分は確認しない。データ部分については，TCPやUDP，あるいはアプリケーションがチェックすればいいという考え方をしているからである。

　まず送信元パソコンのIPは，IPヘッダー中にチェックサムという誤り検出情報を書き込む。大きさは16ビットである（図9[拡大表示]）。

　このチェックサムは，IPヘッダーを16ビットごとに区切って，それぞれのビット列に補数和という演算をして求める。説明すると難しくなるので，考え方だけを簡単に紹介しよう。

　まずIPはヘッダーを16ビットずつに区切るのだが，ヘッダー部分にはチェックサムを書き込む領域もある。そこで，この領域はとりあえず0で埋めておく。そして，この区切られたビット列すべての補数和を計算する。この計算結果が50になったとしよう。そうしたら，チェックサムの値は−50にする。そして，この−50という値を先ほど0で埋めたチェックサム・フィールドに書き込んで送信する（図10[拡大表示]）。

　このIPパケットを受け取ったあて先のパソコンのIPは，再びIPヘッダーを16ビットごとに区切ってチェックサムを計算する。チェックサムを0で埋めたときには50だった。そこに−50が書き込まれているなら，計算結果は0になるはずである。もし，計算結果が0にならなければ，IPヘッダーが壊れているというわけだ。

　ちなみにチェックサムは，経由するルーターも逐一チェックする。ただ，ルーターはパケットを転送するときに役割2や役割3で説明したようにヘッダー部分を書き換える。このため，ルーターのIPはチェックサムのチェックに加えて，新しくなったヘッダーの値を基にチェックサムを算出し，新しいチェックサムの値を書き込んで次のルーターへパケットを転送する。

上位のプロトコルはなに？

　受信側パソコンのIPには，もう一つの仕事がある。受信パケットが壊れていないことが確認できたら，データを抜き出してTCPやUDP，あるいはアプリケーションにそのデータを渡してやる仕事である。このとき，どこに渡すかを調べなければならない。

　IPには，そのためにプロトコル番号を入れるためのフィールドがヘッダーに8ビット分用意されている。プロトコル番号は，IANAアイアナという組織が，TCPなら6番，UDPなら17番といった具合に決めている（図11[拡大表示]）。

　そこで送信元パソコンのIPは，ヘッダー中にこの番号を書き込んで送り，受信側パソコンのIPがそれを見て適切な上位プロトコルにデータを渡す。

　以上，四つの役割を順番に見てきた。IPはこんな仕事をしながらパケットを目的地に届けるのである。