Internet Control Message Protocol for IPv6
| TCP/IP群 | |
|---|---|
| アプリケーション層 | |
|
BGP / DHCP / DNS / FTP / HTTP / IMAP / IRC / LDAP / MGCP / NNTP / NTP / POP / RIP / RPC / RTP / SIP / SMTP / SNMP / SSH / Telnet / TFTP / TLS/SSL / XMPP カテゴリ |
|
| トランスポート層 | |
|
TCP / UDP / DCCP / SCTP / RSVP / ECN カテゴリ |
|
| ネットワーク層 | |
|
IP (IPv4, IPv6) / ICMP / ICMPv6 / IGMP / IPsec カテゴリ |
|
| リンク層 | |
|
ARP/InARP / NDP / OSPF / トンネリング (L2TP) / PPP / MAC (イーサネット, IEEE 802.11, DSL, ISDN, FDDI) カテゴリ |
Internet Control Message Protocol for IPv6（ICMPv6）はIPv6で用いられるICMPプロトコルである。 IPv6ではICMPv6の枠組みを利用して、アドレス解決やアドレス重複検出などにも利用し、type番号もICMP(IPv4)のものとは違う番号が定義し直されているので、IPv4のICMPとは異なる新しいプロトコルとして定義されている。 プロトコル番号は58。 RFC 4443 によって規定されている。
目次 |
パケットフォーマット[編集]
パケットフォーマット自体はICMPと同一。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Message Body +
| |
各type毎にoptionが定義されることがある。
type[編集]
通知の種類が入る。 エラー通知は127以下、そうでないものは128以上の値が定義される。
| 1 | 宛先不達(Destination Unreachable) | RFC 4443 Section 3.1 |
| 2 | パケット過大(Packet too Big) | RFC 4443 Section 3.2 |
| 3 | 時間切れ(Time Exceeded) | RFC 4443 Section 3.3 |
| 4 | パラメータ異常(Parameter Problem) | RFC 4443 Section 3.4 |
| 128 | エコー要求 (Echo Request) | RFC 4443 Section 4.1 |
| 129 | エコー応答 (Echo Reply) | RFC 4443 Section 4.2 |
| 130 | マルチキャストリスナクエリー (Multicast Listener Query) | RFC 2710 Section 3.1 |
| 131 | マルチキャストリスナレポート (Multicast Listener Report) | RFC 2710 Section 3.1 |
| 132 | マルチキャストリスナダン (Multicast Listener Done) | RFC 2710 Section 3.1 |
| 133 | ルーター要請 (router solicitation) | RFC 4861 Section 4.1 |
| 134 | ルーター広告 (router advertisement) | RFC 4861 Section 4.2 |
| 135 | 近隣要請 (Neighbor solicitation) | RFC 4861 Section 4.3 |
| 136 | 近隣広告 (Neighbor advertisement) | RFC 4861 Section 4.4 |
| 137 | リダイレクト (redirect) | RFC 4861 Section 4.5 |
| 138 | ルータリナンバ (Router Renumber) | RFC 2894 Section 3.1 |
| 139 | ノード情報問い合わせ(Node Information Query) | RFC 4620 Section 4 |
| 140 | ノード情報応答(Node Information Reply) | RFC 4620 Section 4 |
| 141 | 逆近隣探索要請 (Inverse Neighbor Discovery Solicitation) | RFC 3122 Section 2.1 |
| 142 | 逆近隣探索広告 (Inverse Neighbor Discovery Advertisement) | RFC 3122 Section 2.2 |
| 143 | MLDv2 マルチキャストリスナレポート (Multicast Listener Report) | RFC 3810 Section 5.2 |
| 144 | ホームエージェントアドレス発見要求 (Home Agent Address Discovery Request) | RFC 3775 Section 6.5 |
| 145 | ホームエージェントアドレス発見応答 (Home Agent Address Discovery Reply) | RFC 3775 Section 6.6 |
| 146 | モバイルプリフィックス要請(Mobile Prefix Solicitation) | RFC 3775 Section 6.7 |
| 147 | モバイルプリフィックス広告(Mobile Prefix Advertisement) | RFC 3775 Section 6.8 |
| 148 | 証明書パス要請(Certification Path Solicitation) | RFC 3971 Section 6.4.1 |
| 149 | 証明書パス広告(Certification Path Advertisement) | RFC 3971 Section 6.4.2 |
code[編集]
type毎に定義された値が入る。
エラー通知[編集]
ICMPと同様にパケット配送中に発生したエラーを通知する。
近隣探索 (Neighbor discovery)[編集]
IPv6 では IP アドレスから MAC アドレスを取得するために、IPv4 の ARP のような別のプロトコルを定義するのではなく、ICMPv6 の枠組みを用いてアドレス解決を行う。アドレス解決をしたいノードはペイロードに解決したいアドレスを格納して、全ノード宛マルチキャストアドレスに IPv4 の ARP request に相当する Neighbor Solicitation (NS) パケットを送信し、それに答えるべきノードは、Target linklayer address option に自ノードの MAC アドレスを格納した Neighbor Advertisement (NA) を送信してアドレス解決を行う。 RFC 4861 で規定されている。
ルータ広告[編集]
ルータ広告自体は ICMP でも定義されている (RFC 1256) が、IPv6 では DHCP などのようなアドレス割当用サーバがなくても、ノードが自力でアドレスを設定する (ステートレスアドレス自動設定 (RFC 4862)) 手段を提供するために、積極的にこのルータ広告が利用されている。 これも広い意味での Neighbor Discovery であり、RFC 4861 で規定されている。
重複アドレス検出[編集]
アドレスを手動で設定したり、ステートレスアドレス自動設定でつけた場合は、そのアドレスの一意性を確認できないので、重複アドレス検出 (Duplicate Address Detection; DAD) で、その一意性を確認する。 RFC 4862 Section 5.4 で規定されている
あるノードにアドレスがつけられると、そのアドレスは 'TENTATIVE' という状態になり、アドレスの重複検出を行う。これは target アドレスにその重複検出をするアドレスを入れた、アドレス解決で利用される近隣要請 (Neighbor Solicitation) を送出するものである。 もし、既にそのアドレスを使っているノードがあれば近隣広告 (Neighbor Advertisement; NA) を返すので、アドレスの重複が検出できる。 1 秒以内に NA が返ってこないと、そのアドレスは重複無しと判断され、利用可能アドレスとなる。
パスMTU探索 (Path MTU Discovery)[編集]
IPv6のパケット断片化は配送中のルータではなく、送信元のみで行われるので、送信元は配送される全経路で通過できるパケットのサイズ(パスMTU)を知らなければならない。これを行うのがパスMTU探索である。 RFC 1981で規定されている。
あるノードから送信されるパケットは、そのインタフェースのMTU値などなるべく大きな値のMTU値を用いて送信される。途中のルータで転送先のインタフェースのMTU値がそのパケットより小さければ、そのルータは送信元に「パケット過大(Packet too big)」エラーを返す。このとき送信可能なMTU値も返されるので、送信元はその値でパケットをフラグメントして再び送信する。これを繰り返すことで、送信元は送信先まで到達可能なMTU値(パスMTU)を知ることができ、以降は始めからその値でフラグメントして送信することができるようになる。
ノード情報問い合わせ[編集]
IPv6ノードに対して、直接そのノードのノード名、アドレスなどを問い合わせをするプロトコルである。 RFC 4620 では、ノード名(FQDN)、IPv6アドレス、IPv4アドレスの問い合わせプロトコルについて規定している。
 |
この項目は、コンピュータに関連した書きかけの項目です。この記事を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |
