みなさんこんにちは！
（スキルアップIT講座）です。
今回は、イーサネットフレームの構造とデータリンク層アドレス
について学びましょう。
前提として、ネットワーク階層モデルとイーサネットの知識を必要とします。「インターネットワーキング」及び「イーサネット」を未受講の方はそちらから受講した方が良いでしょう。
TCP/IPプロトコルスイートではデータリンク層のプロトコルを規定していません。しかし、現在主流のデータリンク層のプロトコルはイーサネットです。そこでネットワーク層プロトコルとトランスポート層プロトコルを学ぶ前にイーサネットフレームの構造とデータリンク層のアドレスについて押さえておきましょう。
レイヤ3 ネットワーク層の論理アドレスに対応するレイヤ2 データリンク層の物理アドレスの対応を解決するARP Address Resolution Protocolはネットワーク層のプロトコルですが、ARPによって行われるアドレス解決のプロセスにもここで触れておきましょう。
標準的なイーサネットフレームの構造を確認しておきましょう。
イーサネットネットワーク上のデータはフレームと呼びます。イーサネットフレームは、イーサネットヘッダとL2データ・FCS フレームチェックシーケンスから構成されます。
L2データは、より上位層の内容を格納しています。しかし、レイヤ2の存在であるイーサネットヘッダはL2データの内容がより上位層のものであるかどうかを意識しません。ただのデータとして扱います。
一般的にL2データの内容はL3ヘッダとL3データです。TCP/IPではIPヘッダとL3データになります。また、L3データの内容は、より上位層のヘッダとデータになります。
イーサネットヘッダは14バイト、FCSは4バイトです。IPヘッダはv4で20バイト・v6で40バイトです。イーサネットフレームサイズが同じならば、IPv6パケットの方が1個のIPパケットで送れるL3データのサイズが小さいということになります。
インターネットワーキング上で、IPパケットを分割せずに転送可能なパケットサイズをMTU Max Transfer Unitといいます。
イーサネットデータの最大サイズは1500バイトです。となるとMTUの上限も1500バイトということになります。
送信データが相手先に届くまで様々なネットワークを経由するインターネットワーキングでは、IPパケットをカプセル化している部分もあります。IPパケットの分割ができない場合にそのようなIPパケットをカプセル化しているネットワークを経由するトラフィックは、カプセル化されたIPパケットのサイズ カプセル内のMTU値 を1500バイトより小さい値にするなど、そのネットワーク内でのイーサネットデータサイズが1500バイトになる様に送信元で考慮する必要があります。
それではここで、MTU値に上限値を指定してpingコマンドを実行してみましょう。
プロトコルアナライザでパケットをキャプチャして見ました。
キャプチャしたフレームサイズが1514バイト
イーサネットヘッダが14バイト
IPヘッダが20バイト
ICMPヘッダが8バイト
ICMPデータが1472バイト
と表示してあります。各ヘッダとデータサイズを足してみると
14 ＋ 20 ＋ 8 ＋1472 ＝ 1514
となります。
今回キャプチャに利用したプロトコルアナライザはEthereal（イーサリアル）です。EtherealはFCSを表示しない仕様になっています。注意しましょう。
イーサネットフレーム最大サイズは、
イーサネットデータ最大サイズ 1500バイトに
イーサネットヘッダ 14バイトと
FCS 4バイト
を加えたサイズですから、1518バイトになります。
802.1QというVLANの標準規格があります。802.1Qではイーサネットヘッダ内に4バイトのVLANタグを挿入します。フレームサイズが変わるのでFCSを再計算します。FCSのサイズは変わりません。
802.1QのVLANタグが付いたイーサネットフレームの最大サイズは1522バイトになります。
IPv6を有効にしたWindows Server 2003とWindows XPでは、netshコマンドでMTUを確認できます。
UNIX互換OSではifconfigコマンドで確認できます
送信データが相手先に届くまでに経由する様々なネットワークの中に、IPパケットをカプセル化しているネットワークが存在する場合、IPv4ネットワークでは、インターネットワーク内のルータが通過可能なMTU値を検知し、必要に応じてパケット分割をする事が多いでしょう。この場合、送信元ホストは送信可能MTU値を調整しません。
IPv6の場合、送信元ホストに通過可能なMTU値が通知され、送信元ホストがエンド・ツー・エンドで到達可能なMTU値に調整してIPパケットを送信します。
標準的なイーサネットフレームを並べてみました。TCPとUDPはトランスポート層 レイヤ4のプロトコルです。そこでここではTCPやUDPのデータをL4データと呼びましょう。
一般的なTCPもしくはUDPのIPパケットは、
・TCPもしくはUDPヘッダとそのデータで構成され、
・1段下位のネットワーク層のプロトコルであるIPでカプセル化されます。IPヘッダからは、TCPヘッダとL4データがひとつのL3データとして見えます。
・IPヘッダとL3データは更に一段下位のデータリンク層のプロトコルでカプセル化されます。イーサネットを使用している場合、イーサネットヘッダとFCSがつきます。イーサネットヘッダからは、IPヘッダとL3データがひとつのL2データとして見えます
ICMPはL3のプロトコルです。ICMPデータにはトランスポート層などの、より上位層の内容が格納してある事もあります。ICMPを利用したアプリケーションのひとつpingではICMPデータはただのバイト列です。
つぎは標準的なIPパケットをカプセル化してIPパケットを構成している例です。トンネリング技術を利用しているネットワークでは、このような構造のパケットになります。
IPsecとPPTPはVPNで利用するプロトコルです。トンネルの始点で標準的なIPパケットをVPN用のプロトコルでカプセル化します。
IPsecはESPヘッダと認証データ
PPTPはGREヘッダとPPPヘッダ
でカプセル化します。トンネルの終点でこれらVPN用のプロトコルヘッダをはずします。トンネルの始点以前と終点移行のホストもしくはネットワークは、VPN用プロトコルでのカプセル化を意識しません。
802.1QのVLANを利用していない時のイーサネットでは、VPN用のプロトコルでカプセル化してあるトラフィックも最大フレームサイズは1518バイトです。カプセル化していないIPパケットよりもカプセル化されたIPパケットの方のサイズが小さいので、標準的な非VPNトラフィックと比較して1個のイーサネットフレームで送信するデータ量はVPNトラフィックの方が少ない、といえます。
同様にPPPoEもPPPoEヘッダとpppヘッダでカプセル化しているので、標準的な非PPPoEトラフィックと比較して1個のイーサネットフレームで送信するデータ量はPPPoEトラフィックの方が少ない、といえます。
データリンク層のアドレスであるMACアドレスと、ネットワーク層のアドレスであるIPアドレスについて述べます。
イーサネットフレームのイーサネットヘッダには送信元と宛先のMACアドレスが格納されています。MACアドレスとはネットワークインターフェースカード固有のアドレスです。イーサネットというプロトコルが物理層とデータリンク層のプロトコルなので物理アドレスとも呼ばれます。データリンク層内のMAC層で管理している値でもあります。
ルータを超えない・スイッチで届く、L2ブロードキャストのネットワークでは通信相手をMACアドレスで識別します。一般的にMACアドレスは工場出荷以前にハードウェアメーカの国別コード・メーカー別コードと製品固有の値から構成しますので、例え同一メーカの同一型番のネットワークカードでもMACアドレスが重複することはありません｡利用者が変更できない値です。
しかし、複数ネットワークカードを論理的にひとつのカードとして構成するチーミングや、複数のサーバを論理的にひとつのサーバに見せるクラスタなどの技術を利用している場合に、ネットワーク管理者がMACアドレスを手動設定することもあるでしょう。この時にMACアドレスの重複が起こる可能性がないとはいえません。
MACアドレスはルータを超えないネットワークで使用します。ルータを超える通信ではイーサネットヘッダが付け替わるので、格納しているMACアドレスの値も変わります。
イーサネットヘッダには、「データとして何をカプセル化して格納しているのか」を示すEtherType（イースタイプ）というエリアがあります。IPパケットをカプセル化している場合には、EtherTypeにはIPと記述されます。
同様に、IPヘッダにも、「データとして何をカプセル化して格納しているのか」を示すエリアがあります。TCPセグメントをカプセル化している場合には、TCPと記述されます。
IPヘッダには、送信元IPアドレスと宛先IPアドレスが格納してあります。IPネットワークではIPアドレスで通信相手を識別します。一般的なエンド・ツー・エンドの通信ではIPヘッダ内の送信元IPアドレスと宛先IPアドレスは変わらずに宛先に届きます。ただし、NAT（ナット）やNAPT（ナプト）を利用している場合はIPヘッダが付け替わりますので、格納してあるIPアドレスも変わります。
IPアドレス等ネットワーク層のアドレスは、ネットワークインターフェースカードのハードメーカの工場出荷以前に決まるということが無く、ネットワーク設計者や管理者が設定します。論理アドレスとも呼ばれます。
MACアドレスを確認してみましょう。
Microsoft OSではroute printやnetstat –rnでルーティングテーブルの表示と共にMACアドレスを確認可能です。Ipconfig /allでも物理アドレスとして表示されます。
UNIX互換OSではifconfigコマンドで確認できます。
Ciscoルータではshow interfaceコマンドで表示できます。
コンピュータ同士の通信では、ネットワークモデルの各層は、お互い同じレベルの層同士で直接通信しているような振舞いをしています。
レイヤ3 ネットワーク層同士ではIPアドレスで通信相手を認識し、
レイヤ2 データリンク層ではMACアドレスで通信相手を認識します。しかし、実際のデータの流れは送信側コンピュータ内で上位層から下位層へデータは渡され、物理層レベルで通信相手に伝わります。受信側のコンピュータは受け取ったデータを下位層からより上位層へ渡します。コンピュータの中でネットワーク層のアドレスとデータリンク層のアドレスを対応付けています。
ネットワーク層のプロトコルであるARPは、レイヤ3 ネットワーク層の論理アドレスに対応するレイヤ2 データリンク層の物理アドレスの対応を解決します。またこの解決のプロセスをアドレス解決と呼びます。この機能はTCP/IPで必須です。
L2アドレスに対応するL3アドレスを解決するプロトコルにRARPがあります。この機能はオプションです。
アドレス解決の様子を実際に見てみましょう。プロトコルアナライザでネットワーク上のトラフィックをキャプチャしました。
最初に、Windows PCでarp –dコマンドを複数回実行し、既に持っているARPキャッシュを消去します。
arp –aコマンドでARPキャッシュの消去を確認します。
任意のIPホストに対してpingを実行します。ここでARPリクエスト が実行されます。
宛先が同一ネットワークならばそのIPアドレスに対して、別ネットワークならばローカルネットワークからの出口であるルータのIPアドレスに対して、「このIPアドレスはどなたが持っていますか？」というリクエストが、ローカルネットワーク内にブロードキャストされます。6バイト全てにビットが立っているMACアドレスFF：FF：FF：FF：FF：FFはMACアドレスのブロードキャストアドレスです。
問い合わせに対して、「そのIPアドレスはこのMACアドレスが持っています。」というリプライがあります。
これで、pingの宛先IPアドレスとMACアドレスの対応が解決できました。ICMP ECHO RequestはこのMACアドレスを宛先に送信されます。
アドレス解決のおさらいです。
要求元は通信相手の IPアドレスを含むARP 要求パケットをローカルネットワーク上にブロードキャストします。
ローカル IP ネットワーク上のすべてのシステムが、このブロードキャスト メッセージを検出します。
該当する IP アドレスを持つシステムが、ARP 応答パケットで 自分のMACアドレスを要求元に送信して応答します。
アドレス解決は毎回行われるとは限りません。ブロードキャストはローカルネットワーク上全てに届く通信です。トラフィックの混雑・ネットワーク帯域の圧迫を生みます。そこで、この問題を回避するためにアドレス解決の結果を一時的に記憶し再利用します。
画面例では、arp –dコマンドを複数回実行し、既に持っているARPキャッシュを強制消去し、arp –aコマンドでARPキャッシュの消去を確認しています。これでping実行以前のARPキャッシュエントリは空である事が判ります。
ping実行以後はARPキャッシュにエントリが存在するのがわかります。
ARPキャッシュにエントリが保持してある間に、宛先IPホストのIPアドレス変更やネットワークカード交換があると、キャッシュ上のIPアドレスとMACアドレスの対応が実際と異なるため、通信に失敗します。
このようなときにはARPキャッシュを強制消去して新たにアドレス解決しましょう。
送信元ホストと宛先ホストがルータで隔てられた別のセグメントにある場合、ルータは宛先ホストの代理としてルータ自身のMACアドレスを含んだARP応答を送信元ホストに返します。送信元ホストは宛先ホストのエントリにルータのMACアドレスをマッピングしたARPキャッシュテーブルを作成します。
本講義は以上です。
次回は「ネットワーク層」を受講する事をお勧めします｡
またお会いしましょう。それでは！