IPデータグラム自身のフォーマットを知ることであろう。
p419
UDPは「普通の宅急便」です。荷物をダンボールに詰めるところまではお客さん（アプリケーション）の仕事であり、運送屋さんはダンボールを指定された住所へ届けるだけです。
Ipv4のヘッダー
データグラムの転送の順番
各ビットは
左から右、上から下へ、バージョン・フィールドの上位ビットから先に送られる。(これは、ビックエディアンと呼ばれるネットワーク・バイト・オーダーである。Intel x86のようなリトル・エディアンを用いているマシンでは、送信・受信においてソフトウェアでの変換が必要となる。）今にして思えばリトル・エディアンを採用すべきであったが、IPが設計された当時には、リトルエディアンが多数派になると想像した者は誰一人いなかった。
- ビック/リトルエディアンは資格のテキストで見たことある
IHLフィールド
ヘッダーの長さが可変であるため、ヘッダーの中にヘッダーの長さを３２ビット単位で示すIHLフィールドが与えられる。最小値は５であり、これはオプションのない場合に相当する。
4ビットフィールドの最大値は15、つまりヘッダーは60バイトが最大になっており、オプション部分は40バイトが最大となる。オプションによっては、例えば通過してきたルータを逐一記録するようなものがあり、その場合、この40倍とはあまりにも小さすぎ、オプションが無駄になる。
- 理解できなかったがIHLフィールドはヘッダーの長さを示すフィールド
DiffServフィールド
数年かけて（少し）その意味を変えたフィールドの一つである。これはもともとサービス・タイプ・フィールドと呼ばれていた。このフィールドはサービスの種類を知らせるためのもである。信頼性とスピードに関する様々な組み合わせが可能である。
それぞれのサービスに対する組み合わせ
音声のデジタル信号は正確さよりも速さが求められる。一方、ファイル転送は速さより誤りのない転送が求められる。
ビット構成
現在では、上位６ビットは各パケットのサービスクラスを示すために用いられている。
下位２ビットは、パケットが輻輳しているかどうかを通知する情報を明示するために用いられている。
全長フィールド
ヘッダーとデータ、すなわちデータグラム全体の長さを表す。最大長は現在65,535バイトである。
将来的にデータグラムの全長が大きくなりそう
将来のネットワークにおいて、さらに大きいデータグラムが必要となる可能性もある。
識別子フィールド
宛先ホストが到着したフラグメントがどのパケットに属するかを決定するために必要となる。パケットの全てのフラグメントには、同じ識別子の値が含まれている。
未使用の１ビット
驚くべきことに、極端に短いIPヘッダーの中で本当に未使用のビットである。
DFフィールド
「フラグメント化禁止」を意味する。これはルーターにパケットのフラグメント化をさせないように指定するものである。元々は、ホストがフラグメントを再構築できないような場合を想定して作られたが、現在では、フラグメント化されずに経路を通ることができる最大パケット長である。経路MTUを求めるプロセスの一部として使われている。
MFフィールド
「さらなるフラグメント」を意味する。最後以外の全てのフラグメントにこのビットが設定されている。このビットは
データグラムの全てのフラグメントが到着したかどうかを知るために必要である。
フラグメント・オフセット
現在の
パケットのどこにこのフラグメントが属するのかを知らせるためのものである。データグラムの最後以外のフラグメントは、基本的なフラグメントの単位である8バイトの倍数でなければならない。13ビットが与えられているため、データグラムごとに最大で8192個のフラグメントに分割でき、最大パケット長は、全長フィールドの限界までとなる
TTL（Time to Live:生存期間）
パケットの生存期間の制限に使用される。
最大生存時間
最大生存時間として255秒まで許されている。その値は、各ホップで少なくとも一つずつ減算され、パケットがルーターで長期間キュー内にある場合には、一つのルーターで２以上減らすことも想定されている。実用上は、単にホップ数をカウントするだけである。
この値が０になれば、パケットは破棄され警告パケットが送信元へと送り返されるこのフィールド用いて、ルーティング・テーブルが壊れてた時などに、パケットが永遠に回り続けるのを防いでいる。
プロトコルフィールド
ネットワーク層が完全なパケットを再構築する際には、どのように処理すれば良いかを知る必要がある。プロトコル・フィールドを参照することで、どのトランスポート・プロセスを使用すれば良いかがわかる。TCPは一つの候補であるが、UDPやその他のプロトコルもある。プロトコル番号はインターネットにおいて共通のものであり、RFC1700で定義されている。
ヘッダー・チェックサム
ヘッダーはアドレスなどの非常に重要な情報を含んでいるため、
情報の保護のために自身のチェックサムを計算しており、これはヘッダー・チェックサムと呼ばれている。このアルゴリズムでは、到着したヘッダーを１６ビットごとに1の補数を足し合わせ、その結果の1の補数をとることによりへッダー・チェックサムを計算する。
到着時には０になっている
到着時には、ヘッダーチェックサムは０であることが想定される。これは、パケットがネットワークを通る間に起こる誤りの検出に有用である。
ヘッダー・チェックサムは各ホップにおいて計算し直す必要がある。なぜなら、少なくとも一個のフィールド（TTLフィールド）の値は変化しているからである。ただし、うまく計算すれば計算時間を短縮できる。
オプションフィールド
送信元アドレスと宛先アドレス