「IPv6パケット」の版間の差分
削除された内容 追加された内容
{{IPv6}} |
Akiomorisita (会話 | 投稿記録) 編集の要約なし |
||
| (10人の利用者による、間の15版が非表示) | |||
1行目:
{{Pathnav|IPv6|frame=1}}
'''IPv6パケット'''は、[[IPv6]]ネットワークの[[Internet Protocol|インターネットプロトコル]]によって[[パケット通信|交換]]される最小メッセージ[[エンティティ|エンティティー]]である。
これらの[[パケット]]はアドレッシング、[[ルーティング]]、ユーザデータからなる[[ペイロード (コンピュータ)|ペイロード]]、のための制御情報で構成されている。IPv6パケット内の制御情報は、必須の「'''固定ヘッダ'''」と任意の「'''拡張ヘッダ'''」に分かれる。IPv6パケットのペイロードは、通常は[[データグラム]]もしくはより上位層の[[トランスポート層]]プロトコルのセグメントが入るが、[[インターネット層]]（[[ICMPv6]]など）や[[データリンク層]]（[[OSPF]]など）のデータであっても良い。
通常IPv6パケットは
IPv6では、[[ルーター]]はIPv6パケットを断片化（[[IPフラグメンテーション]]を参照）せず、送信元ノードのみが断片化を行う（IPv4ではヘッダ内のフラグによって禁止されていないパケットであれば、途中のルータでも断片化をすることがある）。送信元ノードが[[IPv6パケット#フラグメント|IPv6フラグメント拡張ヘッダ]]と共に断片化したパケットを送信することにより、宛先ノードはそのパケットを再構築することができる<ref name="rfc2460" />。最小[[Maximum Transmission Unit|MTU]]である1280[[オクテット (コンピュータ)|オクテット]]よりも大きいMTUを利用するために、[[ホスト (ネットワーク)|ホスト]]は[[Maximum Transmission Unit#経路MTU探索|経路MTU探索]]を実行することを「強く推奨」されている<ref name=rfc2460>[[スティーブ・ディアリング|Deering, S.]]; Hinden, R. (December 1998). [//tools.ietf.org/html/rfc2460 Internet Protocol, version 6 (IPv6) Specification]. [[Internet Engineering Task Force|IETF]]. RFC{{nbsp}}2460.</ref>。
2017年7月から、[[Internet Assigned Numbers Authority|IANA]]が様々なIPv6ヘッダで使用されるすべてのIPv6[[パラメータ]]の登録者となっている。
== 固定ヘッダ ==
IPv6パケットの固定ヘッダは40オクテット（320[[ビット]]）の固定長で構成されている<ref name="rfc2460" />。以下にヘッダフォーマットを示す。
:{| class="wikitable" style="text-align: center"
|+固定ヘッダフォーマット
|-
! style="border-bottom:none; border-right:none;" |''オフセット''
! style="border-left:none;" |[[オクテット (コンピュータ)|オクテット]]
! colspan="8" | 0
! colspan="8" | 1
! colspan="8" | 2
! colspan="8" | 3
|-
! style="border-top: none" |[[オクテット (コンピュータ)|オクテット]]
![[ビット]]
! style="width:2.6%;" | 0
! style="width:2.6%;" | 1
! style="width:2.6%;" | 2
! style="width:2.6%;" | 3
! style="width:2.6%;" | 4
! style="width:2.6%;" | 5
! style="width:2.6%;" | 6
! style="width:2.6%;" | 7
! style="width:2.6%;" | 8
! style="width:2.6%;" | 9
! style="width:2.6%;" | 10
! style="width:2.6%;" | 11
! style="width:2.6%;" | 12
! style="width:2.6%;" | 13
! style="width:2.6%;" | 14
! style="width:2.6%;" | 15
! style="width:2.6%;" | 16
! style="width:2.6%;" | 17
! style="width:2.6%;" | 18
! style="width:2.6%;" | 19
! style="width:2.6%;" | 20
! style="width:2.6%;" | 21
! style="width:2.6%;" | 22
! style="width:2.6%;" | 23
! style="width:2.6%;" | 24
! style="width:2.6%;" | 25
! style="width:2.6%;" | 26
! style="width:2.6%;" | 27
! style="width:2.6%;" | 28
! style="width:2.6%;" | 29
! style="width:2.6%;" | 30
! style="width:2.6%;" | 31
|-
! 0
! 0
| colspan="4" |''バージョン''
| colspan="8" |''トラフィッククラス''
| colspan="20" |''フローラベル''
|-
! 4
! 32
| colspan="16" |''[[ペイロード (コンピュータ)|ペイロード]]長''
| colspan="8" |''次ヘッダ''
| colspan="8" |''ホップ制限''
|-
! 8
! 64
| colspan="32" rowspan="4" |''送信元アドレス''
|-
! 12
! 96
|-
! 16
! 128
|-
! 20
! 160
|-
! 24
! 192
| colspan="32" rowspan="4" |''宛先アドレス''
|-
! 28
! 224
|-
! 32
! 256
|-
! 36
! 288
|}
; ''バージョン''（4ビット）:IPバージョン。6（二進数では<tt>0110</tt>）が必ず入る。
; ''トラフィッククラス''（6+2ビット）:このフィールドは[[Quality of Service|QoS]]に関連する二つの値を持つ。上位6ビットは[[DiffServ]](DS)フィールドで、パケットを分類するために使われる<ref name=rfc2474>{{Cite IETF|rfc=2474|author=K. Nickols|author2=S. Blake|authorlink3=Fred Baker (IETF chair)|author3=F. Baker|author4=D. Black|date=December 1998|title=Definition of the Differentiated Service Field (DS Field) in the IPv4 and IPv6 Headers}}</ref><ref name=rfc3260>{{Cite IETF|rfc=3260|author=D. Grossman|date=April 2002|title=New Terminology and Clarifications for DiffServ}}</ref>。現在、すべての標準的なDSフィールドは「0」ビットで終わる。2連続の「1」ビットで終わるDSフィールドはローカル・実験的使用が予定されている<ref name="rfc47272">{{Cite IETF|rfc=4727|title=Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers|author=B. Fenner|publisher=Network Working Group|date=November 2006}}</ref>。
: 残りの下位2ビットは[[明示的輻輳通知]](Explicit Congestion Notification, ECN)に使われる<ref name=rfc3168>{{Cite IETF|rfc=3168|author=K. Ramakrishnan|author2=S. Floyd|author3=D. Black|date=September 2001|title=The Addition of Explicit Congestion Notification (ECN) to IP}}</ref>。優先値は複数の範囲に細分される。送信元ノードが輻輳制御を提供するトラフィックと、輻輳制御なしのトラフィックである。
; ''フローラベル''（20ビット）:元々は[[リアルタイムコンピューティング|リアルタイムアプリケーション]]サービスを提供するために作られ<ref name="rfc2460" />、QoSに近い目的を持ったフィールド。0ではない値を入れると、対応するルーターや[[スイッチングハブ|スイッチ]]は同じフローラベル・送信元アドレス・宛先アドレスを持つパケットを同じ経路で転送するため<ref name=rfc3595>{{Cite IETF|rfc=3595|author=B. Wijnen|date=September 2003|title=Textual Conventions for IPv6 Flow Label}}</ref><ref name=rfc6437>{{Cite IETF|rfc=6437|author=S. Amante|author2=B. Carpenter|author3=S. Jiang|author4=J. Rajahalme|date=November 2011|title=IPv6 Flow Label Specification}}</ref>、パケットが並べ替えられることを防ぐことができる。
; ''ペイロード長'' （16ビット）:オクテット単位で指定された、すべての拡張ヘッダを含むペイロードのサイズ。ただしホップバイホップ拡張ヘッダが[[IPv6パケット#ジャンボグラム|ジャンボペイロード]]オプションを持つときは0が入る<ref name=rfc2675>{{Cite IETF|rfc=2675|author=D. Borman|authorlink2=Steve Deering|author2=S. Deering|author3=R. Hinden|date=August 1999|title=IPv6 Jumbograms}}</ref>。
; ''次ヘッダ''（8ビット）:次ヘッダのタイプを指定する。拡張ヘッダが使われない場合、上位層である[[トランスポート層]]プロトコルを指定する。このフィールドはIPv4のプロトコルフィールドと同じ機能を持つため、この値はIPv4のプロトコル番号と共有されている（詳細は[[プロトコル番号一覧]]）。
; ''ホップ制限''（8ビット）:IPv4の[[time to live]](TTL)とほぼ同等。この値はルーターを通過するたびに1ずつ減っていき、0になるとパケットは破棄される。ただし宛先ノードはホップ制限が0になっても通常通りパケットを処理する。
; ''送信元アドレス''（128ビット）:送信元ノードの[[IPv6アドレス]]。
; ''宛先アドレス''(128 bits):宛先ノードのIPv6アドレス。
パフォーマンス向上のため、また現在のデータリンク層技術及びトランスポート層・アプリケーション層プロトコルは十分な[[誤り検出訂正|誤り検出]]能力を持っていると見込んで<ref name="rfc1726">{{Cite IETF|rfc=1726|author=C. Partridge|author2=F. Kastenholz|date=December 1994|title=Technical Criteria for Choosing IP The Next Generation (IPng)|section=6.2}}</ref>、このヘッダは誤り検出用の[[チェックサム]]を持たない。
== 拡張ヘッダ ==
拡張ヘッダは任意の[[インターネット層]]の情報を持ち、固定ヘッダと上位層プロトコルヘッダの間に位置する<ref name="rfc2460" />。次ヘッダフィールドを使用しヘッダは数珠つなぎになっている。固定ヘッダの次ヘッダフィールドは最初の拡張ヘッダのタイプを示し、最後の拡張ヘッダの次ヘッダフィールドはペイロードに含まれる上位層プロトコルのタイプを示す。
全ての拡張ヘッダのサイズは8オクテットの倍数であり、いくつかの拡張ヘッダはこの条件を満たすため[[パディング]]（意味を持たないデータ）を含むことがある。
複数の拡張ヘッダが定義されていて<ref name="rfc2460" />、将来さらに新しい拡張ヘッダが定義される可能性がある。パケットの経路上にあるすべての中間ノードが処理する必要のあるホップバイホップ拡張ヘッダを除き、拡張ヘッダは宛先ノードでしかチェック・処理されない。下に定義された拡張ヘッダは固定ヘッダに続く優先的な並びにリストされている。すべての拡張ヘッダは任意であり、かつ一回しか使われない（ただし2回使うことができる宛先オプションを除く）ことに注意されたし。
もしノードがある拡張ヘッダを認識できないときには、ノードはパケットを破棄しパラメーター異常([[ICMPv6]] type4, code1)メッセージを送信する<ref name="rfc2460" />。固定ヘッダ以外のヘッダで次ヘッダの値が0のときも同様である。
:{| class="wikitable" <!-- Listed in order as recommended by RFC8200 -->
|-
! 拡張ヘッダ
![[プロトコル番号一覧|タイプ]]
! 説明
|-
| ''[[IPv6パケット#ホップバイホップオプションと宛先オプション|ホップバイホップオプション]]''
| | 0 || 経路上にあるすべてのデバイスでチェックされる必要のあるオプション。
|-
| ''[[IPv6パケット#ホップバイホップオプションと宛先オプション|宛先オプション]]''（ルーティングヘッダの前）<!-- ヘッダチェインの中で二回使われます。 -->
| | 60 || パケットの宛先でしかチェックされる必要のないオプション。
|-
| ''[[IPv6パケット#ルーティング|ルーティング]]''
| | 43 || データグラムの経路を指定するためのメソッド（[[Mobile IP|Mobile IPv6]]で使われる）。
|-
| ''[[IPv6パケット#フラグメント|フラグメント]]''
| | 44 || データグラムの断片化についての情報が含む。
|-
| ''[[IPv6パケット#認証ヘッダ(AH)とカプセル化セキュリティーペイロード(ESP)|認証ヘッダ(AH)]]''
| | 51 || パケットのほとんどの部分の信ぴょう性を検証するために使われる情報を含む。
|-
| ''[[IPv6パケット#認証ヘッダ(AH)とカプセル化セキュリティーペイロード(ESP)|カプセル化セキュリティーペイロード(ESP)]]''
| | 50 || 安全な通信のための暗号化されたデータを持つ。
|-
|''[[IPv6パケット#ホップバイホップオプションと宛先オプション|宛先オプション]]''（上位層プロトコルヘッダの前）<!-- ヘッダチェインの中で二回使われます。 -->
| | 60 || パケットの宛先でしか検査される必要のないオプション。
|-
| Mobility（currently without upper-layer header）<!-- {{IETF RFC|6275}} -->
| | 135 ||[[Mobile IPv6]]で使用されるパラメーター。
|-
| Host Identity Protocol (HIP) || 139 ||[[Host Identity Protocol]] version 2 (HIPv2)で使用される<ref name=rfc7401>{{Cite IETF|rfc=7401|title=Host Identity Protocol Version 2 (HIPv2)|editor=R. Moskowitz|author1=T. Heer|author2=P. Jokela|author3=T. Henderson|date=April 2015|publisher=[[Internet Engineering Task Force]] (IETF)|issn=2070-1721}}</ref>。
|-
| Shim6 Protocol || 140 ||[[Shim6]]で使用される。<ref name=rfc5533>{{Cite IETF|rfc=5533|title=Shim6: Level 3 Multihoming Shim Protocol for IPv6|author1=E. Nordmark|author2=M. Bagnulo
|date=June 2009|publisher=Networking Working Group}}</ref>
|-
| 予約 || 253 || 実験とテストに使用される<ref name=rfc3692>{{Cite IETF|rfc=3692|title=Assigning Experimental and Testing Numbers Considered Useful|author=T. Narten|date=January 2004|publisher=Network Working Group}} BCP 82. Updates {{IETF RFC|2434}}.</ref><ref name="rfc47272" />。
|-
| 予約 || 254 || 実験とテストに使用される<ref name=rfc3692/><ref name="rfc47272" />。
|}
次ヘッダフィールドが59（次ヘッダなし）のとき、上位層プロトコルを含めそのヘッダに続くヘッダはないことを示す。つまりそのヘッダの視点からすると、ペイロードは含まれずIPv6パケットはそのすぐ後に終了するように見える<ref name="rfc2460" />。しかしながら固定ヘッド内で指定されたペイロード長がパケット内のすべての拡張ヘッダの大きさよりも大きければ、データはペイロードとして含まれることができる。ホストはこのデータを無視するが、変更されないままルーターを通過することができる。
=== ホップバイホップオプションと宛先オプション ===
ホップバイホップオプション拡張ヘッダは送信元・宛先ノードを含む経路上にあるすべてのノードによってチェックされる必要がある。一方宛先オプション拡張ヘッダは宛先ノードのみによってチェックされる必要がある。これらの拡張ヘッダは最低でも8オクテットである必要がある。オプションがそれに収まりきらない場合、すべてのオプションが収まるまで8オクテットのブロック（オプションとパディングを含む）がヘッダに繰り返し追加される。
:{| class="wikitable" style="text-align: center"
|+
|-
! style="border-bottom:none; border-right:none;"| ''
! style="border-left:none;"|
! colspan="8" | 0
! colspan="8" | 1
27 ⟶ 172行目:
! colspan="8" | 3
|-
! style="border-top: none" |
! ビット
! style="width:2.6%;"| 0
! style="width:2.6%;"| 1
64 ⟶ 209行目:
! 0
! 0
| colspan="
| colspan="8"|''
| colspan="
|-
! 4
! 32
| colspan="
|-
! 8
! 64
| colspan="32" rowspan=
|-
! 12
! 96
|}
; ''次ヘッダ''（8ビット）:次ヘッダのタイプを指定する。
; ''拡張ヘッダ長''（8ビット）:最初の8オクテットを含まない、8オクテット単位で表されたこのヘッダのサイズ。
; ''オプション''（可変）:1つ以上のオプションと、オプションを整頓するため・ヘッダ長を8オクテットの倍数にするためのパディングを含む。オプションは[[Type-length-value|TLV]]フォーマット。
===ルーティング===
ルーティング拡張ヘッダは、パケットが宛先ノードに到達する前に経由する必要がある中間ノードを1つ以上指定するために使われる。このヘッダは最低でも8オクテットである必要がある。もしタイプ指定データが4オクテットに収まりきらない場合、すべてのタイプ指定データが収まるまで8オクテットのブロックがヘッダに繰り返し追加される<ref name="rfc2460" />。
:{| class="wikitable" style="text-align: center"
|+''ルーティング拡張ヘッダフォーマット''
|-
! style="border-bottom:none; border-right:none;"| ''オフセット''
! style="border-left:none;"| オクテット
! colspan="8" | 0
! colspan="8" | 1
! colspan="8" | 2
! colspan="8" | 3
|-
! style="border-top: none" | オクテット
! ビット
! style="width:2.6%;"| 0
! style="width:2.6%;"| 1
! style="width:2.6%;"| 2
! style="width:2.6%;"| 3
! style="width:2.6%;"| 4
! style="width:2.6%;"| 5
! style="width:2.6%;"| 6
! style="width:2.6%;"| 7
! style="width:2.6%;"| 8
! style="width:2.6%;"| 9
! style="width:2.6%;"| 10
! style="width:2.6%;"| 11
! style="width:2.6%;"| 12
! style="width:2.6%;"| 13
! style="width:2.6%;"| 14
! style="width:2.6%;"| 15
! style="width:2.6%;"| 16
! style="width:2.6%;"| 17
! style="width:2.6%;"| 18
! style="width:2.6%;"| 19
! style="width:2.6%;"| 20
! style="width:2.6%;"| 21
! style="width:2.6%;"| 22
! style="width:2.6%;"| 23
! style="width:2.6%;"| 24
! style="width:2.6%;"| 25
! style="width:2.6%;"| 26
! style="width:2.6%;"| 27
! style="width:2.6%;"| 28
! style="width:2.6%;"| 29
! style="width:2.6%;"| 30
! style="width:2.6%;"| 31
|-
!
!
| colspan="
| colspan="8"|''拡張ヘッダ長''
| colspan="8"|''ルーティングタイプ''
| colspan="8"|''残りセグメント''
|-
! 4
! 32
| colspan="32"|''タイプ指定データ''
|-
!
!
| colspan="32" rowspan="2"|タイプ指定データ（任意）...
|-
! 12
! 96
|}
; ''次ヘッダ'' （8ビット）:次ヘッダのタイプを示す。
; ''拡張ヘッダ長''（8ビット）:最初の8オクテットを含まない、8オクテット単位で表されたこのヘッダのサイズ。
; ''ルーティングタイプ''（8ビット）:[[IANA]]によって割り当てられた0から255までの値<ref name="iana_routing_options">{{Cite web|url=https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml|title=Internet Protocol Version 6 (IPv6) Parameters: Routing Types|publisher=[[IANA]]|accessdate=2017-11-17}}</ref>。
:{| class="wikitable" style="text-align: left"
!| タイプ
!| 状態
! style='width=500px' | コメント
|-
| 0
| 非推奨
| ルーティングヘッダタイプ0はシンプルだが効果的<ref>{{cite web|url=http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf|title=IPv6 Routing Header Security|author=Philippe Biondi, Arnoud Ebalard|date=April 2007|publisher=[[EADS]]|quote=Type 0: the evil mechanism...|accessdate=3 December 2010}}</ref>な[[DoS攻撃]]が行えるという事実から、このヘッダは2007年から非推奨であり<ref name="rfc5095">{{Cite IETF|rfc=5095|author=J. Abley|author2=P. Savola|author3=G. Neville-Neil|date=December 2007|title=Deprecation of Type 0 Routing Headers in IPv6}}</ref>、ホストとルーターはこのヘッダを無視しなければいけない。
|-
| 1
| 非推奨
|[[DARPA]]によって立ち上げられたNimrod<ref name="rfc1992">{{Cite IETF|rfc=1992|author=I. Castineyra|author2=N. Chiappa|author3=M. Steenstrup|date=August 1996|title=The Nimrod Routing Architecture}}</ref>プロジェクトに使われる。2009年から非推奨。
|-
| 2
| 許可
| タイプ0の制限バージョンで、[[Mobile IPv6]]（移動ノード(MN)のホームアドレス(HoA)を持つことができる）に使われる。
|-
| 3
| 許可
| 低パワー・非可逆ネットワーク向けのRPLソースルートヘッダ<ref name="rfc65542">{{Cite IETF|rfc=6554|title=An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)|author1=J. Hui|author2=JP. Vasseur|author3=D. Culler|author4=V. Manral|publisher=[[Internet Engineering Task Force]] (IETF)|date=March 2012}}</ref>。
|-
| 253 || 個人的使用
| テスト用に使われ、実際の実装ではない。''RFC3692-style Experiment 1''<ref name=rfc3692></ref>
|-
| 254 || 個人的使用
| テスト用に使われ、実際の実装ではない。''RFC3692-style Experiment 2''<ref name=rfc3692></ref>
|}
; ''残りセグメント''（8ビット）:宛先ノードに到達する前に経由しなければいけない残りのノード数。
; ''タイプ指定データ'' （可変）:このタイプのルーティングヘッダに属するデータ。
===フラグメント===
経路[[Maximum Transmission Unit|MTU]]よりも大きいパケットを送信するとき、送信元ノードはパケットを断片化（フラグメント）する。フラグメント拡張ヘッダは元のパケットを再構築するために必要な情報を持つ<ref name="rfc2460" />。
:{| class="wikitable" style="text-align: center"
|+フラグメント拡張ヘッダフォーマット
|-
! style="border-bottom:none; border-right:none;"| ''オフセット''
! style="border-left:none;"| オクテット
! colspan="8" | 0
! colspan="8" | 1
! colspan="8" | 2
! colspan="8" | 3
|-
! style="border-top: none" | オクテット
! ビット
! style="width:2.6%;"| 0
! style="width:2.6%;"| 1
! style="width:2.6%;"| 2
! style="width:2.6%;"| 3
! style="width:2.6%;"| 4
! style="width:2.6%;"| 5
! style="width:2.6%;"| 6
! style="width:2.6%;"| 7
! style="width:2.6%;"| 8
! style="width:2.6%;"| 9
! style="width:2.6%;"| 10
! style="width:2.6%;"| 11
! style="width:2.6%;"| 12
! style="width:2.6%;"| 13
! style="width:2.6%;"| 14
! style="width:2.6%;"| 15
! style="width:2.6%;"| 16
! style="width:2.6%;"| 17
! style="width:2.6%;"| 18
! style="width:2.6%;"| 19
! style="width:2.6%;"| 20
! style="width:2.6%;"| 21
! style="width:2.6%;"| 22
! style="width:2.6%;"| 23
! style="width:2.6%;"| 24
! style="width:2.6%;"| 25
! style="width:2.6%;"| 26
! style="width:2.6%;"| 27
! style="width:2.6%;"| 28
! style="width:2.6%;"| 29
! style="width:2.6%;"| 30
! style="width:2.6%;"| 31
|-
! 0
! 0
| colspan="8"|''次ヘッダ''
| colspan="8"|''予約''
| colspan="13"|''フラグメントオフセット''
| colspan="2"|''予約''
| colspan="1"|''M''
|-
! 4
! 32
| colspan="32"|''識別値''
|}
; ''次ヘッダ'' （8ビット）:次ヘッダのタイプを示す。
; ''予約''（8ビット/2ビット）:0に固定されている。
; ''フラグメントオフセット''（13ビット）:元のパケットの断片化可能な部分の開始部に関連した、8オクテット単位のオフセット。
; ''Mフラグ''（1ビット）:1はさらに断片が続くことを意味し、0はこれが最後の断片であることを意味する。
; ''識別''値（32ビット）:送信元ノードによって生成されるパケット識別番号。元のパケットの再構築に必要。
===認証ヘッダ(AH)とカプセル化セキュリティーペイロード(ESP)===
''[[IPsec#AH|認証ヘッダ(AH)]]と[[IPsec#ESP|カプセル化セキュリティ―ペイロード(ESP)]]''は[[IPsec]]の一部で、IPv6でもIPv4と同様に使用される<ref name=rfc4302>{{Cite IETF|rfc=4302|author=S. Kent|date=December 2005|title=IP Authentication Header}}</ref><ref name=rfc4303>{{Cite IETF|rfc=4302|author=S. Kent|date=December 2005|title=IP Encapsulating Security Payload}}</ref>。
==ペイロード==
固定もしくは任意のIPv6ヘッダの後には[[Transmission Control Protocol#TCPセグメント構造|TCPセグメント]]や[[User Datagram Protocol|UDPデータグラム]]などの[[トランスポート層]]のデータが入った[[ペイロード (コンピュータ)|ペイロード]]が続く。最後のIPv6ヘッダの次ヘッダフィールドはそのパケットにどのタイプのペイロードが含まれているかを示す。
===標準ペイロード長===
[[IPv6パケット#固定ヘッダ|IPv6のペイロード長フィールド]]は16ビットのサイズで、ペイロードのサイズを65,535オクテットまで指定することができる。パケットの断片化を防ぐため、ホストは[[Maximum Transmission Unit#経路MTU探索|経路MTU探索]]（送信元から宛先までのMTUを算出する）を行ってペイロード長を決める。ほとんどの[[データリンク層]]プロトコルのMTUは65,535オクテットよりかなり小さい。
===ジャンボグラム===
IPv6のオプショナルな機能として、ホップバイホップ拡張ヘッダのジャンボペイロードオプション<ref name=rfc2675/>を利用して約4[[Gigabyte|GB]](2<sup>32</sup>−1 = 4,294,967,295オクテット)までのペイロードをもつIPv6パケットを送信できる。そのようなペイロードを持つパケットはジャンボグラムと呼ばれる。なお、一般的に使われるトランスポート層プロトコルであるTCPとUDPはどちらも16ビットまでしか表せないフィールド（データ長及び緊急ポインタ）を持つことに注意が必要である。
==フラグメンテーション（断片化）==
IPv4と違い、IPv6ルーターはIPv6パケットを[[フラグメント|断片化]]（フラグメント）しない。IPv4でフラグメント禁止ビットが設定されているときのように、宛先ノードとの接続での[[Maximum Transmission Unit|MTU]]を超えるサイズのパケットは廃棄され、その状態がパケット過大([[ICMPv6]] type 2)メッセージとして送信元ノードに伝えられる<ref name="rfc2460" />。
送信するパケットの最大サイズを定めるため、IPv6の端末ノードは[[Maximum Transmission Unit#経路MTU探索|経路MTU探索]]を行うことが求められていて、上位層プロトコルはそれに従ってペイロードサイズを制限することが求められている。しかし上位層プロトコルがそれを行うことができない場合、送信元ノードがフラグメント拡張ヘッダを使いIPv6パケットのエンドツーエンドでの断片化を行う。IPv6のデータを転送するすべての[[データリンク層]]は、IPv6フラグメンテーションを呼び出さずに1280バイトのIPパケットを配送する能力を持っていなければいけない。
===断片化===
元のパケットの断片（フラグメント）を含むパケットは2つの部分からなる。元のパケット断片化不能な部分（すべての断片において共通）、そして[[IPv6パケット#フラグメント|フラグメントオフセット]]によって識別される元のパケットの断片化可能な部分である。最初の断片のフラグメントオフセットは0である<ref name="rfc2460" />。
パケットの断片化不能な部分は元のパケットの固定ヘッダと（存在すれば）いくつかの拡張ヘッダで構成されている。「いくつかの拡張ヘッダ」とは、ルーティング拡張ヘッダまでのすべての拡張ヘッダ、もしくはホップバイホップ拡張ヘッダのことである。それらの拡張ヘッダがない場合、断片化不可能な部分は単に固定ヘッダのみである。
断片化不能な部分の最後のヘッダの次ヘッダフィールドは、フラグメント拡張ヘッダが続くことを示すため44がセットされる。フラグメント拡張ヘッダの後には、 元のパケットの残りの断片が続く。
最初の断片（たち）は（存在すれば）拡張ヘッダを保持し、その後残りのペイロードが続く。最後の断片を除き、それぞれの断片の長さは8オクテットの倍数である。
またフラグが0になっている最後のパケットを除き、すべてのフラグメント拡張ヘッダのMフラグは1（まだ断片が続くことを示す）になっている。
===再構築===
宛先ノードはすべての断片を集め、それらを正しい[[オフセット (コンピュータ)|オフセット]]に配置し、パケットのフラグメント拡張ヘッダを廃棄することで元のパケットを再構築する。宛先ノードが正しく再配置するため、断片を含むパケットは順序正しく到達する必要がない。
もし断片を含む最初のパケットが到達してから60秒以内にすべての断片が到達しない場合、再構築は放棄されすべての断片は破棄される。この理由で再構築が放棄された場合、もし最初の断片（固定ヘッダを含む）が到達していたら、ICMPv6 type 3, code 1 時間切れ メッセージが断片化パケットを作成したノードに返される。
宛先ホストは再構築後に1500バイト以内となるような断片化したIPデータグラムは[[ベストエフォート]]で再構築しなければならない。ホストは断片化したデータグラムを1500バイトより大きく再構築することが許可されているが、同時に再構築後のパケットが1500バイトを超えることが明らかになった時点ですべてのデータグラムを暗黙のうちに破棄することが許可されている。したがって宛先ノードがそのような大きいデータグラムを再構築できるという確証がない限り、送信元ノードは再構築後のサイズが1500バイトより大きくなるような断片化したIPデータグラムを送ることは避けるべきである。
===セキュリティー===
断片化はネットワークセキュリティー制御を逃れるために使うことができると調査が示している。その結果、今ではIPv6パケットの最初の断片がIPv6ヘッダチェーンすべてを含むことが要求されていて<ref name=rfc7112>{{Cite IETF|rfc=7112 |title=Implications of Oversized IPv6 Header Chains |author=F. Gont|author2=V. Manral|author3=R. Bonica|date=January 2014}}</ref>、そのような異常なパケットの断片化は禁止されている。さらに、ルーターアドバータイズメント(RA)ガード回避の調査の結果<ref name=rfc7113>{{Cite IETF|rfc=7113 |title=Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) |author=F. Gont |date=February 2014}}</ref>、断片化を[[近隣探索プロトコル|近隣探索]]とともに使用することは非推奨となり、断片化をセキュア近隣探索(SEND)とともに使用することは推奨されなくなった<ref name=rfc6980>{{Cite IETF|rfc=6980 |title=Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery|author=F. Gont |date=August 2013}}</ref>。
== 出典・脚注 ==
| |||