[[ネットワーク用語]] > IPヘッダ

* IPヘッダ [#g2c946bd]

IPヘッダ = Internet Protocol header

- IP[[パケット]]は、IP[[ヘッダ]]とIP[[ペイロード]]（データ部分）から構成されています。
- IPヘッダは、[[IP]]（Internet Protocol）の制御情報です。
- [[IPv4>http://ja.wikipedia.org/wiki/IPv4]]と[[IPv6>http://ja.wikipedia.org/wiki/IPv6]]のIPヘッダは、以下のように定義されています。

|>|CENTER: IPパケット |
|BGCOLOR(pink): IPヘッダ | IPペイロード |

CENTER:http://program.sagasite.info/wiki/index.php?plugin=attach&refer=TCP%2FIP&openfile=TCP-IP0.gif

* IPv4ヘッダ [#x3be6920]

- IPv4ヘッダは、&color(red){12個のフィールド};（基本ヘッダ）と&color(red){オプション};から成っています。
- IPv4ヘッダ長の最小は、&color(red){20バイト};です。＝基本ヘッダのみ
- IPv4ヘッダ長の最大は、&color(red){60バイト};です。＝基本ヘッダ＋40バイトのオプション
- オプションを追加する場合、&color(red){4バイト単位で増える};ようにパディングを詰めて調整されます。

※単位：1バイト（byte）＝8ビット（bit）

[[IPヘッダ内の各情報 - ネットワークエンジニアを目指して>http://www.itbook.info/study/p89.html]]
>IPヘッダの中身は以下のような形式で情報が入っています。

CENTER:&ref(iphead2.gif);


[[IPデータグラムとIPヘッダ　TCP/IP入門>http://net-juku.org/tcpip/tcpip83.html]]
>IPヘッダの基本ヘッダ部分は、20バイト（160bit）で構成されています。
オプションは、必ず付けなければならないというものではありません。

CENTER:&ref(tcpip8301.jpg);


[[TCP/IPをはじめから - IPとは>http://www.infraexpert.com/study/tcpip1.html]]
>　IPヘッダのフォーマットは以下の通りです。IPヘッダは20バイトのサイズですが、オプションが追加された
　場合は最大で60バイトのサイズとなります。ただ、オプションやパディングは一般的には使用されることは
　ないのであまり意識する必要はありません。「データ」はIPヘッダではなくIPペイロードと呼ばれる部分です。

CENTER:&ref(tcpip5.gif);
>※ IPペイロード部分には、TCPやUDPなど上位層プロトコルのヘッダとデータが含まれます。


[[＠IT：連載 基礎から学ぶWindowsネットワーク 第10回　IPパケットの構造とIPフラグメンテーション　1．IPパケットの構造>http://www.atmarkit.co.jp/fwin2k/network/baswinlan010/baswinlan010_02.html]]

CENTER:&ref(fig01.gif);
>''IPパケットの詳細構造''
IPパケットの構造は、IPヘッダ部分と、IPパケットによって運ばれるデータ部分（図中の赤の部分）の大きく2つに分けられる。
そしてIPヘッダはさらに固定長の部分（図中の青色と緑色の部分。先頭の20bytes）と、オプション部分（図中の黄色の部分。最小0byte）の2つで構成される。
図中の小さい1目盛りは1bit幅であり、ここでは32bitずつに区切って表現している。
 
** IPv4ヘッダのフィールド [#wc219756]
IPv4ヘッダには、&color(red){12個のフィールド};があります。

*** (1) 「バージョン」フィールド：4ビット [#o506509f]
バージョン（Version）フィールドは、IPのバージョンを表します。

&color(red){IPv4は、4};（2進数表現では0100）です。
IPv6は、6（2進数では0110）です。
同じネットワーク媒体上に、IPv4とIPv6のパケットが混在していても、バージョンフィールドによって区別することができます。

-その他のバージョン番号
http://www.iana.org/assignments/version-numbers/version-numbers.xml

| 整数 | バージョン |h
| 0-1 | （予約） |
| 2-3 | （未割当） |
| 4 | Internet Protocol |
| 5 | ST Datagram Mode |
| 6 | Internet Protocol version 6 |
| 7 | TP/IX（The Next Internet） |
| 8 | PIP（The P Internet Protocol） |
| 9 | TUBA |
| 10-14 | （未割当） |
| 15 | （予約） |

*** (2) 「ヘッダ長」フィールド：4ビット [#d49c2e49]
ヘッダ長（IHL：Internet Header Length　インターネットヘッダ長）フィールドは、IPヘッダの長さを表しています。
ヘッダ長によって、IPヘッダとデータの境目が分かります。

4ビット幅しかないので、0から15までしか表現できないが、ヘッダの長さは32ビット（4バイト）単位（つまり&color(red){ヘッダ部分は常に4バイトの倍数）で数える};ので、最大長は15×4＝60バイトまで表せます。
IPヘッダの固定長部分（基本ヘッダ）が常に20バイトあるので、このフィールドの&color(red){最小値は5（20÷4）であり、最大値は15};となります。

*** (3) 「サービス・タイプ（TOS）」フィールド：8ビット [#pcff60c2]
サービス・タイプ・フィールドは、&color(red){パケットの優先度};などを表す[[TOS]]（Type Of Service）を指定するために使われます。

ある特定の値が指定された場合には、他のパケットよりも優先して[[ルーティング]]処理などを行う、といった設定ができます。
例えば、音声トラフィックとデータトラフィックでは、音声トラフィックのデータを優先して送出することができる、などです（いわゆる[[QoS]]処理）。
現在使われている実際のTCP/IPネットワークでは、このフィールドによる[[TOS]]指定はほとんど使用されておらず、意味を持っていないことが多いようです。

*** (4)「パケット長」フィールド：16ビット [#l3109b91]
パケット長（Total Length）フィールドは、IPヘッダとデータを含めたパケット全体の長さを表します。

ヘッダ長フィールドが「IPヘッダのサイズ」を4バイト単位で数えたのに対し、パケット長フィールドはパケット全体のサイズを&color(red){バイト単位};で数えたものです。
このフィールドの幅は16ビットなので、パケットのサイズの最大長、つまり1つのパケットで送信可能なデータ（＋ヘッダ部）のサイズは&color(red){64Kバイト（65,535バイト）};までとなります。

パケットがフラグメント化（大きなパケットを小さなパケットに分割）されている場合は、このフィールドは、元のパケット全体のサイズではなく、このフラグメントだけのサイズを表します。

*** (5) 「ID」フィールド：16ビット [#l321172d]
ID（Identification）フィールドは、&color(red){パケットを識別するための数値};です。

[[IP]]は、下位層の[[ネットワークインターフェース層]]で使用する[[プロトコル]]の[[MTU]]（Maximum Transmission Unit：&color(red){最大転送単位};）サイズに合わせて、送信側のIPでデータを分割（フラグメント）し、受信側のIPで組み立てる機能を持っています。

サイズの大きなパケットをフラグメント化（分割）する時に、分割後のパケット全てに&color(red){同じ識別番号};を与えることによって、分割されたパケットを結合して元のパケットに戻すことができます。

- IPフラグメンテーションとは？
IPパケットの最大サイズは64Kバイトですが、このサイズのデータを1回で送信できないネットワーク媒体がほとんどです。
そのため、送信可能なサイズにまでパケットを小さく分割（IPフラグメンテーション）してから送信します。
最終的なあて先のコンピュータ上で、分割されて届いたパケットを合成し、元のサイズのパケットに再構成します。
IPフラグメンテーションの仕組みにより、物理的なネットワーク媒体によらず、パケットを送受信することが可能となっています。

各コンピュータは、パケットを送信するたびにランダムな16ビットの数値を、このIDフィールドに設定します。
このIDの数値そのものには意味がなく、毎回異なるIDがセットされてからパケットが送信されるということだけが重要です。
&color(red){同じパケットに属するフラグメント化されたパケットは、すべて同じIDを共有するので、後で1つのパケットに再構成する場合の目印};となります。

*** (6) 「フラグ」フィールド：3ビット [#le1284b0]
フラグ（Flags）フィールドは、パケットの分割を制御する情報です。

3ビットあるうち、後ろの2ビットだけが使われます。
- 先頭（ビット0）：（未使用）

- 中央（ビット1）：DF（&color(red){Don't Fragment};）ビット
&color(red){分割の不許可};を表す値です。
-- DF値が0なら、分割可
-- DF値が1なら、分割不可
[[ルータ]]は必要ならばパケットを分割しますが、このDFビットに1がセットされていると「パケットを分割してはいけない」という指示になります。
性能の低いコンピュータや、フラグメンテーション・アルゴリズムを実装することが困難な組込み機器などで、DFビットを指定することによって、フラグメンテーション処理を使わずにTCP/IP通信を実現することが可能となります。

- 最終（ビット2）：MF（&color(red){More Fragment};）ビット
分割された&color(red){フラグメントの後続};を表す値です。
-- MF値が0なら、最後のフラグメント
-- MF値が1なら、後続のフラグメントが存在
1つのパケットを複数に分割した場合、最後部のパケットではこのMFビットを0にし、そのほかのパケットではMFビットを1にします。
MFビットが1であれば、フラグメント化されたパケットがさらに後ろに続くという意味になります。

*** (7) 「フラグメント・オフセット」フィールド：13ビット [#bd4f9b6e]
フラグメント・[[オフセット]]（Flagment Offset）フィールドは、&color(red){分割されたパケットが、元のパケットのどの位置にあったか};を表します。

単位は8オクテットで、フラグメント・オフセット・フィールドの最大値は8192です。
※単位：1[[オクテット]]＝8ビット（＝1バイト）

パケットのフラグメントは、常に8バイト単位で行われるので、この値を8倍して[[オフセット]]（位置情報）の数値とします。
これなら13ビットしかないフィールドでも、64Kバイトの範囲を表すことができます。
8オクテット×8192＝65536オクテット（＝64Kバイト）

*** (8) 「TTL」フィールド：8ビット [#a5b6f9b4]
Time to Live（[[TTL]] 生存時間）フィールドは、パケットが&color(red){通過可能なルータの数};を表します。

[[ルータ]]を経由するたびに、[[TTL]]が1ずつ減っていき、0になった時点でパケットが破棄されます。

*** (9) 「プロトコル」フィールド：8ビット [#a5e5c3bc]
プロトコル（Protcol）フィールドは、IPの上位層（[[トランスポート層]]）のプロトコルを表します。

この値は、[[ICANN>http://ja.wikipedia.org/wiki/ICANN]]という組織により「プロトコル名」と「番号」が定義されています。
例えば、IPの上位層プロトコルでTCPが使用されている場合、このプロトコル番号は「6」になります。

- その他のプロトコル番号
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
| プロトコル番号 | プロトコル |h
| 1 | [[ICMP]] (Internet Control Message Protocol) |
| 6 | [[TCP]] (Transmission Control Protocol) |
| 17 | [[UDP]] (User Datagram Protocol)  |

*** (10) 「ヘッダ・チェックサム」フィールド：16ビット [#u22cedad]
ヘッダ・チェックサム（Header Checksum）フィールドは、&color(red){IPヘッダの[[チェックサム]]（整合性を検査するためのデータ）};です。

IPパケットの伝送エラーがないかチェックするためにあります。
IPヘッダ内の[[TTL]]値は、[[ルータ]]を経由するたびに変わるため、各ルータでは転送
する前にヘッダチェックサムの再計算を行っています。

実際には、下位のネットワーク媒体（および上位プロトコル）でも様々な方法でエラー検査が行われているので、IPプロトコルでエラーを検出しなくても問題が発生する確率は非常に小さいです。

*** (11) 「送信元IPアドレス」フィールド：32ビット [#teb0af79]
送信元IPアドレス（Source Address）フィールドは、32ビット（4バイト)で構成された、送信元のIPアドレスがセットされています。

*** (12) 「宛先IPアドレス」フィールド：32ビット [#adf488c0]
宛先IPアドレス（Destination Address）フィールドは、32ビット（4バイト)で構成された、宛先のIPアドレスがセットされています。

** IPv4ヘッダのオプション [#ufc90304]
オプションは、32ビット（4バイト）単位で追加される、可変長のフィールドです。

通常は使用されませんが、デバッグやテストを行う際に使用される情報です。
- IPパケットの通過のログ（時間の記録）
- [[ルーティング]]経路の強制的指定
- パケットが通過したルート（[[ルータ]]のIPアドレス）を記録

オプション部分は通常は使用されないので、IPヘッダのサイズは20バイトです。
オプションが利用される場合は、4バイト（32ビット）単位で可変であり、&color(red){最大で40バイト};（固定部分の基本ヘッダとあわせると最大で60バイト）にまで拡大します。

** IPv4ヘッダのパディング [#v01374f1]
パディングは、オプションを使用したとき、サイズを調整のために入れるデータです。

オプションを追加して、IPヘッダ長が4バイト（32ビット）の整数倍にならなかった場合、オプションのサイズを4バイトの整数倍にするために、&color(red){詰め物（Padding）として空データの「0」の値を入れる};ことによって調整します。

* IPv6ヘッダ [#t16286c7]
- IPv6ヘッダのサイズは、&color(red){固定長で40バイト};です。
- IPv6ヘッダには、&color(red){基本ヘッダ};と&color(red){拡張ヘッダ};の２種類があります。
- IPv6の基本ヘッダは、&color(red){8個のフィールド};から成っています。

CENTER:&ref(L3315180.GIF);
~
CENTER:&ref(L3315190.GIF);
> http://www.nec.co.jp/ip88n/s36_sw/html/cfguide3/0405.HTM

CENTER:&ref(zu02.gif);
> http://www.atmarkit.co.jp/fnetwork/rensai/ipv6-03/ipv6-01.html

** IPv6ヘッダのフィールド [#f5d96a77]
http://www.itbook.info/study/ipv6-4.html

*** (1) 「バージョン」フィールド：4ビット [#r9ad8689]
バージョン（Version）フィールドは、IPのバージョンを表します。

&color(red){IPv6は、6};（2進数では0110）です。

*** (2) 「トラフィッククラス」フィールド：8ビット [#o8b57beb]
トラフィッククラス（Traffic Class）フィールドは、[[QoS]]で使用するパケットのクラスです。

IPv4ヘッダの[[TOS]](Type Of Service)フィールドに相当します。
このフィールドを使用してパケットの優先度付けを行うことが出来ます。

トラフィッククラスフィールドがどのように使われるのかは、RFC2472で定義されています。
ftp://ftp.rfc-editor.org/in-notes/rfc2474.txt

*** (3) 「フローラベル」フィールド：20ビット [#nbf8de99]
[[フローラベル]]（Flow Label）フィールドは、IPv4には無かったフィールドで、[[QoS]]で使用するトラフィック・フロー（データの流れ）につける識別子です。

例えば、リアルタイム性が要求されるインターネット電話の音声パケット群で、同じ扱いを必要とするパケットを識別します。
送信元[[ノード]]が中継[[ルータ]]に対して、自分が送信する特定のトラフィックフローに対して、特別な扱いをさせるような場合に使用します。

*** (4) 「ペイロード長」フィールド：16ビット [#af9da865]
[[ペイロード]]長（Payload Length）フィールドは、[[ヘッダ]]をのぞいたパケットサイズを表します。

IPv4のパケット長は、ヘッダ＋データの長さでしたが、IPv6ではヘッダをのぞいたデータの長さになっています。

*** (5) 「次ヘッダ」フィールド：8ビット [#j907c726]
次ヘッダ（Next Header）フィールドは、IPv4ヘッダでいうところの、プロトコル番号に相当するフィールドです。

IPv6ヘッダの次のヘッダという意味で、&color(red){上位プロトコルのヘッダ};や&color(red){IPv6拡張ヘッダ};を表します。
上位プロトコルが[[TCP]]であれば、プロトコル番号は「6」、[[UDP]]であればプロトコル番号は「17」となるのは、IPv4のプロトコル番号と一緒です。

*** (6) 「ホップ制限」フィールド： 8ビット [#xa1c96e8]
ホップ制限（Hop Limit）フィールドは、IPv4ヘッダでいうところの、[[TTL]]に相当するフィールドになります。

*** (7) 「送信元IPアドレス」フィールド：128 ビット [#tf4ff475]
送信元IPアドレス（Source Address）フィールドは、128ビット（32バイト)で構成された送信元のIPv6アドレスがセットされます。

*** (8) 「宛先IPアドレス」フィールド：128 ビット [#oe6dd00d]
宛先IPアドレス（Destination Address）フィールドは、128ビット（32バイト)で構成された宛先のIPv6アドレスがセットされます。

** IPv6の拡張ヘッダ [#ibcff30a]
IPv6ヘッダは、IPv4のオプションのようなデータを追加するフィールドが無い代わりに、拡張ヘッダを追加できます。

CENTER:&ref(bsci08-02-02.gif);
>IPv6拡張ヘッダ http://itpro.nikkeibp.co.jp/article/COLUMN/20071009/284087/

CENTER:&ref(ipv6-2.gif);
>IPv6パケットフォーマット http://www.infraexpert.com/study/ipv6.htm

[[シンプルで洗練されたIPv6のヘッダフォーマット>http://www.atmarkit.co.jp/fnetwork/rensai/ipv6-03/ipv6-01.html]]

CENTER:&ref(zu03.gif);
>基本ヘッダ（緑色）と各種拡張ヘッダ（青色）は数珠つなぎされる

- IPv6ヘッダは、付加的な情報を別個の「拡張ヘッダ」に再配置する。
- IPv6の「基本ヘッダ」の後ろに、必要に応じて「拡張ヘッダ」を追加する。

** IPv6拡張ヘッダの種類 [#s56d321a]
http://www.itbook.info/study/ipv6-4.html
IPv6拡張ヘッダは、RFC2460で6種類が定義されています。
+ ホップバイホップオプションヘッダ
+ 宛先オプションヘッダ
+ 経路制御ヘッダ
+ フラグメントヘッダ
+ 認証ヘッダ
+ カプセル化セキュリティペイロード（ESP：Encapsulated Security Payload）ヘッダ

http://www.ipv6style.jp/jp/tech/20030425/index.shtml
>IPv6では、基本ヘッダと拡張ヘッダを明確に区別し、基本ヘッダの後に拡張ヘッダを続ける構成としている。
基本ヘッダは40バイトの固定長で、すべてのIPv6パケットにつけられる。
拡張ヘッダはあくまでオプションであり、付加サービスが使われない場合はつけられない。

>拡張ヘッダは、その役割に応じていくつかの種類がある。
複数の付加サービスを使う場合には、それぞれの役割ごとの拡張ヘッダが数珠つなぎでつけられる。
IPv6基本ヘッダのなかにNext Headerという8ビットのフィ—ルドが見られる。
これを見ると、次に拡張ヘッダがあるのか、ないのかが分かる。
拡張ヘッダが使われない場合、IPレイヤの情報は基本ヘッダのみとなり、次に続くのは1つ上のレイヤのTCPヘッダあるいはUDPヘッダなので、そのどちらであるかがNext Headerフィールドに示される。
拡張ヘッダが使われる場合、どの種類の拡張ヘッダが次にくるのかが示される。

>''拡張ヘッダの種類''
拡張ヘッダの種類としては、ホップバイホップ・オプション、デスティネーション・オプション、ルーティング、フラグメント、認証（Authentication）、ESP（Encapsulating Security Payload）の6種類が用意されている。
複数の種類の拡張ヘッダを併用する場合には、この順番でつなげることが望ましいとされている。 

*** (1) ホップバイホップ・オプション [#dcc517df]
拡張ヘッダは基本的に終点ノードによってのみ処理されるものと説明したが、その唯一の例外がホップバイホップ・オプション・ヘッダである。
文字通り、パケットがルータを通るごとに実行されなければならない処理を指定するために用意されている。
用途は特に限定されていない。
例としてはJumbogramオプション（RFC2675）がある。
IPv6基本ヘッダにあるPayload Length（IPv6ヘッダを除くパケットの長さ）フィードは16ビットであるため、65536オクテットまでしか指定できないが、これを超えたサイズのパケットを送る必要がある場合に、拡張ヘッダで長さを指定しなおそうというのがJumbogramオプションである。

*** (2) デスティネーション・オプション [#o0e6a57a]
デスティネーション（宛先）・オプション・ヘッダは、宛先ノードによって実行される処理を指定するために用意されているヘッダである。
用途は特に限定されていない。
IPv6における拡張ヘッダは、基本的にすべて宛先ノードによってのみ処理されるものということはすでに述べた。
その意味では、フラグメント・ヘッダなどもデスティネーション・オプションと同じだと言える。
しかし、デスティネーション・オプションでは、さまざまな処理を指定できるところに違いがある。

*** (3) ルーティング [#r27d4722]
ルーティングヘッダは、ルーティング経路を指定するための情報を埋め込むものである。
これにより、プロバイダを選択するなど、特定の用途のためにパフォーマンスを確保することが可能になる。
始点ノードは、このパケットが通過しなければならないルータのアドレスを、ルーティングヘッダ内にリストして示す。
このリスト内のアドレスは、次々にこのIPv6パケットの宛先アドレスとして割り当てられることによって、バケツリレー式にパケットが転送されていくことになる。

*** (4) フラグメント [#r2e49a7a]
フラグメント・ヘッダは、IPv6パケットの送信元が、Path MTUよりも大きなパケットを送りたいときに、組み立て方を宛先に指示するためのヘッダである。
まず、[[MTU]]（最大転送単位）とは文字通り送信パケットの最大サイズのことだ。
インターネットのようなネットワークでは、宛先ノードまでの間にどれほど細い経路があるのかが大きな問題となる。
細い経路に大きなサイズのパケットを無理やり通そうとしても、溢れてしまうからである。
IPv4の世界では、パケットの経路に存在する各ルータが、各インタフェースに設定されるMTU値にしたがって、パケットを分割する作業を実行することができる。
しかし、この作業はルータに大きな負担となる。
したがって、IPv6では、パケットの分割は送信元ノードだけが行うこととしている。
　
IPv6における送信元ノードは、Path MTU Discoveryという作業を行い、特定の経路においてもっとも狭い帯域の部分を検出し、1つひとつのパケットのサイズをその細さに合わせて送る。
言い方を変えれば、広い帯域が宛先ノードまで完全に確保されていれば、1つひとつのパケットを大きなサイズで送ることができる。
　
送信元のアプリケーションがこのメカニズムに対応していれば、アプリケーションからのデータが最適なサイズで出てくるため、IPレイヤでは特に処理をする必要がない。
しかし、アプリケーションが対応していない場合、Path MTU Discoveryによって発見されたMTUよりも大きなパケットを吐き出してくることになる。
これを適切なMTU値に合わせるためのパケット分割が、送信元ノードのIPレイヤで実行されることになる。
この際に使われるのがフラグメント・ヘッダだ。

*** (5) 認証、(6) ESP [#s8683d54]
IPレイヤにおけるセキュリティの仕組みとして知られているのが[[IPsec]]である。
IPv6ノードは、[[IPsec]]を実装していなければならないとされている。
しかし、実装と利用とは話が別であり、[[IPsec]]による通信を実際に使うかどうかは、時と場合によって異なる。
[[IPsec]]が利用される場合、パケットの[[認証]]と、データ内容の一貫性の保証のための認証ヘッダや、データの暗号化に関する情報を示す[[ESP]]ヘッダは、拡張ヘッダとして組み込まれる。
IPsecは、IPv4の世界でも共通に使えるメカニズムとして規定されているが、IPv4ではこれらの情報はOptionsフィールドに入れられていた。 

** リンク [#r395048a]
[[IP]]
[[ヘッダ]]

IPv4
http://ja.wikipedia.org/wiki/IPv4

IPv6
http://ja.wikipedia.org/wiki/IPv6

#norelated
トップ   編集 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS