1999/06/28

ネットワーク（11）

UDP (User Datagram Protocol)

[IP Datagram]
|<-----------------IP datagram---------------------->|
|               |<-------- UDP datagram------------->|
+---------------+----------+-------------------------+
|   IP Header   |UDP Header|    UDP data             |
+---------------+----------+-------------------------+
|<-- 20 byte -->|<- 8byte->|                         |

[UDP Header]
                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (32bits width)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Srouce Port              |     Destination Port          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Length                 |        Checksum               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|             your data ...                                     |
                  ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Length = UDP Headerの長さ + UDP Dataの長さ

transport layer (トランスポート層) のプロトコルの1つ。
信頼性がない。つまり、 IP層に送ったデータグラムが相手に届くかどうか保証しない。
UDPのチェックサム計算はオプションである(「デフォルトで有効にしておくべき」であると「ホスト要求RFC」では記述されているが)。チェックサムの計算をしていない場合は、値として0を入れる。計算の結果が0のときは、0xffffを入れて送る。
UDPのチェックサムは、UDP Header と UDP Data の両方に対して計算する。計算は16bit単位で、データ長が奇数の場合はpad byte (0)が付加されたものとして計算する。
(注)IP Headerに含まれるチェックサムは、 IP Header のみを対象にして(16bitの1の補数合計)チェックサムを計算する。
送り手がチェックサムを計算している場合、受け手がチェックサムのエラーを検出するとそのパケットは破棄される(エラーメッセージは生成しない)。

[UDP Checksum用の仮想ヘッダ]
                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (32bits width)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                (Source) IP Address                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               (Destination) IP Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       0       | protocol(17)  |        Length                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Srouce Port              |     Destination Port          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Length                  |        Checksum               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|              UDP data ...                                     |
                  ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP Fragmentation

物理ネットワーク層には、転送できるフレーム・サイズの上限がある。 IP層は、

転送すべきデータを受けとった時そのデータをどのローカル・インターフェイスに送るか決定する(routing)
送るインターフェイスのMTUを調べる
データがMTUより小さければそのまま送る。
データがMTUより大きければ fragmentation を行なう。

IP層のデータが一旦 fragment 化されると、最終の宛先に到達するまで re-assemble (fragment化されたデータを再びまとめること) されることはない。最終の宛先ホストに到達すると、そのIP層が re-assemble を行なう。トランスポート層 (tcp や udp)にとって fragmentやre-assemble されたことはわからない(透過的)。

fragment化されたデータがさらに fragment化されることがある。

[IP Header]
                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (32bits width)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|        Total Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Identification          |Flags|    Fragment Offset      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |       Header Checksum         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Source Address                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Destination Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|    TCP (or UDP) header, then your data ....                   |
                  ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Identification (識別子) フィールド
送り手が転送する各IPデータグラムに対して一意の値となる。 fragmentされたパケットでは同じ値となる。
Flagsフィールド
- "more fragments" ビット --- このbitがたっているパケットは最後のfragmentではない。
- "don't fragment" ビット --- このbitがonのパケットはfragment化してはいけない (大き過ぎる場合はパケットを破棄してICMP Errorを送り返す)。
Fragment Offset
fragmentパケットのデータはオリジナルのデータの先頭からどれだけずれているか。
Total Length
各フラグメントの大きさを表す(IP Headerを含む)。

fragment化されたIPパケットのうち、どれか一つでも失われた場合は、元のIPデータグラム全体が送り直されることになる(fragmentationは TCPやUDPに対して透過的なので)。

[IP Fragmentation on Ethernet]
|<-----------------IP datagram---------------------->|
|<-- 20 byte -->|<- 8byte->|<-------1473byte-------->|
+---------------+----------+-------------------------+
|   IP Header   |UDP Header|    UDP data             |
+---------------+----------+-------------------------+

|<-----------------IP packet----------------------->|  |<---IP packet--->|
|<-- 20 byte -->|<- 8byte->|<------1472byte-------->|  |<-- 20 byte -->| |
+---------------+----------+------------------------+  +---------------+-+
|   IP Header   |UDP Header|    UDP data            |  |   IP Header   | |
+---------------+----------+------------------------+  +---------------+-+
                                                                        ^1byte

(用語に関する注意)

データグラム --- IP層が扱う転送単位(fragmentationの前と re-assembleの後で)。
パケット --- IP層とリンク層との間で渡されるデータの単位。「完全なIPデータグラム」と「IPデータグラムのフラグメント」のどちらの場合もある。

ICMP Destination Unreachable (Fragmentation Needed)

[ICMP Error Message: Port Unreachable]
                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (32bits width)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type       |     Code      |        Checksum               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Unused (must be 0)      |   MTU of next hop network     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  ...                                          |
|             IP Header of Original IP Packet                   |
|                  ...                                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             First 8 byte Data of Original IP Packet           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    type =3: ICMP Destination Unreachable (宛先到達不能) 
    code = 4: Fragmentation Needed and Don't Fragment was Set

(例) p.171 Fig.11.10: 「netb → sun のMTU」を決定したい場合
                   552   SLIP    ???
       bsdi    sun------------------netb    solaris
    1500|   1500|                     |1500   |1500
      ============              ======================
        ETHERNET                       ETHERNET
(予想)
                    <-- <--             <----
                fragment化されたデータ  ICMP echo request(ping)
(実験結果)
        <----        <----              <----   ICMP echo request(ping)
        ----> ICMP echo reply
        <---- ICMP Destination Unreachable

