現在インターネットではIP（プロトコル）として IPv4 とIPv6 が使われている． IPv4が広く普及したが，インターネットの利用者が増え，無人の機械まで インターネットに接続されるようになってきたために， IPv4 で利用できるIPアドレスの上限では全く足りないという状況になった． IPアドレスの不足を根本的に解決することを主な目的としてIPv6が作られ， 使われるようになってきた．
IPv6だけでネットワークを構築するために， あるときに一斉に世界中のホストがIPv6を使うようにするというのは 非現実的である．古い機器でIPv4にしか対応しないホストもあるかもしれない．
ネットワークをIPv4,IPv6両方に対応したネットワークを構築するには 大きな手間がかかるのでどうしてもIPv4しか使えないネットワーク， IPv6しか使えないネットワークが存在する状況は避けられない． IPv6を現実的に普及させるステップとしてIPv4のネットワークと IPv6のネットワークを相互通行できるような仕組みが必要となる． IPトンネリングはそのための技術である．
送信元と宛先がIPv4で通信するとき，送信元と宛先が同じ IPv4ネットワークに接続されていればそのままIPv4で通信できる． 問題はネットワークが教科書p.215図5.22のように 2つのIPv4ネットワークがIPv6ネットワークを介して 接続されていて，発信元と宛先が左右の別のネットワークに 接続されている場合である （逆にIPv6のネットワークをIPv4のネットワークで中継している 場合も同じ問題が起こる）．
教科書図5.22の場合，IPv4ネットワークとIPv6ネットワークの接点になる 左右の2箇所に相互接続のための変換作業を行うルーターを設置する． 左側のIPv6ネットワークに送信元ホストがあり，右側のIPv6ネットワーク に宛先ホストがあるとする．左のネットワークの送信元から出たIPv4のパケット （IPv4ヘッダ+データ）が左側の接点にある IPv4v6変換ルーターに到達したとき，ルーターは IPv4のパケットをヘッダごと一つのデータとみて「包んで」 IPv6のデータとして扱う．つまりIPv4のヘッダ+データに IPv6のヘッダをつけ（教科書p.215図23），IPv6のパケットとして 中央のIPv6のネットワークに流す．
このパケットはIPv6で処理できるので右側の接点にある IPv4v6変換ルーターに到達する．このルーターは 逆にIPv6のヘッダを取り去って「包まれていた」内容， つまりIPv4のヘッダ+データに戻して右側のIPv4ネットワークに 流す．右側のネットワークはIPv4ネットワークなのでこの パケットを正しく処理し，目的ホストに到達させることができる．
このように本来宛先に到達しないプロトコルのヘッダ+データを まとめてデータとして他のプロトコルで包んで中継することを 一般的にトンネリングとよぶ．
IP（OSI参照モデル第3層）では経路制御の機能を使って 複数のルーターを使った複雑な中継を行って 別のネットワークへ到達できるように設定することができる． しかし，一般家庭や大学の研究室レベルのネットワークを 構築する場合，複雑な設定はせず，家庭内は単一のネットワークとして 全てのホストのデフォルトルーターに一台の出口ルーター を設定することが一般的である．デフォルトルーターの 外側への設定が正しく行われていれば， こうすることで全てのホストの通信は出口ルーターを 経由して正しく行われる．DHCPを使えばデフォルトルーターの 設定も自動で行える．
この方法は設定が簡単なのでよく利用されるが デフォルトルーターが故障すると全てのホストで通信ができなくなる． そこでルーターを2重化する手法であるVRRPが作られた．
VRRPの目的は教科書p.217図5.25のようにマスタールーターが故障したときに バックアップルーターが代わりにルーターの機能を果たすようにすることであるが， 内部ネットワークのホスト側に複雑な設定をさせたくないという目的もある． 内部ネットワークのホストの設定はVRRPが無いときと同じ設定で動作が できるように設計されている．
VRRPにはルーターに仮想的な（変更できる）IPアドレスと MACアドレスを設定する機能があり， 普段は左側のマスタールーターにユーザーがデフォルトルーターに 指定するIPアドレスが割り与えられている．
バックアップルーターがマスタールーターが故障したことを検知すると マスタールーターに割り当てられていたIPアドレスとMACアドレスを 自分の仮想的なIPアドレスとMACアドレスに割り当て， 他のホストが送ったマスタールーターのIPアドレスまたはMACアドレス宛 のデータがバックアップルーターに届くようにする．
MACアドレスもコピーするのは，ルーターと同じネットワークにある ホストはARPのキャッシュなどでMACアドレスを使って第2層の 通信を行うからである．
ただし，教科書図5.25のスイッチはどのMACアドレスが何番の ポートに接続されているかを記録して，そのポートにしか 送らない機能をもつため，VRRPはスイッチにルーターの MACアドレスの接続ポートが変わったことを伝える．
この節の説明を読むときはルーターは第3層の機器，スイッチは 第2層の機器であることを意識すると良い．またマルチキャストを 実現するプロトコルのIGMP（IPv4），MLD（IPv6）はどちらも 第3層のプロトコルであることも重要である．
マルチキャストは
という2つのフェーズで行われる． 教科書p.219図5.26の上がマルチキャスト受信の準備のフェーズで 下が実際にマルチキャストが行われるフェーズである．
マルチキャストの準備のフェーズで注意が必要なのは， 教科書図5.26上の2番の「IGMP/MLDスヌーピングでマルチキャスト受信を知る」 という処理は1番の「IGMP/MLDでマルチキャスト受信を通知」 の途中でルーターが知ることなしに中継点のスイッチが 勝手に行うというところである．
また，スイッチは第2層の機器なので本来は第3層のプロトコルである IGMP/MLDパケットの内容は理解せずにただのデータとして 第2層のプロトコルで転送するはずであるが，このマルチキャスト プロトコルではスイッチはマルチキャスト受信を要求しているホストが スイッチのどのポートに接続されているかを知る必要がある （後でマルチキャスト通信が来たときにそのポートだけにデータ を送信するため）．そこでスイッチは本来解釈しないはずの自分より 高階層の第3層のIGMP/MLDパケットの内容を理解して どのホストがマルチキャスト受信を要求しているかを知る． 本来読んでそれに依存して動作を変えてはいけない高階層の情報をみて 処理を行うのでIPスヌーピングとよばれる．
IPエニーキャストは負荷分散を目的としている．多くの処理依頼が 予想される一つのIPアドレスに複数のホストを割り当てる． ユーザーはそのIPアドレス宛にパケットを送るとどれか1台のホスト が応答する．
コネクションレスのUDPで1往復の通信であれば問題なく処理できる． DNSのルートサーバーで使われているのが代表的な使用例である．
複数回アクセスした場合，前回と同じホストが応答する保証が無いため， UDPでも複数のパケットを同じ相手と通信したい場合やTCPを使いたい場合は 工夫が必要になる．
通信品質とは，1秒あたり何Gバイトのデータ伝送を保証できるか， という意味である．インターネットはもともと通信品質を保証する ようには設計されていない．
インターネットでの通信はいろいろなネットワークを経由して 行われるが，それぞれのネットワークで一度に伝送できる データ量に上限がある．パケットがネットワークを流れているあいだに 経由地のどこかで通信量が上限に達している（輻輳している）ネットワークが あった場合， パケットはその手前のルーターで一時保管されて ネットワークの混雑がなくなるまで待って転送する，あるいは保管できる 量から溢れて消失してしまうということが起こる．この場合 パケットの再送信が行われるなどして極端な遅延が起こる．
通信品質の制御は基本的にはパケットに優先順位をつけて混雑時には 優先順位の高いパケットだけを送信する，というアイデアで 構成されている．
具体的な通信品質の制御を行うプロトコルとして IntServ と
DiffServ が挙げられている．細かい説明は教科書を読んでほしいが，
大雑把に以下の立ち位置をおさえておけば良い．
IntServ：高機能だが複雑
DiffServ：低機能だが簡単
輻輳通知の目的はホストAからホストBにパケットを送ったとき， 途中で輻輳が発生しているネットワークを経由した場合に ホストAにそのことを通知することである．
しかし通知のために新たなパケットを発生することはより事態を 悪化させるので避けたい．そのため，輻輳の発見は行きのパケット に便乗することで行い，通知は帰りのパケットに便乗して行うように なっている．
教科書に「何ヘッダの何フィールド」という記述が多い．具体的な
ヘッダの構造が書いてあるページを下にまとめた．
IPヘッダのECNフィールド：p.176図4.31（昔は8から15ビットをToS: Type of Serviceフィールドとしていたのを定義し直した）
TCPヘッダのControl Frag（ここにCWR,ECEフラグが格納される）：p.264図6.25
往路で輻輳を発見して宛先ホストに伝えることは第3層のIPパケットの ヘッダに便乗して，復路で輻輳があったことを伝えるのは第4層の TCPパケットに便乗して行われる．往路と復路で利用する階層が異なることに 注意する．
スマートフォンのように移動するホストがインターネットを利用するときに IPアドレスを頻繁に変更しなければいけないという問題がある．
ネットワークは無線通信であってもそれぞれの場所に固定されているので ホストが移動すると移動した先のネットワークに接続しなければならない． 移動前のネットワークと異なるネットワークに接続すると，IPアドレスの 唯一性から異なるIPアドレスを使用することになる．
Mobile IP は移動するホスト（移動ホスト） のIPアドレスを見かけ上固定する仕組みである． 固定のIPアドレスをもつホームエージェントが一つ， 外部エージェントが移動ホストが移動する可能性のある ネットワーク全てに設置されている．
移動ホストはネットワークを移動すると，そのネットワークの 外部エージェントにホームエージェントへ移動した後のIPアドレスを 伝えるように依頼する．そうすることでホームエージェントは 常に移動ホストがどのネットワークの何というIPアドレスを 使用しているか把握できる．
移動ホストと通信したいホストは 仮想的な固定のIPアドレス宛にパケットをを送る．これはホームエージェントに 届くようになっており，ホームエージェントはどのネットワークのどの IPアドレスを移動エージェントが使用しているか知っているので適切に 通信を肩代わりすることができる．こうして移動ホストがどこにいても 通信ができる仕組みである．
6,7章はこの授業では扱わない．通信ネットワーク実習3,4 は OSI参照モデルの高階層を対象とした授業だからである． 6,7章は通信ネットワーク実習1,2に対応する第4層，第3層の 重要な説明が書かれているので，この授業に関係なく読むことを勧める．
コンピュータの構成としてアプリケーションソフトウェアと オペレーティングシステムの境は重要である．アプリケーションソフトウェアは 用途に応じて別のものを作成する必要があるが，オペレーティングシステム 以下の階層は，ハードウェアも含めてどんな用途でも使用しそうな汎用の 機能を提供する．そのためオペレーティングシステムはコンピュータを 使用している間は常に動作していて，アプリケーションソフトウェアからの 仕事依頼を待っている．
プロトコルの階層でも同じで，OSが担当するOSI参照モデルの第4層 以下の層とアプリケーションソフトウェアが担当する第5層以上 に大きな区別がある．TCP/IPの階層構造では第5層以上は一つの 「アプリケーション層」として設計されている．それだけこの間の 区別が重要だということである．
TCP/IPの階層構造でのアプリケーション層のプロトコルは 個々のアプリケーションの必要に応じて決められる．
アプリケーション層のプロトコルはそれ以下の階層の機能を 抽象的にOSの機能として使えるので通信が確立できているという前提で 設計できる．どんなネットワークの形状なのか， 通信媒体は有線なのか無線なのか，といった下位層の実装を 気にすることなくアプリケーションを作成できる．これが プロトコルの階層化の利点である．
遠隔ログインはユーザーがログインしているホストとは別の， ネットワークで繋がっているホストへログインするアプリケーションで， サーバーとは別の端末からサーバーにログインしてサーバーの メンテナンスを行うときなどに必須のアプリケーションである．
TELNET は遠隔ログインプロトコルのうち古くから利用されているものである． TELNET に限らずほとんどのプロトコルはASCII（半角英数字）の文字列をやり取り することで行われる．TELNET の（悪い）特徴は，通信が暗号化されないことで， パケットが流れるネットワーク上のホストは通信の内容傍受することができる． ログインのためにパスワードを入力するとそれも傍受される．このため， TELNET はファイヤウォール内で同じネットワークにある ホスト間で利用するのが普通である．
教科書p.299の囲み記事のようにポート番号を指定することで いろいろなアプリケーションソフトウェアのクライアントとして 動作させることができる．設定の確認やサーバーの動作の確認などに 使われる．
SSHの大きな特徴は通信内容が暗号化されることである． 送信元と宛先のホスト以外の中間のホストは通信内容を暗号化された データを転送することになり，十分な強度の暗号化を用いると解読することは 実質的に不可能である．遠隔地から必ずしも信頼できないネットワークを 経由してサーバーに接続するときに使われる．
ポートフォワーディングを説明しているのが教科書p.300図8.5である． 前提として右側のSSHサーバーとPOPサーバーは同じネットワークにあり， 左のクライアントとの間にはファイアウォールがあること， クライアントは SSH サーバーには接続できるがファイアウォール内の POP3サーバーには直接接続できないことをと仮定している．
教科書図8.5ではあらかじめクライアント上で
という設定をsshコマンドを使って行っておく． 実際に利用するときには，クライアントが自分の10000版ポートにアクセスすると パケットはまず経由地であるSSHサーバーへSSH通信で（暗号化されて）送られる． SSHサーバはファイヤウォール内のネットワークで暗号化されていない 通信でPOP3サーバーの110番ポートに送られる．
こうすることでクライアントから，ファイヤウォール外の安全でない ネットワーク上は暗号化されたデータだけが流れる状況で ファイヤウォール外から直接アクセスできないPOPサーバーへの通信を 安全に行うことができる．
FTP はファイル転送に使われるプロトコルで， ポート番号20番（変えることもできる）の データ転送用のTCPコネクションとポート番号21番の制御用コネクションを張る．
FTPクライアントアプリケーションに 教科書p.303表8.1のASCII（半角英数字）文字列のコマンドを入力すると 制御用コネクションでサーバーに指示が送られる． 制御用コネクションは指示や応答のやり取りに使われる．
実際にデータを転送するのは別のデータ転送用のコネクションで行う． 通常は制御用コネクションはクライアントからサーバーへ張り， データ転送用コネクションはサーバーからクライアント側へ張る． しかしクライアントがNATの内側にあるとNAT外部からはNAT内部の ホストが見えないという特性からデータ転送用のコネクションを張ることが できない．
クライアントがNAT内のホストである場合は 教科書表8.1にあるPASVコマンドを制御用コネクションで送ることで 転送用コネクションもクライアントからサーバーへ張るように FTPアプリケーションソフトウェアに工夫がされている． コネクションは最初に貼った向きがどちら向きでも双方向に 通信できることを利用している．
FTPにアクティブモードとパッシブモードがあること， 制御用コネクションとデータ転送用コネクションが別にあることの 理由はFTPがもともと以下のような利用を想定していたからである （参照:RFC959）．
上の場合，クライアント-サーバーA間とクライアント-サーバーB 間に制御用コネクションを張る．クライアントは サーバーAかBのどちらかにパッシブモードになるように指示し， 他方のサーバーへ相手サーバーへのデータ転送用コネクションを 張るように指示してデータ転送を行う．
ただし，現在はセキュリティの問題でこのような使用はされていない．
現在のFTPの利用法は上記のサーバーAかBのどちらかが クライアントと同じホストになった使い方である．クライアント から相手サーバーへPASVコマンドを出すことで 相手側のサーバーにコネクションを受ける側として準備させて 自分側（のサーバー）からデータ転送用コネクションを張ることができる． これをNAT超えに利用している．