[ IP Network Skill - No. 0133 - ]
発行日： 2003/11/7
‥‥……━━━━━━ IP Network Skill No. 00000133 ━━━━━━……‥‥
┏━┓
┃目┣━┓ 《IP Network Skill No.133 -CONTENTS-》
╋━┗━┫次┣━━━━━━━━━━━━━━━━━━━━━━━━……‥‥
┃ ┗━┛
┃【０】【まえがき】：著書プレゼント企画の結果
┃【１】【学習のてびき】：ネットワークがつながらないとき
┃【２】【コラム】：RFC review RFC3520からRFC3529
┃【３】【オススメの本】：500の技
┃【４】【本日の試験対策問題】：IPヘッダの問題
┃【５】【問題の解答】
╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━……‥‥
【まえがき】
プレゼント企画への多数のご応募、ありがとうございました。
また前と同じ失敗をしてしまいました！締切日を書くのをわすれて
ました。。。すみません。メルマガは金曜に出しているので、翌週
の水曜くらいまで受け付けてます。
既に当選者の方にはメールさせていただきました。メールアドレス
のユーザIDが以下の方です。
nagashimak
sugawarar
tomoe
taro
toyop95
当選された方、おめでとうございます。
当選されなかった方も、貴重なご意見をありがとうございました。
今後も著書プレゼント企画はあると思いますので、是非次回も応募
ください。
メルマガの感想をいただいておりますので、ここでご紹介＆レスを
載せます。事後承諾で済みませんが、載った方、ご了承くださいね。
--------------------------------------------------------------------
ネットワーク設計業務に従事しながらCCNP取得に向けて勉強してますが、
メルマガにより知識強化してます。
感想としては、比較的細かいレベルまで記載がある場合と概略で終わってしまう
場合と様々かなと感じます。
多少長くなるかと思いますが、常に詳細レベルにまでブレークダウンして頂ける
とよいのですが、、大変ですね。
--------------------------------------------------------------------
ありがとうございます。概略で終わってしまうのは、著者があまり
詳しくないところか、詳細を書くとメルマガ30回分くらいになって
しまうかいずれかです。。詳しくないところも調べたりしてますが
やはり時間が足りないので、今後のネタにしてます。
（あとがきに続く）
◎￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣◎
｜ 新規購読・購読解除・バックナンバー ⇒ http://www.xai.nu/ipnet
｜ IP Network Skill 掲示板
｜ ⇒ http://www.xai.nu/cgibin/ipnet/bbs.cgi
｜ バックナンバー一覧
｜ ⇒ http://xai.nu/ipnet/stack/index.html
｜ 間違いご指摘
｜ ⇒ ipnet3@xai.nu
◎＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿◎
┳┯┯┯┯┯━━━━━━━━━━━━━━━━━━━━━━━━━━┯┯┳
┠┼┼┼┴ 学習のてびき： ネットワークがつながらないとき ┬┼┼┼┨
┻┷┷━━━━━━━━━━━━━━━━━━━━━━━━━━┷┷┷┷┷┻
トラブルシュート系を充実させて欲しい、というリクエストもあるのです
が、ネットワークがつながらないという事象は多々あることで、さらに
いろんな要素が絡まっているため、それだけで本が何冊も書けてしまう
と思います。通信機器のバグや仕様の読み間違いというトラブルもありま
すが。
まずはパソコンからインターネット上のWebサーバにアクセスしようと
思ったんだけど画面が表示されない、というパターンを見てみましょう。
会社や学校のLANの場合、まずは近くの人にネットワークが使えるか聞いて
みましょう。他の人が使えていれば、LAN設備の問題ではないことが判明し
ます。他の人も同じ事象が出ていれば、自分のパソコンの設定が悪いわけ
ではないことがわかります。
自宅の場合や、LANで他の人はネットワークが使える場合を考えましょう。
パソコンの設定や振る舞いがおかしいか、ケーブルの問題、直接繋がって
いるLANポートの問題が考えられます。
ケーブルというのは確率が低いのですが、別のケーブルに変えてみたり、
ストレート／クロスの違いを確認したりして一応検査します。
LANポートはパソコンのネットワークの設定を見て、インタフェースが
上がっているかどうか確認してください。インタフェースがあがっている
かよくわからない場合は、コマンドプロンプトから"ip config"と打って
みて(windows系)アドレスが取得されているか見てみてください。
たいていDHCP環境なので、アドレスが取得されていないということは
リンクが上がっていないと考えられます。
リンクが上がっていてアドレスももらっているのに通信できない場合は
相手のサーバが落ちているか、DNSサーバが落ちている可能性があります。
DNSサーバまで疎通性があるか調べるのに"nslookup"というコマンドを
コマンドプロンプトから打ってみます。DNSサーバが落ちているとこの
返信がNGです。この返信が来たら、">"というプロンプトが出るので、
そこで適当なホスト名を入れてみます。(">xai.nu"のように)
ここで返信が来たら、タイミング的な問題なのでWebブラウザを閉じて
もう一度開くと表示されます。これでも表示されないとブラウザの設定
か相手サーバのファイルがおかしくなったと考えられます。
"nslookup"でDNSの返信が来ない場合は相手サーバが落ちている可能性
があります。
"ping xai.nu"のようにPINGを行うと疎通性を調べることが出来ますが、
失敗したときに原因が分かりにくいのでnslookupで調べてみたほうが
早いと思います。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
コ┃ラ┃ム┃【RFC review RFC3520からRFC3529】
━┛━┛━┛
このコラムの注意ですが、嘘が書いてあるかもしれないので、心配な方は
原文をじっくり読まれることをオススメします。説明文中の間違いに対し
て発行人は責任を持ちませんので、ご了承ください。。。
--------------------------------------------------------------------------
3520 Session Authorization Policy Element. L-N. Hamer, B. Gage, B.
Kosinski, H. Shieh. April 2003. (Format: TXT=63445 bytes) (Status:
PROPOSED STANDARD)
--------------------------------------------------------------------------
音声などリアルタイム通信を行う上で、パス間の帯域を明示的に予約して
利用する方法があります。例えばRSVP (Resource ReSerVation Protocol)
がその一例です。コネクション上を流れる１つのまとまった通信データを
セッションと言いますが（例えばFTPコネクション上でやりとりされる
ファイルのデータ）、セッションごとに流入制限を行わせるためのポリシー
エレメント（制御情報要素）を定義しています。SIPに絡んでくるRFCです。
--------------------------------------------------------------------------
3521 Framework for Session Set-up with Media Authorization. L-N.
Hamer, B. Gage, H. Shieh. April 2003. (Format: TXT=59548 bytes)
(Status: INFORMATIONAL)
--------------------------------------------------------------------------
RFC3520と同系統で、メディア承認を用いたセッションの確立処理を定義
しています。シグナリングプロトコルとしてSIPを、帯域予約としてRSVP
を、ポリシーサーバーとの連携にCOPSを用いてホスト、ルータ、サーバ
間の承認処理を提示しています。承認(Authorization)とは認証処理の一種
ですが、認証がユーザアクセスそのものを許可するか否かに対し、承認は
ユーザがネットワーク内で特定の機器にアクセスするなど権限を決めて
あげる処理を指します。
--------------------------------------------------------------------------
3522 The Eifel Detection Algorithm for TCP. R. Ludwig, M. Meyer. April
2003. (Format: TXT=33731 bytes) (Status: EXPERIMENTAL)
--------------------------------------------------------------------------
Experimental（実験）のRFCです。TCPの輻輳制御として、RFC1323のTCP
タイムスタンプオプションを使って再送制御を効率化させています。
タイムスタンプ（つまり送信時刻）を送信者が記憶しておき、再送パケット
にタイムスタンプを設定して再送処理を行います。それに対する返答（Ack）
が帰ってくれば次に再送する必要がなくなる、というアルゴリズムです。
--------------------------------------------------------------------------
3523 Internet Emergency Preparedness (IEPREP) Telephony Topology
Terminology. J. Polk. April 2003. (Format: TXT=10190 bytes) (Status:
INFORMATIONAL)
--------------------------------------------------------------------------
災害など緊急時のネットワーク通信を考えているIEPREPワークグループと
いう委員会がIETFにあります。インターネットを用いた緊急用電話網として
４つのプロトコルを定義しています。"IP Bridging"、"IP at the Start"、
"IP at the End"、"End-to-End IP"の４つ。
--------------------------------------------------------------------------
3524 Mapping of Media Streams to Resource Reservation Flows. G.
Camarillo, A. Monrad. April 2003. (Format: TXT=11249 bytes) (Status:
PROPOSED STANDARD)
--------------------------------------------------------------------------
またRSVP系です。特にRSVPとは言っていないのですが、帯域予約系のプロトコル
を使ってIPフローに対して帯域の確保を行う方法の追加です。同じ送信元アド
レス、送信元ポート番号、あて先アドレス、あて先ポートを使う一連のパケット
群をフローと表現します。このRFCではSIPを対象としていますが、音声など
リアルタイム通信をする上でフロー単位で帯域保証してあげる必要があります。
パケット単位だとポート番号を見ないので、同じアドレス宛てでも保証を必要
としないデータフローも混ざっているかもしれないので。このRFCではフロー
を複数まとめても帯域保障できるようなSingle Reservation Flow (SRF)という
方法を定義しています。
--------------------------------------------------------------------------
3525 Gateway Control Protocol Version 1. C. Groves, M. Pantaleo, T.
Anderson, T. Taylor, Eds.. June 2003. (Format: TXT=439674 bytes)
(Obsoletes RFC3015) (Status: PROPOSED STANDARD)
--------------------------------------------------------------------------
ITU-TのH.248 (Gateway Control Protocol Version 1) がRFC3015で規定され
て、2002年3月にその改訂版が出たため、このRFCをRFC3015の改訂版としたも
のです。H.248はVoIP系のプロトコルです。SIPが最近よく登場したり、その
前にはH.323やMGCPなどVoIP系の呼制御プロトコルを紹介しましたが、H.248
もその一種です。ここで言っているゲートウェイは、ルーティングのデフォル
トゲートウェイとは違って、通常の電話網(PSTN)とインターネット網(VoIP)
とを仲介するルータのことです。そのルータがどのように呼を制御するか、
ということを規定しています。
--------------------------------------------------------------------------
3526 More Modular Exponential (MODP) Diffie-Hellman groups for
Internet Key Exchange (IKE). T. Kivinen, M. Kojo. May 2003. (Format:
TXT=19166 bytes) (Status: PROPOSED STANDARD)
--------------------------------------------------------------------------
インターネット網内で暗号化通信を行うIPSecにおいて、どうやって暗号化
するか？という情報を機器同士でやりとりします。そのとき、暗号化に必要
な鍵のやりとりをするのがIKEです。IKEで鍵を渡し合う際、その鍵も他人に
バレないようにするため、Diffie-Hellman方式というやり方を使います。
詳しくはバックナンバーNo.28にあります。このときにバレないように難しい
値を使って難しい計算をするのですが、その難しい値を既存のもの意外に
さらに難しくしたものをこのRFCで追加しています。というのも、既存では
3DESと呼ばれる暗号化アルゴリズムを使っていたのですが、AESというさらに
強力な暗号化アルゴリズムが採用されてきたため、その対応が必要となり
追加にいたったわけです。
--------------------------------------------------------------------------
3527 Link Selection sub-option for the Relay Agent Information Option
for DHCPv4. K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy. April
2003. (Format: TXT=16831 bytes) (Status: PROPOSED STANDARD)
--------------------------------------------------------------------------
DHCP関連のRFCです。DHCPはユーザからリクエストを受けるとIPアドレスを
一定期間貸し出します。このとき、ユーザがDHCPサーバと別のサブネットに
いる場合、リレーエージェント(Relay Agent)という機器（通常ルータ）に
そのやりとりを中継してもらうことになります。既存のやり方ではリレー
エージェントを介したときでもファイアウォールを挟んでいたりポイント
ツーポイントのためにサブネット自体のアドレスが定義されていないため
どのアドレスをDHCPが割り当てたらよいか判断できませんでした。そこで
新しいオプションを作り、割り当てるべきサブネットアドレスをリクエスト
に含めるようにする方法を定義しています。
--------------------------------------------------------------------------
3528 Mesh-enhanced Service Location Protocol (mSLP). W. Zhao, H.
Schulzrinne, E. Guttman. April 2003. (Format: TXT=35208 bytes)
(Status: EXPERIMENTAL)
--------------------------------------------------------------------------
RFC2608で規定されているService Location Protocol (SLPv2)はサービス
を提供するネットワーク上の相手（サーバや電話相手など）を見つける
プロトコルで、１対１の場合だけ規定されていましたが、メッシュ環境で
どうかというのを書いています。
--------------------------------------------------------------------------
3529 Using Extensible Markup Language-Remote Procedure Calling
(XML-RPC) in Blocks Extensible Exchange Protocol (BEEP). W. Harold.
April 2003. (Format: TXT=23314 bytes) (Status: EXPERIMENTAL)
--------------------------------------------------------------------------
XML-RPCはHTTPを使ってクライアントとサーバ間でXMLメッセージのフォー
マットを定義したものです。BEEP (Blocks Extensible Exchange Protocol)
というアプリケーションプロトコルがRFC3080に規定されています。BEEP
にはTLSやsoapなどいくつか種類がありますが、このRFCでXMLを定義して
います。BEEPはHTTPのように、ユーザがサーバアプリケーションに接続する
ための方式です。EAPは認証フレームワークで、実際の認証方式にEAP-MD5や
EAP-PEAPといった認証プロトコルが使われるように、BEEPはフレームワーク
で実際にはXMLがやり取りされている、という感じです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━≪今週のオススメ本≫━━━━━━━━━━━━━━━━━━━━━━━
――――――――――――――
☆★☆ 500の技 ★☆★
――――――――――――――
プレゼント企画を行った書籍は下記Entry1です。書店で見かけたら中を
めくってみてください。
[Entry 1]【特選TCP/IP500の技】―――――――――――――――――――――
｜⇒ http://www.amazon.co.jp/exec/obidos/ASIN/4774118672/ipnetworkskil-22
└―・――――――――――――――――――――――――――――――――
[Entry 2]【TCP/IP500の技 オールラウンドプログラミング】――――――――
｜⇒ http://www.amazon.co.jp/exec/obidos/ASIN/4774113913/ipnetworkskil-22
└―・――――――――――――――――――――――――――――――――
[Entry 3]【インターネットセキュリティ500の技 オールラウンドプログラミング】―
｜⇒ http://www.amazon.co.jp/exec/obidos/ASIN/477411443X/ipnetworkskil-22
└―・――――――――――――――――――――――――――――――――
╋━━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━━━━━━━━━━……‥‥
┃本┃日┃の┃試┃験┃対┃策┃問┃題┃
╋━━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━━━━━━━━━━……‥‥
〔問題１〕IPヘッダの４ビット目から７ビット目まではヘッダ長です。これ
に関して正しいものは次のうちどれか。
１．IPヘッダとして15バイトまでしか表現できない
２．IPヘッダとして31バイトまでしか表現できない
３．IPヘッダとして60バイトまでしか表現できない
４．IPヘッダとして127ビットまでしか表現できない
〔問題２〕IPヘッダのチェックサムフィールドは16ビットです。これに関して
正しいものは次のうちどれか。
１．0x0000というチェックサムは存在し得ない
２．0xFFFFというチェックサムは存在し得ない
３．送信元で0x1234というチェックサムが受信先で0x1235になっていた
場合、IPパケット内のチェックサム以外のいずれか１つのビットが０
から１になってしまったと考えられる
４．送信元で0x1234というチェックサムが受信先で0x1235になっていた
場合、IPパケット内のチェックサム以外のいずれか１つのビットが１
から０になってしまったと考えられる
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
解┃答┃と┃解┃説┃
━┛━┛━┛━┛━┛
《本日の試験対策問題》
（解答１）３
（解説１）これが正解できたら素晴らしいです。IPヘッダのフィールド
としてIPヘッダ長が４ビット分あります。４ビット分ということは、
0000から1111（２進数）までの16通りの数しか表現できず、表現できる
最大の値は"15"です。なので１を選んでしまった方も多いかもしれませ
ん。しかし、IPヘッダ長の単位はバイトではなく“ワード”です。
１ワードは32ビット、つまり４バイトです。したがって表現できる最大
の値は15×4=60バイトとなります。ちなみに同じIPヘッダ内のトータル
長フィールドは単位がバイトなので気をつけてください。
（解答２）２
（解説２）かなり難しい問題ですね。まず３と４ですが、チェックサムが
１ビット変化したとしても、それはIPパケット内の１ビットが変化した
ことにはなりません。単にチェックサムのビットがノイズの影響などで
通信過程で0100から0101に誤認識されただけです。受信側ではチェック
サムも含めてビット演算をして、その結果がFFFFになっていればOKです。
チェックサム以外のどこかのビットの値が変わっているとFFFF以外の値
が計算結果で出ます。このとき、そのパケットは破棄されます。
１と２を見てみましょう。チェックサムが0000ということは、IPパケッ
トのチェックサム演算で１の補数和を計算した結果が0xFFFFになったと
いうことです。これを反転した0x0000がチェックサム。補数和が0xFFFF
というのはパケット内のビットを足し算していったらたまたまFFFFに
なった、ということでこれはあり得ます。
しかし0xFFFFというチェックサム、つまり補数和が0x0000というのはあ
り得ません。ヘッダ中に必ずバージョンとかヘッダ長とか、０以外の情
報があるためです。たとえばバージョンは４なので0x0100という１を含
む情報があります。そのため、補数和が０ということはあり得ません。
つまり、チェックサムがFFFFということもあり得ない訳です。
チェックサムの計算方法はバックナンバーNo.12を参照してください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆◆◆◆◆◆ ┃ あとがき ┃ ◆◆◆◆◆◆
（まえがきから続く）
--------------------------------------------------------------------
今年CCNA・CCNPを取得し何とかやっていけるようになったかなと思いま
す。次はCCDAを目指しています。
このメルマガは基礎固めに最適だなと思います。特に試験対策問題。
はっきりいって難しいです（TT）
今やっている特集（RFC）はいいですね！中身までは知らなかったので
新たな発見がたくさんあります。
--------------------------------------------------------------------
ありがとうございます。CCDAは国語の試験のようなので読解力を
養ってください。。。RFCは私も調べてみていろいろあるなぁ、と
改めて思いました。
--------------------------------------------------------------------
購読暦約６ヶ月です。
毎週の購読と共に、１号目から少しずつ読み進んでいます。
早朝30分と昼休みが勉強時間です。
とてもためになるのはもちろんですが、世の中にはこんなすごい知識を
もった人もいるんだと驚いています。
私もいつかは、得た知識や経験を元に、人の役に立てたらと思っています。
--------------------------------------------------------------------
かなり褒め上げられてます。。。ありがとうございます。
ネットワークの世界は日々新しい規格ができたりして勉強勉強の毎日
です。まだまだ足りないところも多いです。
やってみようという気持ちがあれば誰でもできますよ。たまに面倒な
ときもありますが。。。
………………………………………………………
IP Network Skill vol.000133 11/07/03
発行者：adzuki http://www.xai.nu/ipnet
……………………………… ipnet3@xai.nu ……
![メルマガスタンド[メルマ！]](/img/common/melma_logo.gif){kind=logo}
>> メルマ！の会報誌もお届けします