solarisからbsdiにpingを打つ。 fragment化された受信パケットが届くまでデータパケットのサイズを大きくしていく。
sun上で tcpdump を利用する。
500byteまでの大きさのpingは大丈夫だったが、600byteのパケットでecho応答が返ってこなくなった。
原因追求
- ping要求で "Don't Fragment" を On にすると、ping応答でも "Don't Fragment" が On になる。
- ping 応答が大き過ぎて sun->netbで fragment化が必要になった。
SNMPを使うとnetb→sunのMTUがわかる(25章)

tracerouteを用いたpath MTU の決定

tracerouteで "Dont't Fragment" を On にしてパケットを送る。 ICMP Error Message (type=3,code=4)を受けとったら、

「次のネットワークのMTU」の値が0以外のとき、そのMTUの値を採用する。
それ以外では、パケットのサイズを小さくして送り直す。

 (例) path MTU discovery機能がサポートされていない場合
sun% traceroute.pmtu  slip
  1    bsdi (140.25213.35)  15 ms  6 ms  6 ms
  2    bsdi (140.252.13.35) 6 ms
fragmentation required and DF set, trying new MTU = 1492
fragmentation required and DF set, trying new MTU = 1006
    ...
fragmentation required and DF set, trying new MTU = 296
  2    slip (140.252.13.65)  377 ms  378 ms  377 ms

UDPによる path MTU discovery

solarisのみが「path MTU discovery機能をサポート」しているとする。 solaris から slip に 650 byte の datagram を "don't fragment" ビットをonにして送る。

(例)      図11.13: UDPによる path MTU discoveryの例
      296 SLIP 296        552    SLIP    1500
    slip--------bsdi    sun------------------netb    solaris
             1500|   1500|                    |1500   |1500
              ==============            ======================
                ETHERNET                       ETHERNET

bsdi から solarisに ICMP Destination Unreachable Message (Fragementation needed and Don't Fragment was Set) を返す。 bsdiから送られるICMP Messageが、「次のネットワークのMTU」を含んでいればただちに path MTU がわかる。

そうでない場合は、一度に送るサイズを小さくしたり、DF (DOn't Fragment) ビットを 0 にしたりする(Fig.11.4)。

UDPとARPの間のやりとり

8Kbyte (=8192byte) のデータを含むUDPデータグラムを生成する。

    UDP Header + UDP Data
    = 8 + 8192
    = (1500  -  20) * 5 + 800
       ^^^^MTU  ^^IP Header

なので、1480byteのパケット5個と800byteのパケット1個が送出されることが期待される。

 Fig.11.17 Ethernetに8192byteのUDPデータグラムを送る
  1  0.0                arp who-has svr4 tell bsdi
  2  0.001234 (0.0012)  arp who-has svr4 tell bsdi
  3  0.001941 (0.0007)  arp who-has svr4 tell bsdi
  4  0.002775 (0.0008)  arp who-has svr4 tell bsdi
  5  0.003495 (0.0007)  arp who-has svr4 tell bsdi
  6  0.004319 (0.0008)  arp who-has svr4 tell bsdi
  7  0.008772 (0.0045)  arp reply svr4 is-at 0:0:c0:c2:9b:26
  8  0.009911 (0.0011)  arp reply svr4 is-at 0:0:c0:c2:9b:26
  9  0.011127 (0.0012)  bsdi > svr4: (frag 10863:800@7400)
 10  0.011255 (0.0001)  arp reply svr4 is-at 0:0:c0:c2:9b:26
 11  0.012562 (0.0013)  arp reply svr4 is-at 0:0:c0:c2:9b:26
 12  0.013458 (0.0009)  arp reply svr4 is-at 0:0:c0:c2:9b:26
 13  0.014526 (0.0011)  arp reply svr4 is-at 0:0:c0:c2:9b:26
 14  0.015583 (0.0011)  arp reply svr4 is-at 0:0:c0:c2:9b:26

Fig.11.17 を見ると、

IPが6個のパケットを作る(fragment)それぞれのパケットがARP要求を生成する。
最初のARP応答を受けとると(7行目)、最後のフラグメントだけを送信する (ARP応答を待つ間、最後のパケットだけを保持する実装が一般的)。
ICMP TIME Exceed (Fragment Reassembly Time Exceeded, Type=11, code=1) は srv4から bsdi には返されない。 Berkeley Unixではパケットを破棄するだけ。また今回の最初のパケットが届かないので(Port番号などがわからないので) ICPMエラーを返さなくてもよい)。

UDPデータグラムの長さの最大値

IP Headerの "Total Length" フィールドは 16bit 幅なので、理論的なIPデータの最大値は

65535 - 20 - 8 = 65507

しかし、実際はこれよりも小さい値をとる。少なくとも576byte以上 (RIPが 512byte以下のパケットになるように流していたことを思い出そう)である必要があるが、多くの実装では NFS のデフォルトサイズ8192byteよりも大きくなっている。

ICMP Source Quench Error Message

受信したデータグラムが処理できないほど速く流れてきている場合は、 ICMP 発信元抑制 (type=4, code=0) エラーメッセージを返して *もよい* 。

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (32bits width)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   type (4)    |   code (0     |         checksum              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               unused (must be 0)                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  ...                                          |
|             IP Header of Original IP Packet                   |
|                  ...                                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             First 8 byte Data of Original IP Packet           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+