約 277,420 件
https://w.atwiki.jp/sevenlives/pages/1013.html
RFC 読み：あーるえふしー 英語：request for comments 別名： 意味： RFCとは、IETFによる技術仕様の策定および公開形式のこと。 世界から様々な提案や優れた技術仕様を募集し、標準化に結びつける活動をしています。 その内容は広く一般に公開されています。 インターネットの標準化に大きく関わっている。 ただし、すべてのRFCが標準化を求めているわけではない。 2010年04月06日 STD? Informatial RFC? IETF IESG? インターネット RFC2822
https://w.atwiki.jp/program/pages/39.html
トップページ 規格 RFC翻訳の調査 ページビュー -
https://w.atwiki.jp/program/pages/25.html
概要 RFC翻訳ページのリストを作りたい。 リンクの追加と削除をお願いします。 リスト RFC1 追加待ち。 RFC2 追加待ち。 RFC3 追加待ち。 RFC4 追加待ち。 RFC 追加待ち。 RFC 追加待ち。 RFC 追加待ち。 ページビュー -
https://w.atwiki.jp/sevenlives/pages/1014.html
RFC2822 読み：あーるえふしーにーはちにーにー 英語： 別名： 意味： RFC2822とは電子メール用のフォーマットを定めた文書のこと。 IETFが2001年に発行しました。 2008年01月19日 IETF RFC822?
https://w.atwiki.jp/selflearn/pages/52.html
RFC3782 開始日 2007年05月26日 最終更新日 2009年06月03日 はじめに RFC3782について自分でまとめた情報を記しています。このRFCはWindowsVistaのTCPで採用されています。 オリジナル 「The NewReno Modification to TCP s Fast Recovery Algorithm」 http //www.ietf.org/rfc/rfc3782.txt 公開日：2004年4月 注意 もともと個人利用を目的としてまとめているために、けっこう意訳している部分があります。「意味分からないよ」とか「おかしいんじゃない？」とかいうのがあれば、オリジナルを参照するか、コメントで質問してください（がんばって調べます）。 用語 訳文に出てくる各語に対応する原文と意味を以下に記します。 略語 正式名称 意味 SMSS SENDER MAXIMUM SEGMENT SIZE 送信側が送ることのできる最大セグメントサイズ cwnd CONGESTION WINDOW 輻輳ウィンドウ。送信側が相手のACK無しで一度に送ることができるサイズの一要因 ssthresh Slow Start THRESHold スロースタートから輻輳回避アルゴリズムに移るときのしきい値 FlightSize FLIGHT SIZE ネットワーク中に流れているデータのバイト数 recover -- NewReno実装における肝となる変数。初期値は初回に送信したセグメント数(単位：バイト)で、再送処理時に更新される 更新履歴 2007/5/26 作成開始 概要 このドキュメントは、TCPのRFC2582に記された高速再転送＆高速リカバリアルゴリズムに記されている「実装依存(Variant)」という用語について、それを明確にする目的で書かれた。RenoとNewRenoの違いを明らかにするのも目的に含まれる。 なお、このドキュメントはSACKが無効であるときの通信を前提としている。 このドキュメントでRFC2582を改訂する（＝RFC2582はObsolete扱い）。したがって、「NewReno」といえば本RFCを指す。 まとめ このRFCの構成 本RFCの、各章の概要は以下の通り。 1-2章 概要と用語の説明 3章 NewRenoにおけるFast RetransmitとFast Recoveryの基本動作（RFC2581の振り返り） 4-6章 幾つかのNewRenoの実装の紹介と、それら実装の背景。ACKベースのヒューリスティクとTimestampベースのヒューリスティクの紹介 7-8章 送信側、受信側における推奨動作 9章 NS2におけるシミュレーションファイルの紹介 10章 RenoとNewRenoの比較。NewRenoのメリット・デメリットの紹介 11章 RFC2582からの変更点 12-15章 まとめ〜参考文献 現状 NewRenoが公開されてから、RFC2582でいうところの実装依存部が数多くの派生実装を生み出す結果になっている。 高速再転送＆高速リカバリアルゴリズムの問題点 SACKがないときに、１ウィンドウサイズ内の複数パケットがロストした場合に同アルゴリズムが有効に動作しない点。 １個のパケットがロストした時は、高速再転送＆高速リカバリアルゴリズムによって素早く元の通常通信に戻る。しかし、複数のパケットがロストした場合、その先頭パケットのみACKが届き、高速再転送アルゴリズムが始まる前には送信済みで、しかし途中でロストしたデータについてはACKされない。 これを「Partial acknowledgement（中途半端なACK）」と呼んでいる。 SACKが動作すれば必要なパケットのみの再送によって速やかに復旧するため問題はないが、SACKはノードの両端がSACKに対応していないといけないため、SACKに頼るだけでは非効率な通信になってしまう可能性がある。 ちなみにタイムスタンプオプションもPartial acknowledgementには有効。なぜなら、高速再転送のときに飛んでいた重複ACKが、高速再転送の前か後かが分かるため。 NewRenoを一言で言うと？ Renoよりも改善されたFast Recoveryアルゴリズムを持っているTCPシステム。 NewRenoの動作 NewRenoの動作シーケンスを以下に記す。RFC2581でFast RetransmitとFast Recoveryについて触れられているが、NewRenoにおいてのそれらは少々異なる動作をする。 3つの重複ACK：3つ目の重複ACKを受信し、なおかつ送信側がFast Recoveryモードになっていない場合、累積のACKフィールドが変数"recover"の値よりも大きいかどうかを確認する。大きければ1.1へ、そうでなければ1.2へ移行する。Fast Retransmitモードの開始：ssthreshを「FlightSize/2」または「2*SMSS」のどちらか大きい方に設定し、さらにこれまでに送信された最大シーケンス番号を変数"recover"にセットする。2へ移る。 Fast Retransmitモードの回避：Fast Retransmit/Fast Recoveryモードには遷移せず、ssthreshも更新しないで、本シーケンスを抜ける（重複ACKが届いても何もしない）。 Fast Retransmitによる再送：ロストしたTCPセグメントを再送し、cwndに「ssthresh+3*SMSS」をセットする。3SMSSを足すのは重複ACKを考慮してすぐに復帰するため。 Fast Recoveryへの遷移：本期間中に重複ACKを受信したら、その都度cwndをSMSSずつ増加させる。これはネットワーク中に残っているセグメントを考慮してすぐにcwndを拡大させるため。 Fast Recoveryの続き：cwndまたはレシーバの受信バッファが許す限り、セグメントを送信する。 新しいデータに対するACKが届いた場合、そのACKは「2で再送されたデータへのACK」または「それより後の再送データへのACK」のどちらかと考えられる。後述。 再送のタイムアウト：再送に対するタイムアウトが発生した場合、recoverには送信した最大のシーケンス番号を記録しておき、可能ならばFast Recovery状態を抜ける 5番のときの処理について、もう少し掘り下げよう。 「2で再送されたデータへのACK」 つまり、送信側から転送したデータがすべて確認応答された、ということを意味している。"recover"で記録した値も含めて。そこでcwndを MIN(ssthresh, FlightSize+SMSS) ssthresh のどちらかに設定し、ウィンドウサイズを収縮(deflate)させる。この時点で、これ以上ウィンドウサイズを拡張するのは危険だと判断するため。 「それ(2で再送されたデータ)より後の再送データへのACK」 RFC2582との違い 幾つかある。 複数回の高速再転送アルゴリズムが連続して発生してしまうこと 高速再転送のロジックにはACK-basedヒューリスティクと、TIME-basedヒューリスティクが存在する 参考サイト・RFC TCP Congestion Control：http //www.ietf.org/rfc/rfc2581.txt 1999年4月 NewReno Modification to TCP s Fast Recovery：http //www.ietf.org/rfc/rfc2582.txt 1999年4月 （ - ）
https://w.atwiki.jp/808909/pages/15.html
http //www.ietf.org/rfc.html RFC 2460 Internet Protocol, Version 6 (IPv6)
https://w.atwiki.jp/rockfeel/pages/12.html
RFCとは RFC(RockFeelClub：ロックフィール部)とは日本工業大学の数ある音楽団体の中でも、 特にバカな奴らが構成する非常にイケてる部活である。 ロックフィールという名前であるがどんなジャンルでもOKだ。 ちなみに登山とか岩登りとか関係ないです。 活動内容は年に5回程度ライブを行っていてそれ以外にも多くの活動をしている。 だがここで多くを語るのはあえてやめておこう。 それはキミ自身の心と体で確かめて欲しいからだ！ 最後に現部長のオーガより貴重なお言葉をいただいたためここに掲載する。 部長の小川です。 みんなが楽しめる仲の良い部活を目指して頑張っていきます★ 自ら本名を出してしまっているのがいかにもロックフィーラーといったところでしょうか。
https://w.atwiki.jp/code_matome/pages/31.html
http //tools.ietf.org/html/rfc3748 Section 1、2、4、5、Appendix A Network Working Group B. Aboba Request for Comments 3748 Microsoft Obsoletes 2284 L. Blunk Category Standards Track Merit Network, Inc J. Vollbrecht Vollbrecht Consulting LLC J. Carlson Sun H. Levkowetz, Ed. ipUnplugged June 2004 Extensible Authentication Protocol (EAP) Status of this Memo このメモの位置づけ This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. このドキュメントはインターネットコミュニティにインターネット標準の規定とプロトコルと改良のための提案と議論の要求をする。 標準化状態とプロトコル状態はSTD1の最新版を参照してください。 このメモの配布には制限がない。 Copyright Notice 著作権表記 Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004). Abstract 概要 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. 複数の認証方式をサポートする認証のフレームワーク、Extensible Authentication Protocol(EAP)を定義する。 EAPはIPを必要とせず、PPPやIEEE 802のようなデータリンクレイヤで直接動作する。 EAPは重複排除、再送を提供するが、それは下位レイヤの順序保証に頼っている。 FragmentationはEAPではサポートされないが、個別のEAP methodではサポートしてもよい。 This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. RFC2284との変更の概要はAppendix Aにある。 RFC 2284を廃止する。 Aboba, et al. Standards Track [Page 1] RFC 3748 EAP June 2004 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 導入 1.1. Specification of Requirements . . . . . . . . . . . . . 4 要求仕様 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 用語 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 6 適用性 2. Extensible Authentication Protocol (EAP). . . . . . . . . . . 7 Extensible Authentication Protocol (EAP) 2.1. Support for Sequences . . . . . . . . . . . . . . . . . 9 サポートするシーケンス 2.2. EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10 EAP Multiplexing Model. 2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . 12 Pass-Throughの動作 2.4. Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14 Peer-to-Peerの動作 3. Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15 低レイヤの動作 3.1. Lower Layer Requirements. . . . . . . . . . . . . . . . 15 低レイヤへの要求事項 3.2. EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18 PPPでのEAP 3.2.1. PPP Configuration Option Format. . . . . . . . . 18 PPP Configuration Option Format 3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19 IEEE 802でのEAP 3.4. Lower Layer Indications . . . . . . . . . . . . . . . . 19 Lower Layer Indications 4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20 EAPのパケットフォーマット 4.1. Request and Response. . . . . . . . . . . . . . . . . . 21 RequestとResponse 4.2. Success and Failure . . . . . . . . . . . . . . . . . . 23 SuccessとFailue 4.3. Retransmission Behavior . . . . . . . . . . . . . . . . 26 再送動作 5. Initial EAP Request/Response Types. . . . . . . . . . . . . . 27 5.1. Identity. . . . . . . . . . . . . . . . . . . . . . . . 28 5.2. Notification. . . . . . . . . . . . . . . . . . . . . . 29 5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31 5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32 5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35 5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . 36 5.6. Generic Token Card (GTC). . . . . . . . . . . . . . . . 37 5.7. Expanded Types. . . . . . . . . . . . . . . . . . . . . 38 5.8. Experimental. . . . . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 6.1. Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41 6.2. Method Types. . . . . . . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7.1. Threat Model. . . . . . . . . . . . . . . . . . . . . . 42 7.2. Security Claims . . . . . . . . . . . . . . . . . . . . 43 7.2.1. Security Claims Terminology for EAP Methods. . . 44 7.3. Identity Protection . . . . . . . . . . . . . . . . . . 46 7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47 7.5. Packet Modification Attacks . . . . . . . . . . . . . . 48 7.6. Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49 7.7. Connection to an Untrusted Network. . . . . . . . . . . 49 7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . 50 7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . 50 7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51 7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53 Aboba, et al. Standards Track [Page 2] RFC 3748 EAP June 2004 7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53 7.13. Separation of Authenticator and Backend Authentication Server. . . . . . . . . . . . . . . . . . . . . . . . . 54 7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55 7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55 7.16. Protected Result Indications. . . . . . . . . . . . . . 56 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 59 9.1. Normative References. . . . . . . . . . . . . . . . . . 59 9.2. Informative References. . . . . . . . . . . . . . . . . 60 Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64 RFC2284からの変更履歴 Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67 1. Introduction 導入 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. 複数の認証方式をサポートする認証のフレームワーク、Extensible Authentication Protocol(EAP)を定義する。 EAPはIPを必要とせず、PPPやIEEE 802のようなデータリンクレイヤで直接動作する。 EAPは重複排除、再送を提供するが、それは下位レイヤ保証に頼っている。 FragmentationはEAPではサポートされないが、個別のEAP methodではサポートしてもよい。 EAP may be used on dedicated links, as well as switched circuits, and wired as well as wireless links. To date, EAP has been implemented with hosts and routers that connect via switched circuits or dial-up lines using PPP [RFC1661]. It has also been implemented with switches and access points using IEEE 802 [IEEE-802]. EAP encapsulation on IEEE 802 wired media is described in [IEEE-802.1X], and encapsulation on IEEE wireless LANs in [IEEE-802.11i]. EAPは専用線、回線交換、有線、無線で使用してよい。 EAPは回線交換 or ダイヤルアップを経由してPPPを使用して接続したルーターとホストに実装されている。 IEEE802を使用したスイッチとAPにも実装されている。 IEE802有線でのEAPカプセル化は[IEEE-802.1X]、 無線LANのカプセル化は[IEEE-802.11i]で説明されている。 One of the advantages of the EAP architecture is its flexibility. EAP is used to select a specific authentication mechanism, typically after the authenticator requests more information in order to determine the specific authentication method to be used. Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the use of a backend authentication server, which may implement some or all authentication methods, with the authenticator acting as a pass-through for some or all methods and peers. EAPアーキテクチャの利点の一つは柔軟性である。 EAPは認証方式を選択するために使用され、EAP authenticatorは認証方式を決定するため情報を要求する。 新しい認証方式をサポートするたびに更新されるauthentiatorではなく、EAPでは各種認証方式をサポートしたバックエンド認証サーバとして使用を可能とし、authenticatorはmethonとpeerのpass-throughとして動作する。 Within this document, authenticator requirements apply regardless of whether the authenticator is operating as a pass-through or not. Where the requirement is meant to apply to either the authenticator or backend authentication server, depending on where the EAP authentication is terminated, the term EAP server will be used. このドキュメントではauthenticatorの要求事項がauthenticatorがpass-throughとして動作しているかどうかに関わらず適用される。 要求事項がEAP認証の終端される場所によって、バックエンドのauthentication serverかauthenticatorに適用される意図の場合、EAP serverという用語が使用される。 Aboba, et al. Standards Track [Page 3] RFC 3748 EAP June 2004 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. The key words MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , MAY , and OPTIONAL in this document are to be interpreted as described in [RFC2119]. このドキュメントのキーワード MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , MAY , and OPTIONAL はRFC2119で説明されるように解釈されること。 1.2. Terminology 用語 This document frequently uses the following terms 下記の用語をよく使う。 authenticator The end of the link initiating EAP authentication. The term authenticator is used in [IEEE-802.1X], and has the same meaning in this document. EAP認証を開始するリンクの終端。[IEEE-802.1X]のauthentiatorと同じ意味。 SeGW、APの役割。（コメント※） peer The end of the link that responds to the authenticator. In [IEEE-802.1X], this end is known as the Supplicant. authenticatorに応答するリンクの終端。 [IEEE-802.1X]のサプリカント。 Supplicant The end of the link that responds to the authenticator in [IEEE- 802.1X]. In this document, this end of the link is called the peer. [IEEE-802.1X]におけるauthenticatorへ応答するリンクの終端。 このドキュメントのpeer。 backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X]. バックエンド認証サーバはauthenticatorに認証サービスを提供するエンティティ。 authenticatorのためにEAPメソッドを実行する。[IEEE-802.1X]でも使用される。 AAA Authentication, Authorization, and Accounting. AAA protocols with EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP]. In this document, the terms AAA server and backend authentication server are used interchangeably. 認証、認可、課金。 EAPがサポートするAAAプロトコルはRADIUS、Diameterを含む。 RADIUS：半径、Diameter：直径でDiameterはRADIUSの進化版。SCTP、TCPにも対応している。 Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279]. 人間が読める形式の文字列。 このメッセージはUTF-8形式であること。 Aboba, et al. Standards Track [Page 4] RFC 3748 EAP June 2004 EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. peerとのEAP認証方式を終端するエンティティ。 バックエンド認証サーバを使用しない場合、EAP serverはauthenticatorの一部である。 authenticatorがpass-throughで動作する場合、EAP serverはバックエンド認証サーバである。 Silently Discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the event, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. 後継処理をせずにパケットを破棄する実装を意味する。 実装はSilently Discard packetのイベントをログに記録する機能と統計情報(カウンタ)に記録する機能を提供すること。 Successful Authentication In the context of this document, successful authentication is an exchange of EAP messages, as a result of which the authenticator decides to allow access by the peer, and the peer decides to use this access. The authenticator s decision typically involves both authentication and authorization aspects; the peer may successfully authenticate to the authenticator, but access may be denied by the authenticator due to policy reasons. EAPメッセージの交換によりauthenticatorがpeerにアクセスを許可し、peerはアクセスを使用すること。 authenticatorの決定は、認証と認可の両方を含む。authenticatorはpeerに認証を成功させてもポリシー上の理由からアクセスを拒否してもよい。 Message Integrity Check (MIC) A keyed hash function used for authentication and integrity protection of data. This is usually called a Message Authentication Code (MAC), but IEEE 802 specifications (and this document) use the acronym MIC to avoid confusion with Medium Access Control. データの完全性保証と認証のために使用される鍵付きハッシュ関数。 Message Authentication Code(MAC)と呼ばれるが、Media Access Controlとの混同を避けるため、MICを使用する。 ※鍵付きハッシュ関数：共通鍵を追加してハッシュ計算する。 Cryptographic Separation Two keys (x and y) are cryptographically separate if an adversary that knows all messages exchanged in the protocol cannot compute x from y or y from x without breaking some cryptographic assumption. In particular, this definition allows that the adversary has the knowledge of all nonces sent in cleartext, as well as all predictable counter values used in the protocol. Breaking a cryptographic assumption would typically require inverting a one-way function or predicting the outcome of a cryptographic pseudo-random number generator without knowledge of the secret state. In other words, if the keys are cryptographically separate, there is no shortcut to compute x from y or y from x, but the work an adversary must do to perform this computation is equivalent to performing an exhaustive search for the secret state value. 2つのキー(x and y)がすべてのメッセージを知っている攻撃者が暗号の仮定を破ることなくxからy、yからxを計算できない場合、暗号的に独立している。メッセージには平文で送られたnonce(ノンス)やすべてのカウンタも含まれる。暗号の仮定を破るとは、一方向関数を逆算出することや擬似乱数生成器の結果を予測することである。 Cryptographically separateを言い換えると、xからy、yからxを計算するショートカットはなく、攻撃者がかなりの量の計算を必要とすることである。 Aboba, et al. Standards Track [Page 5] RFC 3748 EAP June 2004 Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. In existing implementations, a AAA server acting as an EAP server transports the MSK to the authenticator. EAP peerとEAP serverとの間で導出され、EAP methodにより転送されるキー要素。 MSKは64オクテット以上である。 既存の実装では、EAP serverとして動作するAAA serverはauthenticatorにMSKを転送する。 Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet. EAP clientとEAP serverとの間で導出され、EAP methodにより転送され追加のキー要素。 EMSKは64オクテット以上である。 EMSKはauthenticatorおよび第三者と共有されない。EMSKは今後の使用のためにreserveされていて、定義はまだされていない。 Result indications A method provides result indications if after the method s last message is sent and received methodの最後のメッセージが送受信された後、結果通知を提供するmethod。 1) The peer is aware of whether it has authenticated the server, as well as whether the server has authenticated it. peerがserverの認証を認識したかだけではなく、serverがpeerを認証したかどうか。 2) The server is aware of whether it has authenticated the peer, as well as whether the peer has authenticated it. serverがpeerの認証を認識したかだけではなく、peerがserverを認証したかどうか。 In the case where successful authentication is sufficient to authorize access, then the peer and authenticator will also know if the other party is willing to provide or accept access. This may not always be the case. An authenticated peer may be denied access due to lack of authorization (e.g., session limit) or other reasons. Since the EAP exchange is run between the peer and the server, other nodes (such as AAA proxies) may also affect the authorization decision. This is discussed in more detail in Section 7.16. 認証に成功し、アクセス可能であることはpeerとauthenticatorがそれぞれ知っている。ただし、常にそうではない。認証されたpeerがアクセス権がない場合(セッション制限)などがある。 EAP認証がpeerとサーバ間で実施するため、他のノード(AAA proxies等)が認証の決定に影響を与える可能性がある。これについてはSection 7.16で述べる。 1.3. Applicability 適用性 EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. EAPはIPレイヤ接続が利用不可の場合でもネットワークアクセス認証が使用できるように設計された。 EAPを大量のデータ転送のような目的に使用することは推奨しない。 Since EAP does not require IP connectivity, it provides just enough support for the reliable transport of authentication protocols, and no more. EAPはIP接続を必要としないので認証プロトコルに必要なだけの信頼性転送を提供する。 EAP is a lock-step protocol which only supports a single packet in flight. As a result, EAP cannot efficiently transport bulk data, unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960]. EAPは1パケット送信のみをサポートするロックステッププロトコルである。 1パケットずつ送信する。 そのためEAPはTCPやSCTPのようなトランスポートプロトコルと異なり、大量のデータ転送を効率的に転送することができない。 Aboba, et al. Standards Track [Page 6] RFC 3748 EAP June 2004 While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so out of order reception is not supported. EAPは再送をサポートしているが、下位レイヤの順序保証を前提とする。そのため非順序の受信はサポートしない。 Since EAP does not support fragmentation and reassembly, EAP authentication methods generating payloads larger than the minimum EAP MTU need to provide fragmentation support. EAPはfragmentationとreassemblyをサポートしないため、最小のEAP MTUより大きいペイロードを生成するEAP認証メソッドはfragmentationをサポートする必要がある。 While authentication methods such as EAP-TLS [RFC2716] provide support for fragmentation and reassembly, the EAP methods defined in this document do not. As a result, if the EAP packet size exceeds the EAP MTU of the link, these methods will encounter difficulties. EAP-TLSのような認証方式は、fragmentationとreassemblyをサポートするが、本ドキュメントで定義するEAPメソッドではサポートしない。 EAPパケットサイズがEAP MTUを超えた場合、難しいことになる。 EAP authentication is initiated by the server (authenticator), whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an authentication algorithm to add one or two additional messages (at most one roundtrip) in order to run over EAP. 多くの認証プロトコルがクライアント(peer)から開始されるのに対し、EAP認証はサーバー(authenticator)から開始される。結果、EAPでは1 or 2の追加メッセージが必要になる。(1回以上の往復が必要) Where certificate-based authentication is supported, the number of additional roundtrips may be much larger due to fragmentation of certificate chains. In general, a fragmented EAP packet will require as many round-trips to send as there are fragments. For example, a certificate chain 14960 octets in size would require ten round-trips to send with a 1496 octet EAP MTU. 証明書ベースの認証がサポートされる場合、証明書のfragmentationにより往復回数が多くなる。 fragmentationされたEAPパケットは多くの往復回数を要求する。 例えば、1,469オクテットのEAP MTUで14,960オクテットの証明書を送信するために10往復必要になる。 Where EAP runs over a lower layer in which significant packet loss is experienced, or where the connection between the authenticator and authentication server experiences significant packet loss, EAP methods requiring many round-trips can experience difficulties. In these situations, use of EAP methods with fewer roundtrips is advisable. パケロスが多い場合は往復回数の少ないEAPメソッドの使用を推奨する。 2. Extensible Authentication Protocol (EAP) The EAP authentication exchange proceeds as follows 以下のようにEAPプロトコルは実行する。 [1] The authenticator sends a Request to authenticate the peer. The Request has a Type field to indicate what is being requested. Examples of Request Types include Identity, MD5-challenge, etc. The MD5-challenge Type corresponds closely to the CHAP authentication protocol [RFC1994]. Typically, the authenticator will send an initial Identity Request; however, an initial Identity Request is not required, and MAY be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines, Aboba, et al. Standards Track [Page 7] RFC 3748 EAP June 2004 dedicated switch or dial-up ports), or where the identity is obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.). [1] authenticatorはpeerを認証するためのRequestを送信する。 RequestはRequestを示すためのType filedをもつ。 Request Typeは例えばIdentity、MD5-challengeなどを含む。 MD5-challenge TypeはCHAP認証プロトコル[RC1994]に関係している。 一般的にauthenticatorはinitial Identity Requestを送信するが、initial Identity Requestは必要ではなく、無視(bypass)してよい。 例えば、Identityはpeerが接続したポート(専用線、ダイヤルアップポート)によって決定されたり、Identityが他の方法(MACアドレス、MD5-Challenge ResponseのName field等)で得られた場合は不要になる。 [2] The peer sends a Response packet in reply to a valid Request. As with the Request packet, the Response packet contains a Type field, which corresponds to the Type field of the Request. peerはRequestに対してResponseパケットを送信する。 [2] Requestパケットを同様に、ReponseパケットはRequestのType filedに対応するType filedを含む。 [3] The authenticator sends an additional Request packet, and the peer replies with a Response. The sequence of Requests and Responses continues as long as needed. EAP is a lock step protocol, so that other than the initial Request, a new Request cannot be sent prior to receiving a valid Response. The authenticator is responsible for retransmitting requests as described in Section 4.1. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer. [3] authenticatorは追加のRequestパケットを送信し、peerはResponseで応答する。 Request-Responseのシーケンスは必要なだけ続く。 EAPはlock stepプロトコルなので、Initial Request以外には新しいRequestはRespose受信前に送信することができない。 authenticatorはSection 4.1のとおり、Requestを再送する責任がある。 適当な回数再送した後、authenticatorはEAPを終了すること。 authenticatorは再送した場合 or peerからResponseを取得できなかった場合にSuccess or Failure packetをpeerに送らないこと。 [4] The conversation continues until the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests), in which case the authenticator implementation MUST transmit an EAP Failure (Code 4). Alternatively, the authentication conversation can continue until the authenticator determines that successful authentication has occurred, in which case the authenticator MUST transmit an EAP Success (Code 3). [4] この処理はauthenticatorがpeerの認証に失敗(Requestに対する不適当なResponse)し、authenticatorがEAP Failure(Code 4)を送信するまで続く。 または、authenticatorが認証の成功と判断し、authenticatorがEAP Success(Code 3)を送信するまで続く。 Advantages 利点 o The EAP protocol can support multiple authentication mechanisms without having to pre-negotiate a particular one. EAPは事前のネゴシエーション無しに複数の認証メカニズムをサポートできる。 o Network Access Server (NAS) devices (e.g., a switch or access point) do not have to understand each authentication method and MAY act as a pass-through agent for a backend authentication server. Support for pass-through is optional. An authenticator MAY authenticate local peers, while at the same time acting as a pass-through for non-local peers and authentication methods it does not implement locally. Network Access Server(NAS)(スイッチ、アクセスポイント)は認証方式を認識する必要はなく、バックエンド認証サーバーのためのpass-throughエージェントそして機能してよい。pass-throughのサポートはオプションである。 authenticatorはローカル認証とpass-throghの認証を同時に実行できる。 o Separation of the authenticator from the backend authentication server simplifies credentials management and policy decision making. authenticatorとバックエンド認証サーバーとの分離は認証情報の管理とポリシーの決定を簡素化できる。 Aboba, et al. Standards Track [Page 8] RFC 3748 EAP June 2004 Disadvantages 欠点 o For use in PPP, EAP requires the addition of a new authentication Type to PPP LCP and thus PPP implementations will need to be modified to use it. It also strays from the previous PPP authentication model of negotiating a specific authentication mechanism during LCP. Similarly, switch or access point implementations need to support [IEEE-802.1X] in order to use EAP. PPPで使用するためにPPP LCPに新しい認証タイプの追加が必要となる。（PPP LCPはPPPのリンク制御用プロトコル、PPP NCPはレイヤ3設定用）。 スイッチ or アクセスポイントでEAPを使う場合、IEEE-802.1Xが必要になる。（MACフレームをRADIUSフレームに入れ替えたりする） o Where the authenticator is separate from the backend authentication server, this complicates the security analysis and, if needed, key distribution. authenticatorとバックエンド認証サーバとの分離はセキュリティ分析とキー管理が複雑になる。 2.1. Support for Sequences サポートするシーケンス An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, the peer and authenticator MUST utilize only one authentication method (Type 4 or greater) within an EAP conversation, after which the authenticator MUST send a Success or Failure packet. EAPではメソッドのシーケンスを使用する。 一般例はMD5-ChallnegeのようなEAP認証とIdentity Requestである。 peer と authenticatorはEAPでは一つだけ認証方式(Type 4以上)を使用すること。そして、authenticatorはSuccess or Failure パケットを送信すること。 Once a peer has sent a Response of the same Type as the initial Request, an authenticator MUST NOT send a Request of a different Type prior to completion of the final round of a given method (with the exception of a Notification-Request) and MUST NOT send a Request for an additional method of any Type after completion of the initial authentication method; a peer receiving such Requests MUST treat them as invalid, and silently discard them. As a result, Identity Requery is not supported. PeerがInitial Requestと同じTypeのResponseを送信した後、authenticatorはメソッドの完了前に異なるタイプのRequestを送ってはいけない（Notification Requestは除く）また、authenticatorはInitial 認証メソッドが完了した後に別のTypeの追加メソッドのRequestを送ってはいけない。 PeerがそのようなRequestを受信した場合、無効として扱い、破棄すること。結果、Identity Requeryはサポートされない。 A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an authenticator receiving an unexpected Nak SHOULD discard it and log the event. peerはinitial non-Nak Responseを送信した後、Requestに対する応答としてNak(legacy or expanded)を送信しないこと。 authenticatorは予期しないNakを破棄し、ロギングすること。 Multiple authentication methods within an EAP conversation are not supported due to their vulnerability to man-in-the-middle attacks (see Section 7.4) and incompatibility with existing implementations. EAPにおける複数認証方式は中間者攻撃(Section 7.4)に脆弱性があり、既存の実装と互換性がないため対応しない。 Where a single EAP authentication method is utilized, but other methods are run within it (a tunneled method), the prohibition against multiple authentication methods does not apply. Such tunneled methods appear as a single authentication method to EAP. Backward compatibility can be provided, since a peer not supporting a tunneled method can reply to the initial EAP-Request with a Nak Aboba, et al. Standards Track [Page 9] RFC 3748 EAP June 2004 (legacy or expanded). To address security vulnerabilities, tunneled methods MUST support protection against man-in-the-middle attacks. 単一のEAP認証方式が他の方式(Tunneled method)を使って利用される場合、複数の認証方式を禁止する規定は適用されない。 TunneledメソッドはEAPの単一の認証方式とされる。 Tunneled方式をサポートしていないpeerがInitial EAP RequestでNakを応答できるように下位互換性を提供される。 2.2. EAP Multiplexing Model Conceptually, EAP implementations consist of the following components EAPの実装の概念は下記のコンポーネントで構成される。 [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP, wired IEEE 802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP [PIC]. Lower layer behavior is discussed in Section 3. 低レイヤはpeerとauthenticatorとの間でのEAPフレームの送受信をする。 EAPはPPP、IEEE802.1X、IEEE802.11、UDP、IKEv2、TCPなど様々な低レイヤで動作する。 低レイヤの動作はSection 3で説明する。 [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers. 低レイヤを介してEAPパケットを送受信する。重複検知、再送を提供し、peerとauthenticatorでEAPメッセージを送受信する。 [c] EAP peer and authenticator layers. Based on the Code field, the EAP layer demultiplexes incoming EAP packets to the EAP peer and authenticator layers. Typically, an EAP implementation on a given host will support either peer or authenticator functionality, but it is possible for a host to act as both an EAP peer and authenticator. In such an implementation both EAP peer and authenticator layers will be present. Code filedに基いて、EAPレイヤはEAP peerレイヤとauthenticatorレイヤへの着信パケットを逆多重する。 一般的、ホスト上ではpeer or authenticatorのいずれかをサポートするが、ホストがpeerとauthenticatorの両方をサポートすることも可能である。 そのような実装ではEAP peerレイヤとEAP authenticatorレイヤが存在する。 [d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5. EAPメソッドは認証アルゴリズムを実装し、EAP peerレイヤとEAP authenticatorレイヤを介してEAPメッセージを送受信する。 EAPではfragmentationをサポートしないため、Section 5で議論されるEAPメソッドの責任である。 The EAP multiplexing model is illustrated in Figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it. EAP多重モデルはFigure 1に示される。 実装はこのモデルへの準拠が要件にないことに注意してください。 Aboba, et al. Standards Track [Page 10] RFC 3748 EAP June 2004 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Peer layer | | EAP ! Auth. layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! layer | | EAP ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! layer | | Lower ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! Peer ! Authenticator +------------ -------------+ Figure 1 EAP Multiplexing Model Within EAP, the Code field functions much like a protocol number in IP. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the EAP layer to the EAP peer layer, if implemented. EAP packets with Code=2 (Response) are delivered to the EAP authenticator layer, if implemented. EAPのCode filed functionはIPのprotocol numberのようなフィールドである。 EAPレイヤはCode filedに応じて着信EAPパケットを分離する。 Code=1 (Request), 3 (Success), and 4 (Failure) で受信したEAPパケットは実装していれば、EAPレイヤからEAP peerレイヤに転送される。 Code=2 (Response)で受信したEAPパケットは実装していればEAPレイヤからEAP authenticatorレイヤに転送される。 Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. An EAP method implementation on a host may register to receive packets from the peer or authenticator layers, or both, depending on which role(s) it supports. EAPのType filed functionはUDPやTCPのポート番号のようなfieldである。 EAP peerレイヤ、EAP authentictorレイヤはTypeに応じて着信EAPパケットを逆多重し、Typeに対応したEAPメソッドで転送する。 ホスト上のEAPメソッドの実装はpeerレイヤ、authenticatorレイヤの役割によってそれらからパケットを受信できるように登録できる。 Since EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater), in addition to the Identity method. The Identity Type is discussed in Section 5.1. EAP認証方式はIdentityにアクセスできるため、実装ではIdentity methodに加え、認証方式(Type 4以上)へのIdentity RequestとIdentity Responseにアクセスできること。 Identity TypeはSection 5.1で議論する。 Aboba, et al. Standards Track [Page 11] RFC 3748 EAP June 2004 A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response are available to another method. The Notification Type is discussed in Section 5.2. Notification ResponseはpeerがNotification Requestを受信したことの確認のためだけに使われる。 これはNotification RequestやNotification Responseのコンテンツは別のメソッドで利用可能であると仮定することはできない。 Notification TypeはSetion 5.2で議論する。 Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the contents of the Nak Response(s) are available to another method. The Nak Type(s) are discussed in Section 5.3. Nak(Type 3)やExpanded Nak（Type 254）はメソッドのネゴシエーションのために利用される。 peerはNak Reposen（Type3） or Expanded Nak Response(Type 254)で許容できないタイプのinitial EAP Requestに応答する。 Nak Responseのコンテンツが別のメソッドで利用可能であると仮定することはできない。 Nak TypeはSection 5.3で議論する。 EAP packets with Codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. EAPパケットのSuccess Code or Failure CodeはType filedが含まれていないとEAPメソッドに転送されない。 Success と FailureはSection 4.2で議論する。 Given these considerations, the Success, Failure, Nak Response(s), and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods. これらの考察より、Success、Failure、Nak Response、Notification Request/ResponseメッセージはEAPメソッドへデータを送信するために使用してはいけない。 2.3. Pass-Through Behavior When operating as a pass-through authenticator , an authenticator performs checks on the Code, Identifier, and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator layer to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it. pass-through authenticatorとして動作する場合、authenticatorはSection 4.1で定義されるCode、Identifier、Lengthをチェックする。authenticatorはpeerから受信したEAPパケットをバックエンド認証サーバのauthenticatorレイヤに転送する。peer宛のバックエンド認証サーバからの受信パケットはpeerに転送される。 A host receiving an EAP packet may only do one of three things with it act on it, drop it, or forward it. The forwarding decision is typically based only on examination of the Code, Identifier, and Length fields. A pass-through authenticator implementation MUST be capable of forwarding EAP packets received from the peer with Code=2 (Response) to the backend authentication server. It also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer. EAPパケットを受信したホストは3つのいずれかのみを実行してよい。ACT or DROP or FORWARD。 FORWARDINGの決定はCode、Identifier、Lengthのチェックに基づく。 Pass-through認証の実装ではバックエンド認証サーバにCode=2(Response)のpeerから受信したEAPパケットを転送できること。 同様に、バックエンド認証サーバはEAPパケットを受信でき、Code=1 (Request), Code=3 (Success), Code=4 (Failure)をpeerに転送できること。 Unless the authenticator implements one or more authentication methods locally which support the authenticator role, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. Where the authenticator supports local authentication methods, it MAY examine the Type field to determine whether to act on the packet itself or forward it. Compliant pass- through authenticator implementations MUST by default forward EAP packets of any Type. Authenticatorが一つ以上のローカル認証方式を実装していない場合、EAPメソッドレイヤのheader filed(Type、Type-Data)はFORWARDINGの判断に使用されない。 authenticatorはローカル認証をサポートしている場合、自身で制御する(ACT)かFORWARDするか判断するためにType filedをチェックしてよい。 pass-throughに準拠したauthenticatorの実装では任意のTypeのEAPパケットをデフォルトで転送すること。 Aboba, et al. Standards Track [Page 12] RFC 3748 EAP June 2004 EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer layer. Therefore, unless a host implements an EAP peer layer, these packets will be silently discarded. Similarly, EAP packets received with Code=2 (Response) are demultiplexed by the EAP layer and delivered to the authenticator layer. Therefore, unless a host implements an EAP authenticator layer, these packets will be silently discarded. The behavior of a pass-through peer is undefined within this specification, and is unsupported by AAA protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP]. Code=1 (Request), Code=3 (Success), Code=4 (Failure)のEAPパケットはEAPレイヤによって逆多重化されpeerレイヤに転送される。そのためホストがEAP peerレイヤを実装していない場合、パケットは破棄される。 同様に、Code=2 (Response) で受信したEAPパケットはEAPレイヤによって逆多重化されauthenticatorレイヤに転送される。そのためホストがEAP authenticatorレイヤを実装していない場合、パケットは破棄される。 pass-through peerの動作はこの仕様書では未定義でRADIUS、DameterのようなAAAプロトコルではサポートされない。 The forwarding model is illustrated in Figure 2. Forwading modelはFigure2のように表現される。 Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | |EAP | EAP | | | ! | | ! | |Peer | Auth.| EAP Auth. | | ! | |EAP ! peer| | | +-----------+ | |EAP !Auth.| | ! | | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! ! +-------- --------+ +--------- -------+ Figure 2 Pass-through Authenticator For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet. Auuthenticatorがpass-throughとして機能するセッションでは、バックエンド認証サーバから送信されたAccept/Rejectの通知のみに基いて認証結果を決定すること。 結果はAccept/Reject通知と一緒に送られたEAPパケットのコンテンツやカプセル化されたEAPパケットの欠如によって決定されてはいけない。 Aboba, et al. Standards Track [Page 13] RFC 3748 EAP June 2004 2.4. Peer-to-Peer Operation Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both ends of the link may act as authenticators and peers at the same time. In this case, it is necessary for both ends to implement EAP authenticator and peer layers. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality. EAPはpeer-to-peerプロトコルであるので、独立した認証は同時に実行できる(下位レイヤの機能に依存する。)。リンクの両端は同時にauthenticatorとpeerとして動作できる。その場合、両端はEAP authenticatorレイヤとEAP peerレイヤの実装が必要である。さらにpeerのEAPメソッドの実装はauthenticatorとpeerの両方の機能をサポートする必要がある。 Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols, and link layers may not support this. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer- to-peer operation with such a method would need to be provisioned with both types of credentials. EAPはpeer-to-peerをサポートするが、EAPの実装では、メソッド、AAAプロトコル、linkレイヤをサポートしなくてもよい。EAPメソッドはpeerとauthenticarotで異なる認証をする非対称認証をサポートしてもよい。このようなメソッドでpeer-to-peer動作をするhostは認証情報を両方のタイプで準備する必要がある。 （EAP-TLSのようにクラサバ動作するもの） For example, EAP-TLS [RFC2716] is a client-server protocol in which distinct certificate profiles are typically utilized for the client and server. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers, support both peer and authenticator roles in the EAP-TLS implementation, and provision certificates appropriate for each role. 例えば、EAP-TLS[RFC2716]はクライアントとサーバで異なる証明書を用いるクライアント-サーバプロトコルである。これはEAP-TLSでpeer-to-peerの認証をサポートするhostは、EAP peer/authenticationのレイヤ両方を実装し、peer/authenticaitonとしてEAP-TLSをサポートし、各役割の証明書を用いる必要があることを意味する。 AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM- EAP] only support pass-through authenticator operation. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access- Request encapsulating an EAP-Request, Success, or Failure packet with an Access-Reject. There is therefore no support for pass-through peer operation. RADIUS/EAP[RFC3579]とDiameter EAP[DIAM-EAP]などのAAAプロトコルは pass-through authenticator の動作のみをサポートする。[RFC3579]Section 2.6.2で述べられるように、RADIUS serverはAccess-Requestにカプセル化したEAP-Request、Success、Access-RejectのFailureで応答する。 pass-through peer はサポートされない。 Even where a method is used which supports mutual authentication and result indications, several considerations may dictate that two EAP authentications (one in each direction) are required. These include メソッドは双方向用に2つのEAP認証を要求できる。 [1] Support for bi-directional session key derivation in the lower layer. Lower layers such as IEEE 802.11 may only support uni- directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 infrastructure mode, only the Access Point (AP) sends multicast/broadcast traffic. In IEEE 802.11 ad hoc mode, where either peer may send multicast/broadcast traffic, two uni-directional group-key exchanges are required. Due to limitations of the design, this also implies the need for unicast key derivations and EAP method exchanges to occur in each direction. 下位レイヤでの双方向のセッションキーのサポート。IEEE 802.11等の下位レイヤは単方向のセッションキーと転送をサポートする。IEEE802.11インフラストラクチャモードではAccess Point(AP)はmulticast/broadcastしか送信できないため、例えば[IEEE802.11i]で定義されたgroup-key handshakeは単方向である。アドホックモードではpeerの両方がmulticast/broadcastを送信できるため、両方向のgroup-key交換ができる。 [2] Support for tie-breaking in the lower layer. Lower layers such as IEEE 802.11 ad hoc do not support tie breaking wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur. [3] Peer policy satisfaction. EAP methods may support result indications, enabling the peer to indicate to the EAP server within the method that it successfully authenticated the EAP server, as well as for the server to indicate that it has authenticated the peer. However, a pass-through authenticator will not be aware that the peer has accepted the credentials offered by the EAP server, unless this information is provided to the authenticator via the AAA protocol. The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated the server. Peer policy satisfaction EAPメソッドはEAPサーバだけでなく、EAP peerにも認証結果を通知する。ただし、AAAプロトコルを経由してauthenticatorに提供されない場合、 pass-through の認証システムではpeerがEAPサーバによって提供される認証情報を認識できない。 atuthenticatorが、peerがサーバを認証したことの確認は、Acceptパケット内のkey attributeの受信により確認する。 However, it is possible that the EAP peer s access policy was not satisfied during the initial EAP exchange, even though mutual authentication occurred. For example, the EAP authenticator may not have demonstrated authorization to act in both peer and authenticator roles. As a result, the peer may require an additional authentication in the reverse direction, even if the peer provided an indication that the EAP server had successfully authenticated to it. EAP peerのアクセスポリシーは相互認証中にInitial EAP認証中に許可されない可能性がある。例えば、EAP authenticatorはpeerとauthenticatorの両方で動作する権限を持っていない可能性がある。その場合、peeは、peerがEAPサーバから認証を受けた後、逆方向の追加の認証を要求することができる。 4. EAP Packet Format A summary of the EAP packet format is shown below. The fields are transmitted from left to right. EAPパケットの概要を以下に示す。 Fieldは左から右に送信される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code The Code field is one octet and identifies the Type of EAP packet. EAP Codes are assigned as follows Code fieldは1オクテットでEAPパケットのタイプを識別する。 EAP Codeは以下のように割り当てられる。 1 Request 2 Response 3 Success 4 Failure Since EAP only defines Codes 1-4, EAP packets with other codes MUST be silently discarded by both authenticators and peers. EAPはCode 1-4のみを定義するため、他のCodeのEAPパケットはauthenticatorとpeerの両方で破棄されること。 Aboba, et al. Standards Track [Page 20] RFC 3748 EAP June 2004 Identifier The Identifier field is one octet and aids in matching Responses with Requests. Identifier fieldは1オクテットでRequestに一致するResponseの確認に使う。 Length The Length field is two octets and indicates the length, in octets, of the EAP packet including the Code, Identifier, Length, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored upon reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded. Length filedは2オクテットで、オクテット単位でCode、Identifier, Length,and Data fieldsを含むEAPパケットの長さを示す。 Lengthフィールドの範囲外であるData Linkレイヤのパディングは受信側で無視されること。 受信オクテットよりもLengthに設定された値が大きい場合、メッセージは破棄されること。 Data The Data field is zero or more octets. The format of the Data field is determined by the Code field. Data fieldは0以上のオクテットである。Data fieldのフォーマットはCode fieldによって決まる。 4.1. Request and Response Description The Request packet (Code field set to 1) is sent by the authenticator to the peer. Each Request has a Type field which serves to indicate what is being requested. Additional Request packets MUST be sent until a valid Response packet is received, an optional retry counter expires, or a lower layer failure indication is received. Requestパケット（Code=1）はauthenticatorによりpeerへ送信される。 Requestは要求に関するTypeフィールドをもつ。 追加のRequestパケットは有効なResponseパケットを受信するか、リトライカウンタが超過するか、下位レイヤから失敗通知(Failure indication)を受信するまで送信すること。 （⇒認証終わるか、失敗するまでに送る必要がある） Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The content of the data field is dependent on the Request Type. The peer MUST send a Response packet in reply to a valid Request packet. Responses MUST only be sent in reply to a valid Request and never be retransmitted on a timer. 再送されるRequestは新しいRequestと区別するために同じIdentifier valueを送信すること。 Data fieldのコンテンツはRequest Typeに依存する。peerは有効なRequest パケットに対してResponseパケットを送信すること。Responseは有効なRequestに対する応答として送信され、タイマーで再送されることがないこと。 If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response without reprocessing the Request. Requests MUST be processed in the order that they are received, and MUST be processed to their completion before inspecting the next Request. PeerがすでにResponseを送信した有効な重複Requestを受信した場合、Requestを再処理することなく、もとのResponseを再送すること。 Requestは受信した順序に処理され、次のRequestをチェックする前に処理を完了すること。 A summary of the Request and Response packet format follows. The fields are transmitted from left to right. RequestとResponseのパケットフォーマットを下記に示す。フィールドは左から右に送信される。 Aboba, et al. Standards Track [Page 21] RFC 3748 EAP June 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Code 1 for Request 2 for Response Identifier The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field. Identifier filedは1オクテット。Responseを待っている間にタイムアウトして再送される場合はIdentifierは同じであること。再送ではない新しいRequestはIdentifier filedを変更すること。 The Identifier field of the Response MUST match that of the currently outstanding Request. An authenticator receiving a Response whose Identifier value does not match that of the currently outstanding Request MUST silently discard the Response. ResponseのIndeitifir fieldは現在未処理のRequestと一致すること。 Authenticatorは現在未処理のRequestと一致しないIdentifierをもつResponseを受信したらResponseを破棄すること。 In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within the conversation. One way to achieve this is to start the Identifier at an initial value and increment it for each new Request. Initializing the first Identifier with a random number rather than starting from zero is recommended, since it makes sequence attacks somewhat more difficult. 新しいRequestと再送との混同を避けるため、新しいRequestは前のRequestと異なる必要があるが、プロシージャで一意である必要はない。 実現方法の一つは新しいRequestのたびにIdentifierをインクリメントすることである。 最初のIdentifierは0ではなく乱数にした方がシーケンス攻撃が困難になるのでよい。 Since the Identifier space is unique to each session, authenticators are not restricted to only 256 simultaneous authentication conversations. Similarly, with re-authentication, an EAP conversation might continue over a long period of time, and is not limited to only 256 roundtrips. Identifierが有限だが、authenticatorの同時認証プロシージャが256に制限されることはない。 再認証はEAPプロシージャが長期間になるので往復が256に制限されることはない。 Implementation Note The authenticator is responsible for retransmitting Request messages. If the Request message is obtained from elsewhere (such as from a backend authentication server), then the authenticator will need to save a copy of the Request in order to accomplish this. The peer is responsible for detecting and handling duplicate Request messages before processing them in any way, including passing them on to an outside party. The authenticator is also responsible for discarding Response messages with a non-matching Identifier value before acting on them in any way, including passing them on to the backend authentication server for verification. Since the authenticator can retransmit before receiving a Response from the peer, the authenticator can receive multiple Responses, each with a matching Identifier. Until a new Request is received by the authenticator, the Identifier value is not updated, so that the authenticator forwards Responses to the backend authentication server, one at a time. AuthenticatorはRequestの再送を担当する。Requestがバックエンド認証サーバなど他の場所から取得された場合、authenticatorはRequestをコピーする必要がある。peerは処理前に重複したRequestメッセージを検出できること。 Authenticatorはバックエンド認証サーバーへの送信を含むRequestメッセージのIdentifierが予期しないものだった場合のメッセージ破棄をすること。AuthenticatorはpeerからResponseを受信する前に再送できるため、Identifierが同じ複数のResponseを受信する。 新たなRequestをauthenticatorが受信するまで、authenticatorはバックエンド認証サーバーに1つずつResponseを送信できるように、Identifierを変更しない。 Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Type-Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored upon reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded. Length filedは2オクテットでCode, Identifier, Length, Type, and Type-Dataを含むEAPパケットのlengthを示す。Lengthフィールドの範囲外であるData Linkレイヤのパディングは受信側で無視されること。受信オクテットよりもLengthに設定された値が大きい場合、メッセージは破棄されること。 Type The Type field is one octet. This field indicates the Type of Request or Response. A single Type MUST be specified for each EAP Request or Response. An initial specification of Types follows in Section 5 of this document. Type fieldは1オクテット。Request or ResponseのTypeを示す。各Request or Responseに一つのTypeが設定されること。 InitialのTypeはSection 5に示す。 The Type field of a Response MUST either match that of the Request, or correspond to a legacy or Expanded Nak (see Section 5.3) indicating that a Request Type is unacceptable to the peer. A peer MUST NOT send a Nak (legacy or expanded) in response to a Request, after an initial non-Nak Response has been sent. An EAP server receiving a Response not meeting these requirements MUST silently discard it. ResponseのTypeはRequestかRequest Typeがpeerに許可されなかったことを示すlegacy or Expanded Nak(Section 5.3)に対応している必要がある。 Initial non-Nak Responseが送信された後、peerはRequestの応答としてNak(legacy or expanded)を送信してはいけない。 EAPサーバはこれらの要求を満たさないResponseを受信したらそれを破棄すること。 Type-Data The Type-Data field varies with the Type of Request and the associated Response. Type-DataはRequestとResponseによって異なる。 4.2. Success and Failure The Success packet is sent by the authenticator to the peer after completion of an EAP authentication method (Type 4 or greater) to indicate that the peer has authenticated successfully to the authenticator. The authenticator MUST transmit an EAP packet with the Code field set to 3 (Success). If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests), then after unsuccessful completion of the EAP method in progress, the implementation MUST transmit an EAP packet with the Aboba, et al. Standards Track [Page 23] RFC 3748 EAP June 2004 Code field set to 4 (Failure). An authenticator MAY wish to issue multiple Requests before sending a Failure response in order to allow for human typing mistakes. Success and Failure packets MUST NOT contain additional data. Successパケットはpeerがauthenticatorに正常に認証したことを示すため、EAP認証(Type 4以上)が完了した後にauthenticatorからpeerに送信される。authenticatorは3(Success)をCode filedに設定したEAPパケットを送信すること。 authenticatorがpeerを認証できない(1つ以上のRequestを許容できない)場合、進行中のEAPメソッドが失敗した後に、実装は4(Failure)をCode filedにセットしたEAPパケットを送信すること。 authenticatorは人の入力ミスを許容するため、Failure応答する前に、複数回Requestしてもよい。SuccessとFailureは追加のデータを含んではいけない。 Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not explicitly permitted MUST silently discard it. By default, an EAP peer MUST silently discard a canned Success packet (a Success packet sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending a Success packet prior to conclusion of the EAP method conversation. 指定されｔメソッドの仕様が明示的にその時点でのメソッドを終了することを許可しない場合、Success and FailureのパケットはEAP authenticatorにより送信されていはいけない。そのような送信では明示的に許可されていないSuccess and Failureのパケットを受信したpeer EAPの実装はパケットを破棄すること。デフォルトではEAP peerは古いSuccessパケットを破棄すること(Successパケットは接続後に即座に送信されること。)。 これにより、不正なauthenticatorが以前のEAPメソッド用のSuccessパケットを送信し、認証をバイパスすることがなくなる。 Implementation Note Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. See also Section 3.4 for guidance on the processing of lower layer success and failure indications. 実装上の注意：Success、Failureはacknowledgeされないため、authenticatorにより再送されず、lostする可能性がある。peerはそのような状況を考慮する必要がある。下位レイヤの成功/失敗の処理についてはSection 3.4参照。 As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. EAP methods may implement result indications. After the authenticator sends a failure result indication to the peer, regardless of the response from the peer, it MUST subsequently send a Failure packet. After the authenticator sends a success result indication to the peer and receives a success result indication from the peer, it MUST subsequently send a Success packet. Section 2.1で述べたように、EAPでは一つだけEAP認証方式が許容される。EAPメソッドはResult indicationを実装してもよい。authenticatorがpeerにfailure resultを送信した後、peerからの応答に関わらず、その後にFailureパケットを送信すること。 authenticatorがpeerにsuccess result indicationを送信し、peerが受信した場合、その後にSuccessパケットを送信すること。 On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a failure result indication, or the peer decides that it does not want to continue the conversation, possibly after sending a failure result indication), the peer MUST terminate the conversation and indicate failure to the lower layer. The peer MUST silently discard Success packets and MAY silently discard Failure packets. As a result, loss of a Failure packet need not result in a timeout. Peerでメソッドが正常に終了しなかった（すなわちauthenticatorがfailure result indicationを送信したか、peerがfailure result indicationを送信し、プロシージャを継続しないことを決定した）場合、peerはプロシージャを終了し、下位レイヤにfailureを通知すること。 PeerはSuccessパケットを破棄すること。またFailureパケットも破棄してよい。その結果、Failureパケットの損失によりタイムアウトが発生することはない。 On the peer, after success result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully. Success result indicationが両側で交換された後、peerはFailureパケットを破棄すること。EAP Successは受信していないが、peerはEAP Successパケットを損失し、認証は成功したと判断する。（※ACKのような使い方） Aboba, et al. Standards Track [Page 24] RFC 3748 EAP June 2004 If the authenticator has not sent a result indication, and the peer is willing to continue the conversation, the peer waits for a Success or Failure packet once the method completes, and MUST NOT silently discard either of them. In the event that neither a Success nor Failure packet is received, the peer SHOULD terminate the conversation to avoid lengthy timeouts in case the lost packet was an EAP Failure. authenticatorがresult indicationを送信していなくて、peerがプロシージャを継続する場合、peerはメソッド完了後のSuccess or Failureを待ち、それらを破棄してはいけない。（Success or Failure待ちで） SuccessでもFailureでもないパケットを受信した場合、peerは長いタイムアウトを避けるためプロシージャを終了すること。 If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet. However, an authenticator MAY omit having the peer authenticate to it in situations where limited access is offered (e.g., guest access). In this case, the authenticator MUST send a Success packet. peerがauthenticatorに認証を思考し、それが失敗した場合、authenticatorはFailureパケットを送信すること。Successパケットでアクセス権を付与してはいけない。authenticatorは限定アクセス(例 guestアカウント)の場合、peer認証を省略してもよい。そのケースではauthenticatorはSuccessパケットを送信すること。 Where the peer authenticates successfully to the authenticator, but the authenticator does not send a result indication, the authenticator MAY deny access by sending a Failure packet where the peer is not currently authorized for network access. peerがauthenticatorに認証されたが、authenticatorがresult indicationを送信しない場合、authenticatorはFailureパケットを送信し、peerのアクセスを拒否してよい。 A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right. Success and Failureパケットフォーマットを下記に示す。fieldは左から右に送信される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 3 for Success 4 for Failure Identifier The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Identifier field of the Response packet that it is sent in response to. Identifier fieldはResponseとRequestを対応付ける1オクテットである。ResponseとRequestで一致すること。 Length 4 Aboba, et al. Standards Track [Page 25] RFC 3748 EAP June 2004 4.3. Retransmission Behavior Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. By default, where EAP is run over an unreliable lower layer, the EAP retransmission timer SHOULD be dynamically estimated. A maximum of 3-5 retransmissions is suggested. 認証プロセスはユーザの入力を伴うため、再送と認証タイムアウトを決定する際には注意が必要である。EAPが信頼性の低い下位レイヤで実行される場合、EAP再送タイマは動的に推定されること。最大で3～5回の再送が提案される。 When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. The peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request. 信頼性のある下位レイヤ（例：EAP over ISAKAMP/TCP）ではEAPレイヤで再送が発生しないように、authenticatorの再送タイマは無限大に設定すること。peerはRequestの無限待機を回避するためにタイムアウト時間を調整してよい。 Where the authentication process requires user input, the measured round trip times may be determined by user responsiveness rather than network characteristics, so that dynamic RTO estimation may not be helpful. Instead, the retransmission timer SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards (see Section 5.6) are involved. 認証プロセスがユーザの入力を必要とする場合、ラウンドトリップタイムは動的なRTO推定は有効でない場合があるため、ユーザの応答により決定してよい。再送タイマはToken Cards(Section 5.6参照)が関係する場合のように長いタイムアウトが必要な場合、ユーザが応答するのに十分な再送タイマを設定すること。 RTO Retransmission Time Out（再送タイムアウト） In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute). 適切なタイムアウト時間をEAP authenticatorに提供するため、バックエンド認証サーバによりauthenticatorに通知できる(RADIUSのSession-Timeout attributeなどによる)。 In order to dynamically estimate the EAP retransmission timer, the algorithms for the estimation of SRTT, RTTVAR, and RTO described in [RFC2988] are RECOMMENDED, including use of Karn s algorithm, with the following potential modifications 動的にEAP再送タイマを推定するために、SRTT、RTTVAR、RTOを推定するアルゴリズム[RFC2988]、下記のKarn s Algorithmが推奨される。 SRTT：RTTの平均(smooth) RTTVAR：RTTの分散(variance) [a] In order to avoid synchronization behaviors that can occur with fixed timers among distributed systems, the retransmission timer is calculated with a jitter by using the RTO value and randomly adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative calculations to create jitter MAY be used. These MUST be pseudo-random. For a discussion of pseudo-random number generation, see [RFC1750]. 固定タイマで発生する同期動作を回避するため、再送タイマはRTO値に-RTOmin/2とRTOmin/2の間の乱数を足してjitterを算出する。jitterの計算は別の式を使用してもよい。これは擬似乱数であること。擬似乱数生成の議論は[RFC1750]参照。 [b] When EAP is transported over a single link (as opposed to over the Internet), smaller values of RTOinitial, RTOmin, and RTOmax MAY be used. Recommended values are RTOinitial=1 second, RTOmin=200ms, and RTOmax=20 seconds. EAPが一つのリンク(Internetではない。LAN?)で転送される場合、RTOinitial、RTOmin、RTOmaxは小さい値を使用してよい。お勧めはRTOinitial=1 second, RTOmin=200m秒, and RTOmax=20秒 Aboba, et al. Standards Track [Page 26] RFC 3748 EAP June 2004 [c] When EAP is transported over a single link (as opposed to over the Internet), estimates MAY be done on a per-authenticator basis, rather than a per-session basis. This enables the retransmission estimate to make the most use of information on link-layer behavior. EAPが一つのリンク（Internetではない）で転送される場合、Session毎ではなくauthenticator毎に推定した方がよい。リンクレイヤの動作に関する情報を利用することで再送の推定を可能とする。 [d] An EAP implementation MAY clear SRTT and RTTVAR after backing off the timer multiple times, as it is likely that the current SRTT and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are cleared, they should be initialized with the next RTT sample taken as described in [RFC2988] equation 2.2. EAPの実装ではSRTTとRTTVARをクリアしてもよい。SRTTとRTTVARがクリアされると、SRTTとRTTVARは[RFC2988]の式2.2で次のRTTをサンプリングして初期化される。 5. Initial EAP Request/Response Types This section defines the initial set of EAP Types used in Request/ Response exchanges. More Types may be defined in future documents. The Type field is one octet and identifies the structure of an EAP Request or Response packet. The first 3 Types are considered special case Types. このSectionではRequest/Responseの交換に使用されるEAP Typeを定義する。他のTypeは別のドキュメントで定義されてもよい。 Type fieldは1オクテットでEAP Request/Responseのパケット構造を識別する。 最初の3つは特殊なケースのTypeとして考慮される。 The remaining Types define authentication exchanges. Nak (Type 3) or Expanded Nak (Type 254) are valid only for Response packets, they MUST NOT be sent in a Request. 残りのTypeは認証の交換を定義する。 Nak(Type 3) or Expanded Nak(Type 254)はResponseパケットのみで、Requestには使用しないこと。 All EAP implementations MUST support Types 1-4, which are defined in this document, and SHOULD support Type 254. Implementations MAY support other Types defined here or in future RFCs. EAPの実装はType 1-4をサポートすること。実装は他のTypeや他のRFCで定義されているTypeをサポートしてもよい。 1 Identity 2 Notification 3 Nak (Response only) 4 MD5-Challenge 5 One Time Password (OTP) 6 Generic Token Card (GTC) 254 Expanded Types 255 Experimental use EAP methods MAY support authentication based on shared secrets. If the shared secret is a passphrase entered by the user, implementations MAY support entering passphrases with non-ASCII characters. In this case, the input should be processed using an appropriate stringprep [RFC3454] profile, and encoded in octets using UTF-8 encoding [RFC2279]. A preliminary version of a possible stringprep profile is described in [SASLPREP]. EAPメソッドは共通鍵に基づく認証をサポートしてよい。共通鍵がユーザの入力したパスフレーズである場合、実装は非ASCII文字を含むパスフレーズの入力をサポートしてよい。その場合、入力は適切な文字列処理[RFC3454]とUTF-8エンコーディング[RFC2279]で処理されること。文字列処理は[SASLPREP]で説明される。 Aboba, et al. Standards Track [Page 27] RFC 3748 EAP June 2004 5.1. Identity Description The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there is an expectation of interaction with a user. A Response of Type 1 (Identity) SHOULD be sent in Response to a Request with a Type of 1 (Identity). Identity TypeはpeerのIDを照会するために使用される。一般的にauthenticatorはInitial Requestでこれを発行する。peerに入力を要求するためのオプションの表示可能メッセージが含まれてもよい。Type 1(Identity)のRequestに対してType 1(Identity)のResponseが送信されること。 Some EAP implementations piggy-back various options into the Identity Request after a NUL-character. By default, an EAP implementation SHOULD NOT assume that an Identity Request or Response can be larger than 1020 octets. EAPの実装は複数のオプションをIdentity Requestのnull文字の後にpiggy-backしてよい。 デフォルトのEAPの実装では、Identity Request/Responseは1020オクテットより大きくならないこと。（※Fragmentの考慮。Fragmentが保証される他の認証方式の場合だったらよい。） It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response. Identity Requests and Responses are sent in cleartext, so an attacker may snoop on the identity, or even modify or spoof identity exchanges. To address these threats, it is preferable for an EAP method to include an identity exchange that supports per-packet authentication, integrity and replay protection, and confidentiality. The Identity Response may not be the appropriate identity for the method; it may have been truncated or obfuscated so as to provide privacy, or it may have been decorated for routing purposes. Where the peer is configured to only accept authentication methods supporting protected identity exchanges, the peer MAY provide an abbreviated Identity Response (such as omitting the peer-name portion of the NAI [RFC2486]). For further discussion of identity protection, see Section 7.3. Identity ResponseはルーティングとEAPメソッドの選択に使用することを推奨する。EAPメソッドはIdentity Responseを必要としないように、EAPメソッドはIDを取得するためのメソッド固有のメカニズムを含む。Identity Request/Responseは平文で送信されるので、攻撃者はIDを盗聴したり、ID交換をなりすますことができる。これらの脅威に対抗するため、EAPメソッドはパケット毎の認証、完全性チェック、機密性を含むことが望ましい。Identity ResponseはメソッドのためのIDでなくてもよく、難読化されたり、切り詰められてもよい。Peerが保護されたID交換をサポートする認証方式のみ設定される場合、peerはNAIのpeer-name部を省略したようなIdentity Responseを提供してよい。 NAI(Network Access Identifier：nai = username / ( username @ realm )) Section 7.3でidentity protectionについて議論する。 Implementation Note The peer MAY obtain the Identity via user input. It is suggested that the authenticator retry the Identity Request in the case of an invalid Identity or authentication failure to allow for potential typos on the part of the user. It is suggested that the Identity Request be retried a minimum of 3 times before terminating the authentication. The Notification Request MAY be used to indicate an invalid authentication attempt prior to transmitting a new Identity Request (optionally, the failure MAY be indicated within the message of the new Identity Request itself). 実装上の注意：Peerはユーザの入力からIdentityを得る可能性がある。authenticatorはタイプミスによる認証失敗や不正IDの場合はIdentity Requestを再試行することが推奨される。Identiry Requestは認証が終了する前に最低でも3回再試行されることが推奨される。 Notification Requestは新しいIdentity Request送信の前に、無効になった認証を通知するために使用してよい。(必要ならば、認証失敗は新しいIdentity Requestで通知してもよい。) Aboba, et al. Standards Track [Page 28] RFC 3748 EAP June 2004 Type 1 Type-Data This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet. このfieldはUTF-8、ISO 10646文字のRequest中の印字可能なメッセージが含まれる。Requestがnullを含む場合、nullの前のfieldが表示される。Identityが不明な場合、Identity Response fieldはlengthを0にすること。Identity Response filedはnull終端してはいけない。 Type-Data fieldの長さは、Request/Response パケットのLength filedから導出される。 Security Claims (see Section 7.2) Auth. mechanism None Ciphersuite negotiation No Mutual authentication No Integrity protection No Replay protection No Confidentiality No Key derivation No Key strength N/A Dictionary attack prot. N/A Fast reconnect No Crypt. binding N/A Session independence N/A Fragmentation No Channel binding No 5.2. Notification Description The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request, prior to completion of an EAP authentication method. The peer MUST respond to a Notification Request with a Notification Response unless the EAP authentication method specification prohibits the use of Notification messages. In any case, a Nak Response MUST NOT be sent in response to a Notification Request. Note that the default maximum length of a Notification Request is 1020 octets. By default, this leaves at most 1015 octets for the human readable message. Notification Typeは必要に応じてpeerにauthenticatorから表示可能なメッセージを通知するために使用される。EAP認証メソッドの完了前の未完了のRequestが存在しない場合、authenticatorはいつでもpeerにNotification Requestを送信してよい。（※EAP認証メソッドの手続き中じゃなかったらってこと） EAP認証メソッドの仕様がNotificationメッセージの使用を禁止していなければ、peerはNotification ResponseでNotification Requestに応答すること。いずれのケースでもNotification Requestの応答にNak Responseを送信してはいけない。Notification Requestの最大長はデフォルトでは1020オクテットであることに注意すること。デフォルトでは、このとき表示可能なメッセージは1015オクテットとなる。 Aboba, et al. Standards Track [Page 29] RFC 3748 EAP June 2004 An EAP method MAY indicate within its specification that Notification messages must not be sent during that method. In this case, the peer MUST silently discard Notification Requests from the point where an initial Request for that Type is answered with a Response of the same Type. EAPメソッドはNotificationメッセージがメソッド中に送信しないように、仕様として示してもよい。その場合、peerはauthenticatorからのNotification Requestを破棄すること。 The peer SHOULD display this message to the user or log it if it cannot be displayed. The Notification Type is intended to provide an acknowledged notification of some imperative nature, but it is not an error indication, and therefore does not change the state of the peer. Examples include a password with an expiration time that is about to expire, an OTP sequence integer which is nearing 0, an authentication failure warning, etc. In most circumstances, Notification should not be required. peerはユーザにメッセージを表示するか、表示できない場合はログに記録すること。Notificatio Typeは通知を提供することを目的としているが、エラー通知ではないためpeerの状態は変化しない。例えば、OTPのシーケンス番号が0に近づく、パスワードの有効期限切れ、認証の失敗の警告等である。できる限り、Notificationは要求されないこと。 OTP：One Time Password：ワンタイムパスワード Type 2 Type-Data The Type-Data field in the Request contains a displayable message greater than zero octets in length, containing UTF-8 encoded ISO 10646 characters [RFC2279]. The length of the message is determined by the Length field of the Request packet. The message MUST NOT be null terminated. A Response MUST be sent in reply to the Request with a Type field of 2 (Notification). The Type-Data field of the Response is zero octets in length. The Response should be sent immediately (independent of how the message is displayed or logged). RequestのType-Data fieldはUTF-8、ISO 10646[RFC2279]の0オクテットより長い表示可能メッセージが含まれる。 メッセージ長はRequestパケットのLength filedによって決められる。このメッセージはnull終端してはいけない。Response(Type filed 2)をRequestの応答に送信すること。ResponseのType-Data filedは0オクテットであること。メッセージの表示やロギングとは無関係にResponseは即座に送信されること。 Security Claims (see Section 7.2) Auth. mechanism None Ciphersuite negotiation No Mutual authentication No Integrity protection No Replay protection No Confidentiality No Key derivation No Key strength N/A Dictionary attack prot. N/A Fast reconnect No Crypt. binding N/A Session independence N/A Fragmentation No Channel binding No Aboba, et al. Standards Track [Page 30] RFC 3748 EAP June 2004 5.3. Nak 5.3.1. Legacy Nak Description The legacy Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains one or more authentication Types desired by the Peer. Type zero (0) is used to indicate that the sender has no viable alternatives, and therefore the authenticator SHOULD NOT send another Request after receiving a Nak Response containing a zero value. legacy Nak TypeはResponseメッセージでのみ有効である。要求されたauthentication Typeが許容できないRequestに対する応答として送信される。Authentication Typeは4以上が設定される。Responseはpeerが要求する1つ以上のauthenticatio Typeが含まれている。Type 0は送信者(peer)が他の選択肢を持っていないことを示し、authenticatorは0のNak Responseを受信した後はRequestを送らないこと。 Since the legacy Nak Type is valid only in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method. legacy Nak TypeがResponseだけで有効であり、限られた機能を持っているため、EAPメソッド固有パラメータのネゴシエーションエラーやエラーメッセージのような汎用的なエラー通知としてしようしないこと。 Code 2 for Response. Identifier The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of a legacy Nak Response MUST match the Identifier field of the Request packet that it is sent in response to. Identifier fieldは1オクテットでRequestとResponseの照合するために使用される。 legacy Nak ResponseのIdentifier fieldは応答するRequestパケットのIdentifier filedと一致すること。 Length =6 Type 3 Type-Data Where a peer receives a Request for an unacceptable authentication Type (4-253,255), or a peer lacking support for Expanded Types receives a Request for Type 254, a Nak Response (Type 3) MUST be sent. The Type-Data field of the Nak Response (Type 3) MUST contain one or more octets indicating the desired authentication Type(s), one octet per Type, or the value zero (0) to indicate no proposed alternative. A peer supporting Expanded Types that Aboba, et al. Standards Track [Page 31] RFC 3748 EAP June 2004 receives a Request for an unacceptable authentication Type (4-253, 255) MAY include the value 254 in the Nak Response (Type 3) to indicate the desire for an Expanded authentication Type. If the authenticator can accommodate this preference, it will respond with an Expanded Type Request (Type 254). peerが許容できない authentication Type(4～253, 255)のRequestを受信した場合 or Expanded TypeをサポートしていないpeerがType 254のRequestを受信した場合、Nak Response(Type 3)が送信されること。Nak Response(Type 3)のType-Data filedには1オクテット以上の要求するauthentication Type(s)が含まれること。1Type毎に1オクテットとし、0は選択肢がないことを示す。許容できないauthenticaiton Type(4-253, 255)のRequestを受信したExpanded TypeをサポートするpeerはExpanded authentication Typeを示すため、Nak Response(Type 3)に254を設定してもよい。 Authenticatorが設定に対応可能ならば、Expanded Type Request(Type 254)を応答する。 Security Claims (see Section 7.2) Auth. mechanism None Ciphersuite negotiation No Mutual authentication No Integrity protection No Replay protection No Confidentiality No Key derivation No Key strength N/A Dictionary attack prot. N/A Fast reconnect No Crypt. binding N/A Session independence N/A Fragmentation No Channel binding No 5.3.2. Expanded Nak Description The Expanded Nak Type is valid only in Response messages. It MUST be sent only in reply to a Request of Type 254 (Expanded Type) where the authentication Type is unacceptable. The Expanded Nak Type uses the Expanded Type format itself, and the Response contains one or more authentication Types desired by the peer, all in Expanded Type format. Type zero (0) is used to indicate that the sender has no viable alternatives. The general format of the Expanded Type is described in Section 5.7. Expanded Nak TypeはResponseメッセージでのみ有効である。認証Typeが許容できないType 254(Expanded Type)のRequestの応答としてのみ送信すること。Expanded Nak TypeはExpanded Type formatを使用し、Responseはpeerが要求する1つ以上の認証TypeがすべてのExpanded Type formatに含まれる。Type 0は送信者(peer)が他の候補を持たない場合に使用される。Expanded TypeはSection 5.7で説明される。 Since the Expanded Nak Type is valid only in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method. Expanded Nak TypeがResponseだけで有効であり、限られた機能を持っているため、EAPメソッド固有パラメータのネゴシエーションエラーやエラーメッセージのような汎用的なエラー通知としてしようしないこと。 Code 2 for Response. Aboba, et al. Standards Track [Page 32] RFC 3748 EAP June 2004 Identifier The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of an Expanded Nak Response MUST match the Identifier field of the Request packet that it is sent in response to. Identifier fieldは1オクテットでRequestとResponseの照合するために使用される。 legacy Nak ResponseのIdentifier fieldは応答するRequestパケットのIdentifier filedと一致すること。 Length =20 Type 254 Vendor-Id 0 (IETF) Vendor-Type 3 (Nak) Vendor-Data The Expanded Nak Type is only sent when the Request contains an Expanded Type (254) as defined in Section 5.7. The Vendor-Data field of the Nak Response MUST contain one or more authentication Types (4 or greater), all in expanded format, 8 octets per Type, or the value zero (0), also in Expanded Type format, to indicate no proposed alternative. The desired authentication Types may include a mixture of Vendor-Specific and IETF Types. For example, an Expanded Nak Response indicating a preference for OTP (Type 5), and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as follows Section 5.7で定義されたExpanded Type(254)を含むRequestのときのみ、Expanded Nak Typeが送信される。 Nak ResponseのVendor-Data filedには1つ以上の認証Type(4以上)、Typeごとの8オクテットのすべてのexpanded formatを含むこと。または、候補がない場合、0を設定し通知する。 要求する認証Typeはベンダー固有とIETF Typeを合わせてもよい。 例えば下記のように、OTP(One Type Password Type 5)とMIT(Vendor-ID 20)を示すExpanded Nak Responseがある。 Aboba, et al. Standards Track [Page 33] RFC 3748 EAP June 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Identifier | Length=28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 (OTP) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 20 (MIT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An Expanded Nak Response indicating a no desired alternative would appear as follows 下記に他の候補のないExpanded Nak Responseを示す。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Identifier | Length=20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (No alternative) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Claims (see Section 7.2) Auth. mechanism None Ciphersuite negotiation No Mutual authentication No Integrity protection No Replay protection No Confidentiality No Key derivation No Key strength N/A Dictionary attack prot. N/A Fast reconnect No Crypt. binding N/A Aboba, et al. Standards Track [Page 34] RFC 3748 EAP June 2004 Session independence N/A Fragmentation No Channel binding No 5.4. MD5-Challenge Description The MD5-Challenge Type is analogous to the PPP CHAP protocol [RFC1994] (with MD5 as the specified algorithm). The Request contains a challenge message to the peer. A Response MUST be sent in reply to the Request. The Response MAY be either of Type 4 (MD5-Challenge), Nak (Type 3), or Expanded Nak (Type 254). The Nak reply indicates the peer s desired authentication Type(s). EAP peer and EAP server implementations MUST support the MD5- Challenge mechanism. An authenticator that supports only pass- through MUST allow communication with a backend authentication server that is capable of supporting MD5-Challenge, although the EAP authenticator implementation need not support MD5-Challenge itself. However, if the EAP authenticator can be configured to authenticate peers locally (e.g., not operate in pass-through), then the requirement for support of the MD5-Challenge mechanism applies. MD5-Challenge TypeはPPP CHAPプロトコル[RFC1994]と類似している。 Requestはpeerへの challenge メッセージを含む。ResponseはRequestの応答として送信すること。Responseは4 (MD5-Challenge), Nak (Type 3), or Expanded Nak (Type 254)のいずれかであってよい。Nak応答ではpeerが要求する認証Typeを示す。EAP peerとEAP serverはMD5-Challengeメカニズムをサポートすること。EAP authenticatorはMD5-Challnegeをサポートする必要はないが、その場合、authenticatorはMD5-Challengeをサポートしたバックエンド認証サーバとの通信とpass-throughをサポートすること。ただし、EAP authenticatorがローカル認証(pass-throughを使用しない認証)を設定できるる場合、MD5-Challengeをサポートすること。 Note that the use of the Identifier field in the MD5-Challenge Type is different from that described in [RFC1994]. EAP allows for retransmission of MD5-Challenge Request packets, while [RFC1994] states that both the Identifier and Challenge fields MUST change each time a Challenge (the CHAP equivalent of the MD5-Challenge Request packet) is sent. MD5-Challenge TypeのIdentifier filedは[RFC 1994]のものとは異なる。[RFC1994]ではChallenge filedとIdentifierはChallengeの送信(MD5-Challenge Requestと同等)毎に変更する必要があるが、EAPではMD5-Challenge Requestパケットの再送をしてもよい。 Note [RFC1994] treats the shared secret as an octet string, and does not specify how it is entered into the system (or if it is handled by the user at all). EAP MD5-Challenge implementations MAY support entering passphrases with non-ASCII characters. See Section 5 for instructions how the input should be processed and encoded into octets. [RFC1994]ではoctet stringとして共通鍵と扱い、システムに入力する方法を規定しない。 EAP MD5-Challengeの実装は、非ASCII文字をpassphraseとしないことをしてもよい。 Section 5でoctet stringにエンコードする方法を示す。 Type 4 Type-Data The contents of the Type-Data field is summarized below. For reference on the use of these fields, see the PPP Challenge Handshake Authentication Protocol [RFC1994]. Type-Data fieldを下記に示す。 これらのフィールドの使用方法は、PPP Challenge Handshake Authentication Protocol[RFC1994]を参照。 Aboba, et al. Standards Track [Page 35] RFC 3748 EAP June 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value-Size | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Claims (see Section 7.2) Auth. mechanism Password or pre-shared key. Ciphersuite negotiation No Mutual authentication No Integrity protection No Replay protection No Confidentiality No Key derivation No Key strength N/A Dictionary attack prot. No Fast reconnect No Crypt. binding N/A Session independence N/A Fragmentation No Channel binding No 5.5. One-Time Password (OTP) Description The One-Time Password system is defined in A One-Time Password System [RFC2289] and OTP Extended Responses [RFC2243]. The Request contains an OTP challenge in the format described in [RFC2289]. A Response MUST be sent in reply to the Request. The Response MUST be of Type 5 (OTP), Nak (Type 3), or Expanded Nak (Type 254). The Nak Response indicates the peer s desired authentication Type(s). The EAP OTP method is intended for use with the One-Time Password system only, and MUST NOT be used to provide support for cleartext passwords. One-Time Password systemは A One-Time Password System [RFC2289]および OTP Extended Responses [RFC2243]で定義される。Requestは[RFC2289]で定義されたOTP challengeを含む。ResponseはRequestの応答として送信されること。ResponseはType 5 (OTP), Nak (Type 3), or Expanded Nak (Type 254)であること。Nak Responseではpeerの要求する認証Typeを示す。EAP OTPメソッドはOne-Time Passwordシステムにのみ使用され、平文パスワードをサポートするシステムでは使用しないこと。 Type 5 Aboba, et al. Standards Track [Page 36] RFC 3748 EAP June 2004 Type-Data The Type-Data field contains the OTP challenge as a displayable message in the Request. In the Response, this field is used for the 6 words from the OTP dictionary [RFC2289]. The messages MUST NOT be null terminated. The length of the field is derived from the Length field of the Request/Reply packet. Type-Data filedはRequestでは表示可能なOTP challenge を含む。ResponsehaこのフィールドをOTP dictionary[RFC2289]として6 wordを使用する。このメッセージはnull終端してはいけない。このfiledの長さはRequest/ResponseパケットのLength filedから導出される。 Note [RFC2289] does not specify how the secret pass-phrase is entered by the user, or how the pass-phrase is converted into octets. EAP OTP implementations MAY support entering passphrases with non-ASCII characters. See Section 5 for instructions on how the input should be processed and encoded into octets. [RFC2289]では秘密pass-phraseをユーザが入力する方法、pass-phraseをoctetに変換する方法を規定していない。EAP OTPでは非ASCII文字を含むpass-phraseをサポートしてもよい。Section 5に入力をoctetにエンコードする方法を示す。 Security Claims (see Section 7.2) Auth. mechanism One-Time Password Ciphersuite negotiation No Mutual authentication No Integrity protection No Replay protection Yes Confidentiality No Key derivation No Key strength N/A Dictionary attack prot. No Fast reconnect No Crypt. binding N/A Session independence N/A Fragmentation No Channel binding No 5.6. Generic Token Card (GTC) Description The Generic Token Card Type is defined for use with various Token Card implementations which require user input. The Request contains a displayable message and the Response contains the Token Card information necessary for authentication. Typically, this would be information read by a user from the Token card device and entered as ASCII text. A Response MUST be sent in reply to the Request. The Response MUST be of Type 6 (GTC), Nak (Type 3), or Expanded Nak (Type 254). The Nak Response indicates the peer s desired authentication Type(s). The EAP GTC method is intended for use with the Token Cards supporting challenge/response Aboba, et al. Standards Track [Page 37] RFC 3748 EAP June 2004 authentication and MUST NOT be used to provide support for cleartext passwords in the absence of a protected tunnel with server authentication. Generic Token Card Typeはユーザの入力を必要とするToken Cardの実装で使用するために定義される。 Requestは表示可能メッセージを含み、Responseは認証に必要なToken Card情報を含む。 典型的にはToken Card deviceから読み取られASCII文字として入力される。Requestに対してResponseを送信すること。ResponseはType 6 (GTC), Nak (Type 3), or Expanded Nak (Type 254)であること。Nak Responseの場合、peerが要求する認証Typeを通知すること。 Token CardによるEAP GTCメソッドはchallenge/response認証をサポートし、サーバ認証にトンネルが存在しない場合に平文テキストを送信する場合は使用してはいけない。 Type 6 Type-Data The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by the Length field of the Request packet. The message MUST NOT be null terminated. A Response MUST be sent in reply to the Request with a Type field of 6 (Generic Token Card). The Response contains data from the Token Card required for authentication. The length of the data is determined by the Length field of the Response packet. RequestのType-Data filedは0以上の長さの表示可能なメッセージを含む。メッセージ長はRequestパケットのLength filedで決まる。メッセージはnull終端しないこと。6 (Generic Token Card)のRequestにはResponseを送信すること。Responseは認証に必要なToken Cardのデータが含まれる。データ長はResponseパケットのLength filedで決まる。 EAP GTC implementations MAY support entering a response with non- ASCII characters. See Section 5 for instructions how the input should be processed and encoded into octets. EAP GTCの実装は非ASCII文字で応答することをサポートしなくてもよい。Section 5に入力をoctetにエンコードする方法を示す。 Security Claims (see Section 7.2) Auth. mechanism Hardware token. Ciphersuite negotiation No Mutual authentication No Integrity protection No Replay protection No Confidentiality No Key derivation No Key strength N/A Dictionary attack prot. No Fast reconnect No Crypt. binding N/A Session independence N/A Fragmentation No Channel binding No 5.7. Expanded Types Description Since many of the existing uses of EAP are vendor-specific, the Expanded method Type is available to allow vendors to support their own Expanded Types not suitable for general usage. EAPの用途にはベンダー固有があるため、Expanded method Typeは独自のExpanded Typeをサポートできるように使用される。 Aboba, et al. Standards Track [Page 38] RFC 3748 EAP June 2004 The Expanded Type is also used to expand the global Method Type space beyond the original 255 values. A Vendor-Id of 0 maps the original 255 possible Types onto a space of 2^32-1 possible Types. (Type 0 is only used in a Nak Response to indicate no acceptable alternative). Expanded Typeは255以上にMethod Typeを拡張するために使用される。 An implementation that supports the Expanded attribute MUST treat EAP Types that are less than 256 equivalently, whether they appear as a single octet or as the 32-bit Vendor-Type within an Expanded Type where Vendor-Id is 0. Peers not equipped to interpret the Expanded Type MUST send a Nak as described in Section 5.3.1, and negotiate a more suitable authentication method. Expanded attributeをサポートする実装では、1オクテット or 0であるVendor-ID Expanded Typeの32bitのVendor-Typeとして示されるEAP Typeを256未満の場合と同等に扱うこと。 PeerがExpanded Typeをサポートしていない場合、Section 5.3.1に示すとおり、Nakを送信し、認証メソッドをネゴシエーションすること。 A summary of the Expanded Type format is shown below. The fields are transmitted from left to right. Expanded Type formatを下記に示す。filedは左から右に送信される。 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 | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 254 for Expanded Type Vendor-Id The Vendor-Id is 3 octets and represents the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as allocated by IANA. A Vendor-Id of zero is reserved for use by the IETF in providing an expanded global EAP Type space. Vendor-IDは3オクテットであり、IANAによって割り当てられたベンダーのSMI Network Management Private Enterprise Codeのネットワークバイトオーダーを示す。0のVendor-IDはIETFのために予約されている。 Vendor-Type The Vendor-Type field is four octets and represents the vendor- specific method Type. Vendor-Typeは4オクテットでベンダー固有のメソッドTypeを表す。 If the Vendor-Id is zero, the Vendor-Type field is an extension and superset of the existing namespace for EAP Types. The first 256 Types are reserved for compatibility with single-octet EAP Types that have already been assigned or may be assigned in the future. Thus, EAP Types from 0 through 255 are semantically identical, whether they appear as single octet EAP Types or as Aboba, et al. Standards Track [Page 39] RFC 3748 EAP June 2004 Vendor-Types when Vendor-Id is zero. There is one exception to this rule Expanded Nak and Legacy Nak packets share the same Type, but must be treated differently because they have a different format. Vendor-IDが0の場合、Vendor-Type fieldは既存のEAP Typeを拡張したものである。 256まではすでに割り当てられているか、将来のために予約されている。このため、0～255のEAP Typeは、1オクテットのEAP TypeとVendor-ID 0のときのVendor-Typeと同じである。ただし例外があり、Expanded NakとLegacy Nakパケットは同じTypeだが、異なるformatのため異なる処理をすること。 Vendor-Data The Vendor-Data field is defined by the vendor. Where a Vendor-Id of zero is present, the Vendor-Data field will be used for transporting the contents of EAP methods of Types defined by the IETF. Vendor-Dataはベンダーによって定義される。Vendor-IDが0の場合、Vendor-DataはIETF によって定義されるEAPメソッドのコンテンツを送信するために使用される。 5.8. Experimental Description The Experimental Type has no fixed format or content. It is intended for use when experimenting with new EAP Types. This Type is intended for experimental and testing purposes. No guarantee is made for interoperability between peers using this Type, as outlined in [RFC3692]. Experimental Typeは固定のフォーマットやコンテンツを持っていない。新しいEAP Typeを試すときに使用するものである。このタイプは試験を目的にしている。[RFC3692]に示されう保証はこのタイプを使用したpeer間の相互運用には適用されない。 Type 255 Type-Data Undefined Aboba, et al. Standards Track [Page 63] RFC 3748 EAP June 2004 Appendix A. Changes from RFC 2284 This section lists the major changes between [RFC2284] and this document. Minor changes, including style, grammar, spelling, and editorial changes are not mentioned here. このセクションでは[RFC2284]とこのドキュメントの主要な変更点を示す。文法やスペルなどの軽微な経脳は記載されない。 o The Terminology section (Section 1.2) has been expanded, defining more concepts and giving more exact definitions. 用語Section(Section 1.2)がコンセプトと定義により拡張されれた。 o The concepts of Mutual Authentication, Key Derivation, and Result Indications are introduced and discussed throughout the document where appropriate. Mutual Authentication(相互認証)、Key Derivation(鍵導出)、Result Indication(結果通知)のコンセプトがドキュメント全体に導入され、議論されている。 o In Section 2, it is explicitly specified that more than one exchange of Request and Response packets may occur as part of the EAP authentication exchange. How this may be used and how it may not be used is specified in detail in Section 2.1. Section 2で明示的にRequestとResponseの複数のやりとりがEAP認証で発生する可能性を規定した。 o Also in Section 2, some requirements have been made explicit for the authenticator when acting in pass-through mode. Section 2でpass-throughモードで動作する場合、authenticatorのための要件が明示的に示された。 o An EAP multiplexing model (Section 2.2) has been added to illustrate a typical implementation of EAP. There is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it. EAP多重化モデル(Section 2.2)がEAPの一般的な実装を示すために追加された。 実装がこのモデルに準拠している必要はない。 o As EAP is now in use with a variety of lower layers, not just PPP for which it was first designed, Section 3 on lower layer behavior has been added. EAPは最初に設計されたPPPだけでなく様々な低レイヤで使用される。Section 3で低レイヤの動作が追加された。 o In the description of the EAP Request and Response interaction (Section 4.1), both the behavior on receiving duplicate requests, and when packets should be silently discarded has been more exactly specified. The implementation notes in this section have been substantially expanded. RequestとResponseの動作の説明(Section 4.1)では、重複Request受信、パケットを破棄の動作が明確に仕様化された。実装の注意点が拡張された。 o In Section 4.2, it has been clarified that Success and Failure packets must not contain additional data, and the implementation note has been expanded. A subsection giving requirements on processing of success and failure packets has been added. Section 4.2ではSuccessパケットとFailureパケットが追加のデータを含んではいけないことが明記された。SuccessパケットとFailureパケットの要求事項が追加された。 o Section 5 on EAP Request/Response Types lists two new Type values the Expanded Type (Section 5.7), which is used to expand the Type value number space, and the Experimental Type. In the Expanded Type number space, the new Expanded Nak (Section 5.3.2) Type has been added. Clarifications have been made in the description of most of the existing Types. Security claims summaries have been added for authentication methods. Section 5のEAP Request/Response Typeのリストに2つのTypeが追加された。 Typeの値を拡張するために使用されるExpanded Type(Section 5.7)とExperimental Type。 Expanded Type number spaceでは、新しい Expanded Nak(Section 5.3.2) Typeが追加された。 既存の説明の明確化。認証方式のSecurity要求が追加された。 Aboba, et al. Standards Track [Page 64] RFC 3748 EAP June 2004 o In Sections 5, 5.1, and 5.2, a requirement has been added such that fields with displayable messages should contain UTF-8 encoded ISO 10646 characters. Section 5、5.1、5.2にfiledはUTF-8、ISO 10646文字の表示可能文字であるという要求事項が追加された。 o It is now required in Section 5.1 that if the Type-Data field of an Identity Request contains a NUL-character, only the part before the null is displayed. RFC 2284 prohibits the null termination of the Type-Data field of Identity messages. This rule has been relaxed for Identity Request messages and the Identity Request Type-Data field may now be null terminated. Section 5.1でIdentity RequestのType-Data filedがNULを含んでいる場合、nullの前の部分までが表示されることが要求される。 RFC2284ではIdentityメッセージのType-Data filedのnull終端を禁止している。 このルールはIdentity RequestメッセージとIdentity Request Type-Data filedで緩和されており、現在はnull終端できる。 o In Section 5.5, support for OTP Extended Responses [RFC2243] has been added to EAP OTP. Section 5.5では、OTP Extended Response[RFC2243]のサポートがEAP OTPに追加された。 o An IANA Considerations section (Section 6) has been added, giving registration policies for the numbering spaces defined for EAP. IANA Consideration section(Section 6)がEAPのために定義されたnumbering spaceの登録ポリシーのために追加された。 o The Security Considerations (Section 7) have been greatly expanded, giving a much more comprehensive coverage of possible threats and other security considerations. Security Consideration(Section 7)が大幅に拡張され、脅威とセキュリティに関して総合的にカバーされた。 o In Section 7.5, text has been added on method-specific behavior, providing guidance on how EAP method-specific integrity checks should be processed. Where possible, it is desirable for a method-specific MIC to be computed over the entire EAP packet, including the EAP layer header (Code, Identifier, Length) and EAP method layer header (Type, Type-Data). Section 7.5では、EAPメソッド固有の完全性チェックが実施されるかについての方針をメソッド固有の動作に追加された。 可能な場合、EAPレイヤヘッダー(Code、Identifier、Length)とEAPメソッドレイヤのヘッダー(Type、Type-Data)を含む全体のEAPパケットで計算されることがメソッド固有のMICに関して望ましい。 o In Section 7.14 the security risks involved in use of cleartext passwords with EAP are described. Section 7.14ではEAPの平文のパスワードの使用に関するセキュリティリスクについて説明される。 o In Section 7.15 text has been added relating to detection of rogue NAS behavior. Section 7.15では、不正なNASの動作の検知に関して追加された。 Aboba, et al. Standards Track [Page 66] RFC 3748 EAP June 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an AS IS basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http //www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Aboba, et al. Standards Track [Page 67]
https://w.atwiki.jp/selflearn/pages/53.html
TCPに関連するRFCのまとめ 開始日 2007年06月23日 最終更新日 2009年06月03日 はじめに ここでは、WindowsVistaのTCPで採用されているRFC情報をもとに、その１つ１つを読み、理解していきます。 注意 もともと個人利用を目的としてまとめているものなだけに、けっこう自分なりの理解で進めている部分があります。「意味分からないよ」とか「おかしいんじゃない？」とかいうのがあれば、コメントで質問してください（がんばって調べます）。 用語 訳文に出てくる各語に対応する原文と意味を以下に記します。 略語 正式名称 意味 更新履歴 2008/5/26 作成開始 2008/6/23 表紙ページ（このページのこと）を作成 Windows VistaでサポートしているTCP関連のRFC一覧 RFC番号のリンクは、IETFの当該RFCサイトに張られています。また、進捗欄でリンクが張られている場合、その調査(中)ページがあります。 注意：IPv6関連の記述はあえて除外してあります(*1)。 RFC番号 タイトル 概要 進捗 793 Transmission Control Protocol TCPのベースとなる動作について 未読 1323 TCP Extensions for High Performance 不明 未読 2581 TCP Congestion Control 輻輳制御について。Reno? 未読 2582 The NewReno Modification to TCP s Fast Recovery algorithm NewRenoについて(Obsolete) 未読 2883 An extension to the Selective Acknowledgement (SACK) option for TCP SACKオプションによる通信の効率化 未読 3042 Enhancing TCP s Loss Recovery using Limited Transmit 不明 未読 3168 The Addition of Explicit Congestion Notification (ECN) to IP 不明 未読 3517 A Conservative Selective Acknowledgment (SACK)-based loss recovery algorithm for TCP 不明 未読 3782 The NewReno modification to TCP s Fast Recovery algorithm NewRenoアルゴリズムのうち、SACK無効時における高速回復アルゴリズムの拡張。RFC2582の改訂版 調査中 4138 Forward RTO-Recovery (F-RTO) An algorithm for detecting spurious retransmission timeouts with TCP and SCTP 不明 未読 参考サイト （ - ）
https://w.atwiki.jp/code_matome/pages/30.html
http //tools.ietf.org/html/rfc4960 Page 70まで Network Working Group R. Stewart, Ed. Request for Comments 4960 September 2007 Obsoletes 2960, 3309 Category Standards Track Stream Control Transmission Protocol Stream Control Transmission Protocol Status of This Memo このメモの位置づけ This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. このドキュメントはインターネットコミュニティにインターネット標準の規定とプロトコルと改良のための提案と議論の要求をする。 標準化状態とプロトコル状態はSTD1の最新版を参照してください。 このメモの配布には制限がない。 Abstract 概要 This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. このドキュメントはRFC2960とRFC3309を廃止する。 このドキュメントはStream Control Transmission Protocol(SCTP)を記述する。 SCTPはIPネットワーク上で公衆無線網(PSTN)の音声メッセージを送信するために設計されているが、 より広い応用が可能。 SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users SCTPはIP等のコネクションレスパケット網上で動作する信頼性の高いプロトコルである。 SCTPはユーザーに下記のサービスを提供する。 -- acknowledged error-free non-duplicated transfer of user data, -- ユーザデータのエラー無し、重複無しの送信 -- data fragmentation to conform to discovered path MTU size, -- Path MTUサイズに適合するためのデータの分割(フラグメント) -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- 個々のユーザメッセージの到達順序のオプションを使用した 複数ストリーム内のユーザメッセージの順序送信 -- optional bundling of multiple user messages into a single SCTP packet, and -- 単一SCTPパケットに複数のユーザメッセージを任意にバンドルする -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. -- アソシエーションによるマルチホーミングのサポートによるネットワークレベルの障害耐性。 The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. SCTPの設計は輻輳制御に適切な振る舞いと、フラッディング、マスカレード攻撃への耐性が含まれる。 Stewart Standards Track [Page 1] RFC 4960 Stream Control Transmission Protocol September 2007 Table of Contents 1. Introduction ....................................................5 1.導入 1.1. Motivation .................................................5 1.1. モチベーション 1.2. Architectural View of SCTP .................................6 1.2. SCTPのアーキテクチャ観点 1.3. Key Terms ..................................................6 1.3. 用語 1.4. Abbreviations .............................................10 1.4. 略語 1.5. Functional View of SCTP ...................................10 1.5 SCTPの機能的観点 1.5.1. Association Startup and Takedown ...................11 1.5.1. AssociationのStartupとTakedown 1.5.2. Sequenced Delivery within Streams ..................12 1.5.2. ストリーム内の順序送信 1.5.3. User Data Fragmentation ............................12 1.5.3. ユーザデータの分割(フラグメント) 1.5.4. Acknowledgement and Congestion Avoidance ...........12 1.5.4. Acknowledgementと輻輳回避 1.5.5. Chunk Bundling .....................................13 1.5.5. チャンクバンドリング 1.5.6. Packet Validation ..................................13 1.5.6 パケット検証 1.5.7. Path Management ....................................13 1.5.7. パスマネジメント 1.6. Serial Number Arithmetic ..................................14 1.6 シリアルナンバーの計算 1.7. Changes from RFC 2960 .....................................15 1.7. RFC2960からの変更点 2. Conventions ....................................................15 2. ルール 3. SCTP Packet Format .............................................15 3. SCTPパケットフォーマット 3.1. SCTP Common Header Field Descriptions .....................16 3.1. SCTP共通ヘッダーフィールドの説明 3.2. Chunk Field Descriptions ..................................17 3.2. チャンクフィールドの説明 3.2.1. Optional/Variable-Length Parameter Format ..........19 3.2.1. オプション/可変長パラメータのフォーマット 3.2.2. Reporting of Unrecognized Parameters ...............21 3.2.2. 認められていないパラメータの報告 3.3. SCTP Chunk Definitions ....................................21 3.3. SCTPチャンク定義 3.3.1. Payload Data (DATA) (0) ............................22 3.3.1. ペイロードデータ (DATA) (0) 3.3.2. Initiation (INIT) (1) ..............................24 3.3.2 Initialtion (INIT) (1) 3.3.2.1. Optional/Variable-Length Parameters in INIT ........................27 3.3.2.1 INITのオプション/可変長パラメータ 3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........30 3.3.3. Initiation Acknowledgement (INIT ACK) (2) 3.3.3.1. Optional or Variable-Length Parameters ....33 3.3.3.1. オプション/可変長パラメータ 3.3.4. Selective Acknowledgement (SACK) (3) ...............34 3.3.4 Selective Acknowledgement (SACK) (3) 3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................38 3.3.5. Heartbeat Request (HEARTBEAT) (4) 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......39 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) 3.3.7. Abort Association (ABORT) (6) ......................40 3.3.7. Abort Association (ABORT) (6) 3.3.8. Shutdown Association (SHUTDOWN) (7) ................41 3.3.8. Shutdown Association (SHUTDOWN) (7) 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........41 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) 3.3.10. Operation Error (ERROR) (9) .......................42 3.3.10. Operation Error (ERROR) (9) 3.3.10.1. Invalid Stream Identifier (1) ............44 3.3.10.1 Invalid Stream Identifier (1) 3.3.10.2. Missing Mandatory Parameter (2) ..........44 3.3.10.2 Missing Mandatory Parameter (2) 3.3.10.3. Stale Cookie Error (3) ...................45 3.3.10.3. Stale Cokie Error (3) 3.3.10.4. Out of Resource (4) ......................45 3.3.10.4. Out of resource (4) 3.3.10.5. Unresolvable Address (5) .................46 3.3.10.5. Unresolvable Address (5) 3.3.10.6. Unrecognized Chunk Type (6) ..............46 3.3.10.6. Unrecognized Chunk Type (6) 3.3.10.7. Invalid Mandatory Parameter (7) ..........47 3.3.10.7. Invalid Mandatory Parameter (7) 3.3.10.8. Unrecognized Parameters (8) ..............47 3.3.10.8. Unrecognized Parameters (8) 3.3.10.9. No User Data (9) .........................48 3.3.10.9. No User Data (9) 3.3.10.10. Cookie Received While Shutting Down (10) ...............................48 3.3.10.10. Cookie Received While Shutting Down (10) Stewart Standards Track [Page 2] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.11. Restart of an Association with New Addresses (11) ......................49 3.3.10.11 Restart of an Association with New Addresses (11) 3.3.10.12. User-Initiated Abort (12) ...............49 3.3.10.12 User-Initiated Abort (12) 3.3.10.13. Protocol Violation (13) .................50 3.3.10.13 Protocol Violation (13) 3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................50 3.3.11. Cookie Echo (COOKIE ECHO) (11) 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........51 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........51 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) 4. SCTP Association State Diagram .................................52 4. SCTP Association状態遷移図 5. Association Initialization .....................................56 5. Association Initialization 5.1. Normal Establishment of an Association ....................56 5.1. Associationの通常の確立 5.1.1. Handle Stream Parameters ...........................58 5.1.1. Streamパラメータの処理 5.1.2. Handle Address Parameters ..........................58 5.1.2. Addressパラメータの処理 5.1.3. Generating State Cookie ............................61 5.1.3. State Cookieの生成 5.1.4. State Cookie Processing ............................62 5.1.4. State Cookieの処理 5.1.5. State Cookie Authentication ........................62 5.1.5. State Cookieの認証 5.1.6. An Example of Normal Association Establishment .....64 5.1.6. 通常のAssociation確立の例 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and ..........................................65 5.2. 重複、予期しないINIT、INIT ACK、COOKIE ECHOの処理 5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) .......................66 5.2.1. COOKIE-WAIT or COOKIE-ECHOED状態でのINIT受信 5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, .............................66 5.2.2. CLOSED、COOKIE-ECHOED以外の状態での予期しないINIT 5.2.3. Unexpected INIT ACK ................................67 5.2.3. 予期しないINIT ACK 5.2.4. Handle a COOKIE ECHO when a TCB Exists .............67 5.2.4. TCBが存在する場合のCOOKIE ECHOの処理 5.2.4.1. An Example of a Association Restart .......69 5.2.4.1 Association Restartの例 5.2.5. Handle Duplicate COOKIE-ACK. .......................71 5.2.5. COOKIE-ACK重複の処理 5.2.6. Handle Stale COOKIE Error ..........................71 5.2.6. COOKIE Error状態の処理 5.3. Other Initialization Issues ...............................72 5.3. 他のInitialization問題 5.3.1. Selection of Tag Value .............................72 5.3.1. Tag Valueの選択 5.4. Path Verification .........................................72 5.4. パス検証 6. User Data Transfer .............................................73 6. ユーザデータ送信 6.1. Transmission of DATA Chunks ...............................75 6.1. データチャンクの送信 6.2. Acknowledgement on Reception of DATA Chunks ...............78 6.2. データチャンク受信のAcknowledgement 6.2.1. Processing a Received SACK .........................81 6.2.1. SACK受信の処理 6.3. Management of Retransmission Timer ........................83 6.3. 再送タイマのマネジメント 6.3.1. RTO Calculation ....................................83 6.3.1. RTOの計算 6.3.2. Retransmission Timer Rules .........................85 6.3.2. 再送タイマのルール 6.3.3. Handle T3-rtx Expiration ...........................86 6.3.3. T3-rtx期限切れの処理 6.4. Multi-Homed SCTP Endpoints ................................87 6.4. Multi-Homed SCTPエンドポイント 6.4.1. Failover from an Inactive Destination Address ......88 6.4.1. 非アクティブな宛先アドレスからのFailover(障害迂回) 6.5. Stream Identifier and Stream Sequence Number ..............88 6.5. Stream Identifier and Stream Sequence Number 6.6. Ordered and Unordered Delivery ............................88 6.6. 順序送信と非順序送信 6.7. Report Gaps in Received DATA TSNs .........................89 6.7. 受信したDATA TSNのGaps報告 6.8. CRC32c Checksum Calculation ...............................90 6.8. CRC32チェックサムの計算 6.9. Fragmentation and Reassembly ..............................91 6.9. 分割と組み立て 6.10. Bundling .................................................92 6.10. バンドリング 7. Congestion Control .............................................93 7. 輻輳制御 7.1. SCTP Differences from TCP Congestion Control ..............94 7.1 TCP輻輳制御とSCTPの違い Stewart Standards Track [Page 3] RFC 4960 Stream Control Transmission Protocol September 2007 7.2. SCTP Slow-Start and Congestion Avoidance ..................95 7.2. SCTP Slow-Startと輻輳回避 7.2.1. Slow-Start .........................................96 7.2.1 Slow-Start 7.2.2. Congestion Avoidance ...............................97 7.2.2. 輻輳回避 7.2.3. Congestion Control .................................98 7.2.3. 輻輳制御 7.2.4. Fast Retransmit on Gap Reports .....................98 7.2.4. Gap ReportのFast Retransmit 7.3. Path MTU Discovery .......................................100 7.3. Path MTU Discovery 8. Fault Management ..............................................100 8. Fault Management 8.1. Endpoint Failure Detection ...............................100 8.1 エンドポイント障害検知 8.2. Path Failure Detection ...................................101 8.2. パス障害検知 8.3. Path Heartbeat ...........................................102 8.3. Path Heartbeat 8.4. Handle Out of the Blue Packets .........................104 8.4. Out of the Blue パケットの処理 8.5. Verification Tag .........................................105 8.5. Tagの検証 8.5.1. Exceptions in Verification Tag Rules ..............105 8.5.1. Tagルール検証の例外 9. Termination of Association ....................................106 9. Associationの終了 9.1. Abort of an Association ..................................107 9.1. AssociationのAbort 9.2. Shutdown of an Association ...............................107 9.2. AssociationのShutdown 10. Interface with Upper Layer ...................................110 10. 上位レイヤのInterface 10.1. ULP-to-SCTP .............................................110 10.1 上位レイヤからSCTP 10.2. SCTP-to-ULP .............................................120 10.2. SCTPから上位レイヤ 11. Security Considerations ......................................123 11. セキュリティの考慮 11.1. Security Objectives .....................................123 11.1 セキュリティの目的 11.2. SCTP Responses to Potential Threats .....................124 11.2. 脆弱性へのSCTPの対応 11.2.1. Countering Insider Attacks .......................124 11.2.1 Inside攻撃への対応 11.2.2. Protecting against Data Corruption in the Network ..........................................124 11.2.2 ネットワーク内のデータ破損に対する保護 11.2.3. Protecting Confidentiality .......................124 11.2.3 機密性の保護 11.2.4. Protecting against Blind Denial-of-Service Attacks ........................125 11.2.4. DoS攻撃からの保護 11.2.4.1. Flooding ................................125 11.2.4.1. Flooding 11.2.4.2. Blind Masquerade ........................126 11.2.4.2. Blind Masquerade 11.2.4.3. Improper Monopolization of Services .....127 11.2.4.3. 不適切なサービス独占 11.3. SCTP Interactions with Firewalls ........................127 11.3. ファイヤーウォールとSCTPの作用 11.4. Protection of Non-SCTP-Capable Hosts ....................128 11.4. SCTP非対応ホストの保護 12. Network Management Considerations ............................128 12. ネットワークマネジメントの考慮 13. Recommended Transmission Control Block (TCB) Parameters ......129 13. 推奨されるTCBパラメータ 13.1. Parameters Necessary for the SCTP Instance ..............129 13.1. SCTPインスタンスに必要なパラメータ 13.2. Parameters Necessary per Association (i.e., the TCB) ....129 13.2. Association(すなわちTCB)毎に必要なパラメータ 13.3. Per Transport Address Data ..............................131 13.3. Transport Adddress Data毎に 13.4. General Parameters Needed ...............................132 13.4. 一般的に必要なパラメータ 14. IANA Considerations ..........................................132 14. IANAの考慮 14.1. IETF-defined Chunk Extension ............................132 14.1 IETF定義のチャンク拡張 14.2. IETF-Defined Chunk Parameter Extension ..................133 14.2 IETF定義のチャンクパラメータ拡張 14.3. IETF-Defined Additional Error Causes ....................133 14.3. IETF定義の追加エラーCause 14.4. Payload Protocol Identifiers ............................134 14.4 ペイロードプロトコルの識別子 14.5. Port Numbers Registry ...................................134 14.5. ポート番号登録簿 15. Suggested SCTP Protocol Parameter Values .....................136 15. 提案されるSCTPプロトコルパラメータ値 16. Acknowledgements .............................................137 16. Acknowledgements Appendix A. Explicit Congestion Notification .....................139 Appendix A. 詳細な輻輳通知 Stewart Standards Track [Page 4] RFC 4960 Stream Control Transmission Protocol September 2007 Appendix B. CRC32c Checksum Calculation ..........................140 Appendix A. CRC32チェックサムの計算 Appendix C. ICMP Handling ........................................142 Appendix C. ICMPの処理 References .......................................................149 参照 Normative References ..........................................149 Normative References Informative References ........................................150 Informative References 1. Introduction This section explains the reasoning behind the development of the Stream Control Transmission Protocol (SCTP), the services it offers, and the basic concepts needed to understand the detailed description of the protocol. このセクションではStream Control Transmission Protocol (SCTP)が提供するサービス、 プロトコルの詳細を理解するために必要な基本的なコンセプトの背景を説明する。 This document obsoletes [RFC2960] and [RFC3309]. このドキュメントはRFC2960、RFC3309を廃止する。 1.1. Motivation 1.1. モチベーション TCP [RFC0793] has performed immense service as the primary means of reliable data transfer in IP networks. However, an increasing number of recent applications have found TCP too limiting, and have incorporated their own reliable data transfer protocol on top of UDP [RFC0768]. The limitations that users have wished to bypass include the following TCP [RFC0793]はIPネットワーク内の高信頼性のデータ転送の方法としてサービスを提供している。 しかし、最近のアプリケーションではTCPの多くの制限から、UDP[RFC0768]上に独自の信頼性のあるデータ転送プロトコルが組み込まれている。 ユーザが回避を望む制限には下記のものがある。 -- TCP provides both reliable data transfer and strict order-of- transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking offered by TCP causes unnecessary delay. -- TCPは信頼性のデータ転送と厳密なデータの順序伝送を提供する。 データお順序性が必要なアプリケーションもあるが、一部のアプリケーションでは順序制御のない信頼性のデータ転送を必要とする。 これらの両方のケースでは、TCPが提供するhead-of-line blocking(head-of-the-lineブロッキング（キュー送信によるブロッキング)が原因となる。 -- The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time. -- TCPのストリーム指向は不便である。 アプリケーションはプッシュ機構を使用する、メッセージを送信する。 -- The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts. -- TCPの限られた範囲では、multi-homed hostsを使用した高信頼データ転送の提供が複雑になる。 -- TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks. --TCPはSYN攻撃のようなDoS攻撃に比較的脆弱である。 Transport of PSTN signaling across the IP network is an application for which all of these limitations of TCP are relevant. While this application directly motivated the development of SCTP, other applications may find SCTP a good match to their requirements. IPネットワーク上のPSTNシグナリングの転送は、TCPのこれらの制限が関係しているアプリケーションである。 これがSCTPの開発の動機であり、いくつかのアプリケーションの要件にもマッチする。 Stewart Standards Track [Page 5] RFC 4960 Stream Control Transmission Protocol September 2007 1.2. Architectural View of SCTP 1.2. SCTPのアーキテクチャ観点 SCTP is viewed as a layer between the SCTP user application ( SCTP user for short) and a connectionless packet network service such as IP. The remainder of this document assumes SCTP runs on top of IP. The basic service offered by SCTP is the reliable transfer of user messages between peer SCTP users. It performs this service within the context of an association between two SCTP endpoints. Section 10 of this document sketches the API that should exist at the boundary between the SCTP and the SCTP user layers. SCTPはSCTPユーザアプリケーション(略：SCTP user)とIPのようなコネクションレスのパケットサービスとみなされる。 SCTPはIP上で動作することを前提とする。 SCTPが提供する基本機能はSCTPユーザ間のユーザメッセージの信頼性転送である。 SCTPは2つのSCTPエンドポイント間のassociationのコンテキスト内でこのサービスを実行する。 Section 10ではSCTPとSCTPユーザレイヤ間の境界に存在するAPIを説明する。 SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint (Section 1.3) to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations that may be generated from each endpoint s lists. SCTPはコネクション指向の性質があるが、SCTP associationはTCPコネクションより広範なコンセプトである。 SCTPは各SCTPエンドポイントにSCTPパケット転送するための転送アドレスのリスト(すなわちSCTPポートと組み合わせられた複数のIPアドレス)を他のエンドポイントに提供するための方法を提供する。 Associationは各エンドポイントのリストから生成されるsource/destinationのすべての組み合わせの転送に作成される。 _____________ _____________ | SCTP User | | SCTP User | | Application | | Application | |-------------| |-------------| | SCTP | | SCTP | | Transport | | Transport | | Service | | Service | |-------------| |-------------| | |One or more ---- One or more| | | IP Network |IP address \/ IP address| IP Network | | Service |appearances /\ appearances| Service | |_____________| ---- |_____________| SCTP Node A | -------- Network transport ------- | SCTP Node B Figure 1 An SCTP Association 1.3. Key Terms 1.3. 用語 Some of the language used to describe SCTP has been introduced in the previous sections. This section provides a consolidated list of the key terms and their definitions. SCTPを説明するために使用される用語は前の章で導入された。 この章では用語と定義を提供する。 o Active destination transport address A transport address on a peer endpoint that a transmitting endpoint considers available for receiving user messages. o Active destination transport address： 送信側エンドポイントがユーザデータを受信可能と判断しているエンドポイント間のトランスポートアドレス。 Stewart Standards Track [Page 6] RFC 4960 Stream Control Transmission Protocol September 2007 o Bundling An optional multiplexing operation, whereby more than one user message may be carried in the same SCTP packet. Each user message occupies its own DATA chunk. o Bundling（バンドリング） 複数のユーザメッセージを同じSCTPパケットで転送することによる多重化処理。 各ユーザメッセージは各データチャンクで送信される。 o Chunk A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content. o Chunk（チャンク） チャンクヘッダとチャンクコンテンツで構成されるSCTPパケット内の情報の単位。 o Congestion window (cwnd) An SCTP variable that limits the data, in number of bytes, a sender can send to a particular destination transport address before receiving an acknowledgement. o Congestion window (cwnd)（輻輳ウィンドウ） データを制限するSCTPのパラメータ（byte数）で、送信側がacknowledgementを受信する前に宛先アドレスに送信できる。 o Cumulative TSN Ack Point The TSN of the last DATA chunk acknowledged via the Cumulative TSN Ack field of a SACK. o Cumulative TSN Ack Point（累積TSN Ack Point） 最後のデータチャンクのTSNはSACKの累積TSN AckフィールドでAckされる。 o Idle destination address An address that has not had user messages sent to it within some length of time, normally the HEARTBEAT interval or greater. o Idle destination address ユーザメッセージをHEARTBEATかそれ以上の時間に受信できなかったアドレス。 o Inactive destination transport address An address that is considered inactive due to errors and unavailable to transport user messages. o Inactive destination transport address エラーによりinactiveと判断され、ユーザメッセージの転送に使用できないアドレス。 o Message = user message Data submitted to SCTP by the Upper Layer Protocol (ULP). o Message = user message 上位レイヤ(ULP)からSCTPに送信されるデータ。 o Message Authentication Code (MAC) An integrity check mechanism based on cryptographic hash functions using a secret key. Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties. In SCTP, it is used by an endpoint to validate the State Cookie information that is returned from the peer in the COOKIE ECHO chunk. The term MAC has different meanings in different contexts. SCTP uses this term with the same meaning as in [RFC2104]. o Message Authentication Code (MAC) 秘密鍵を用いたハッシュ関数に基づく、Integrityチェックのメカニズム。 通常、MACは秘密鍵を共有する2者間で送信された情報の検証のために使用される。 SCTPでは、COOKIE ECHOチャンクでピアから返信されたState Cookie情報を検証するためにエンドポイントで使用される。 o Network Byte Order Most significant byte first, a.k.a., big endian. o Network Byte Order（ネットワークバイトオーダー） 最上位byteが最初。別名ビッグエンディアン。 o Ordered Message A user message that is delivered in order with respect to all previous user messages sent within the stream on which the message was sent. o Ordered Message（順序制御されたメッセージ） メッセージが送信されたストリーム内で順序通りに転送されたユーザメッセージ。 o Outstanding TSN (at an SCTP endpoint) A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement. o Outstanding TSN (at an SCTP endpoint)（SCTPエンドポイントの未処理のTSN） エンドポイントにより送信されたが、acknowledgementを受信していないTSNおよび関連するデータチャンク。 Stewart Standards Track [Page 7] RFC 4960 Stream Control Transmission Protocol September 2007 o Path The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths. o Path SCTPエンドポイント間の特定の宛先トランスポートアドレスへのSCTPエンドポイントが送信したSCTPパケットが通るルート。 異なる宛先トランスポートアドレスに送信することは、必ずしもパスを分けることを必要としない。 o Primary Path The primary path is the destination and source address that will be put into a packet outbound to the peer endpoint by default. The definition includes the source address since an implementation MAY wish to specify both destination and source address to better control the return path taken by reply chunks and on which interface the packet is transmitted when the data sender is multi-homed. o Primary Path Primary pathはエンドポイント間の送信にデフォルトで使用される宛先と送信元のアドレス。 定義は送信元アドレスと宛先アドレスを含んでいる、それは、実装ではマルチホーム送信のときにパケットを送信する送信元・宛先の両方のアドレスを指定するため。。 o Receiver Window (rwnd) An SCTP variable a data sender uses to store the most recently calculated receiver window of its peer, in number of bytes. This gives the sender an indication of the space available in the receiver s inbound buffer. o Receiver Window (rwnd) SCTP変数でデータ送信側がエンドポイント間の最新の受信ウィンドウを保持するために使用するバイト数。 送信者に受信者の受信バッファの使用可能な領域の値を示す。 o SCTP association A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time. o SCTP association SCTPエンドポイント間のプロトコルの関係。 2つのSCTPエンドポイントとVerification Tag、TSNなどのプロトコル状態情報から構成される。 Associationはassociationのエンドポイントのトランスポートアドレスを使って一意に識別できる。 2つのSCTPエンドポイントある時点でその間に複数のSCTP associationを持ってはいけない。 o SCTP endpoint The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint. o SCTP endpoint SCTPパケットの論理的な送信者/受信者。 マルチホームホストでは、SCTPエンドポイントは、送信元トランスポートアドレスと宛先トランスポートアドレスの組である。 SCTPエンドポイントで使用されるトランスポートアドレスは同じポート番号を使用する必要があるが、複数のIPアドレスを使用することができる。 SCTPに使用されるトランスポートアドレスは別のSCTPエンドポイントで使用することはできない。 つまり、トランスポートアドレスはSCTPエンドポイントで一意である。 o SCTP packet (or packet) The unit of data delivery across the interface between SCTP and the connectionless packet network (e.g., IP). An SCTP packet includes the common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP DATA chunks. o SCTP packet (or packet) SCTPとコネクションレスパケット網(例 IP)間のインタフェース間のデータ送信ユニット。 SCTPパケットはSCTPヘッダを含み、場合によりSCTP制御チャンク、SCTPデータチャンク（カプセル化ユーザデータを含む）も含まれる。 o SCTP user application (SCTP user) The logical higher-layer application entity which uses the services of SCTP, also called the Upper-Layer Protocol (ULP). o SCTP user application (SCTP user) SCTPを使用する論理的に上位のアプリケーション。Upper-Layer Protocol(ULP)とも呼ばれる。 Stewart Standards Track [Page 8] RFC 4960 Stream Control Transmission Protocol September 2007 o Slow-Start Threshold (ssthresh) An SCTP variable. This is the threshold that the endpoint will use to determine whether to perform slow start or congestion avoidance on a particular destination transport address. Ssthresh is in number of bytes. o Slow-Start Threshold (ssthresh) SCTP変数。エンドポイントが特定の宛先トランスポートアドレスにスロースタートや輻輳回避を実行するかを決定するための閾値。ssthreshはバイト数。 o Stream A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. o Stream 2つのSCTPエンドポイント間で確立される一方向の論理チャネルで、すべてのユーザメッセージが順序送信（非順序送信のServiceは除く）により送信される。 Note The relationship between stream numbers in opposite directions is strictly a matter of how the applications use them. It is the responsibility of the SCTP user to create and manage these correlations if they are so desired. 対向のストリームとの関連はアプリケーションが管理する。 o Stream Sequence Number A 16-bit sequence number used internally by SCTP to ensure sequenced delivery of the user messages within a given stream. One Stream Sequence Number is attached to each user message. o Stream Sequence Number ストリーム内のユーザメッセージの順序送信を保証するため、SCTPが使用する16ビットのシーケンス番号。 Stream Sequence Numberは各ユーザメッセージに付与される。 o Tie-Tags Two 32-bit random numbers that together make a 64-bit nonce. These tags are used within a State Cookie and TCB so that a newly restarting association can be linked to the original association within the endpoint that did not restart and yet not reveal the true Verification Tags of an existing association. o Tie-Tags 64bitのnonceを作る32bitの乱数。 タグは、associationにリンクできるようにState CookieとTCBで使用される。 o Transmission Control Block (TCB) An internal data structure created by an SCTP endpoint for each of its existing SCTP associations to other SCTP endpoints. TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association. o Transmission Control Block (TCB) 他のSCTPエンドポイントへ各SCTP associationのためにSCTPエンドポイントによって作成された内部データ構造。 TCBはassociationを維持、管理するための状態情報と運用状態のすべてを含んでいる。 o Transmission Sequence Number (TSN) A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries. o Transmission Sequence Number (TSN) SCTPが内部的に使用する32ビットのシーケンス番号。 TSNは受信の確認と重複受信検出を受信側SCTPエンドポイントが可能なようにユーザデータを含むチャンクに付与される。 o Transport address A transport address is traditionally defined by a network-layer address, a transport-layer protocol, and a transport-layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the transport protocol). o Transport address ネットワークレイヤアドレス（ネットワーク層）とポート番号（トランスポート層）。 o Unacknowledged TSN (at an SCTP endpoint) A TSN (and the associated DATA chunk) that has been received by the endpoint but for which an acknowledgement has not yet been sent. Or in the opposite case, for a packet that has been sent but no acknowledgement has been received. o Unacknowledged TSN (at an SCTP endpoint) エンドポイントで受信されたが、acknowledgementがまだ送信されていないTSN。 送信側ではパケットは送信されたが、acknowledgementがまだ受信されていない。 Stewart Standards Track [Page 9] RFC 4960 Stream Control Transmission Protocol September 2007 o Unordered Message Unordered messages are unordered with respect to any other message; this includes both other unordered messages as well as other ordered messages. An unordered message might be delivered prior to or later than ordered messages sent on the same stream. o Unordered Message（順序制御されていないメッセージ） 非順序送信の他のメッセージ（非順序送信メッセージ or 順序送信メッセージ）に関して非順序送信である。 非順序送信メッセージは同じストリームで送信された順序送信メッセージの前後に送信される。 o User message The unit of data delivery across the interface between SCTP and its user. o User message SCTPとユーザ間のインタフェースのデータ送信単位。 o Verification Tag A 32-bit unsigned integer that is randomly generated. The Verification Tag provides a key that allows a receiver to verify that the SCTP packet belongs to the current association and is not an old or stale packet from a previous association. o Verification Tag ランダムに生成される32bit非負整数。 Verification Tagは受信者のSCTPパケットが現在のassociationに属し、以前のassociationの古いパケットか確認するキーを提供する。 1.4. Abbreviations MAC - Message Authentication Code [RFC2104] RTO - Retransmission Timeout RTT - Round-Trip Time RTTVAR - Round-Trip Time Variation SCTP - Stream Control Transmission Protocol SRTT - Smoothed RTT TCB - Transmission Control Block TLV - Type-Length-Value coding format TSN - Transmission Sequence Number ULP - Upper-Layer Protocol 1.5. Functional View of SCTP 1.5 SCTPの機能的観点 The SCTP transport service can be decomposed into a number of functions. These are depicted in Figure 2 and explained in the remainder of this section. SCTPトランスポートサービスはいくつかの機能に分割できる。 これらは図2に示されるとおり、本章で説明される。 Stewart Standards Track [Page 10] RFC 4960 Stream Control Transmission Protocol September 2007 SCTP User Application SCTPユーザアプリケーション ----------------------------------------------------- __________________________________________ | || Sequenced Delivery | | Association || within Streams | | ||____________________| | Startup |Stream内の順序送信 | |______________________________ | and || User Data Fragmentation | | ||____________________________| | Takedown |ユーザデータのフラグメント | |______________________________ | || Acknowledgement | | || and | | || Congestion Avoidance | | ||____________________________| | |Acknowledgementと輻輳回避 | |_______________________________ | || Chunk Bundling | | ||_____________________________| | | | |___________________________________ | || Packet Validation | | ||_________________________________| | | | |_______________________________ | || Path Management | |__________________||______________________________| Figure 2 Functional View of the SCTP Transport Service Figure 2 SCTP Transport Serviceの機能観点 1.5.1. Association Startup and Takedown 1.5.1. Association Startup and Takedown An association is initiated by a request from the SCTP user (see the description of the ASSOCIATE (or SEND) primitive in Section 10). アソシエーションはSCTPユーザからの要求で初期化される。 （ASSOCIATE SENDのプリミティブはSection 10参照。） A cookie mechanism, similar to one described by Karn and Simpson in [RFC2522], is employed during the initialization to provide protection against synchronization attacks. The cookie mechanism uses a four-way handshake, the last two legs of which are allowed to carry user data for fast setup. The startup sequence is described in Section 5 of this document. RFC2522でKarn and Simpsonが述べたのと同じcookieメカニズムがsyn attackに対する保護を提供するため初期化中に使用される。 4-way handshakeのcookieメカニズムは、fast setupでユーザデータを送信する最後の2 legを使う。 startupシーケンスはSection 5で述べられる。 SCTP provides for graceful close (i.e., shutdown) of an active association on request from the SCTP user. See the description of the SHUTDOWN primitive in Section 10. SCTP also allows ungraceful close (i.e., abort), either on request from the user (ABORT Stewart Standards Track [Page 11] RFC 4960 Stream Control Transmission Protocol September 2007 primitive) or as a result of an error condition detected within the SCTP layer. Section 9 describes both the graceful and the ungraceful close procedures. SCTPはSCTPユーザからの要求によるアクティブなassociationのgraceful 切断(shutdown)を提供する。 SHUTDOWNプリミティブはSection 10参照。SCTPはユーザからの要求やSCTPレイヤで検出されたエラーによるungraceful 切断(abort)も許可する。 Section 9ではgraceful切断、ungraceful切断を説明する。 SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on each peer will stop accepting new data from its user and only deliver data in queue at the time of the graceful close (see Section 9). SCTPはTCPのようなhalf-open state（片方が切断されている間にもう片方がデータを送信する）をサポートしない。 エンドポイントの片方がshutdownすると、各peerのassociationは新しいデータの受け入れを停止し、graceful切断時にキューのデータのみを送信する。 1.5.2. Sequenced Delivery within Streams The term stream is used in SCTP to refer to a sequence of user messages that are to be delivered to the upper-layer protocol in order with respect to other messages within the same stream. This is in contrast to its usage in TCP, where it refers to a sequence of bytes (in this document, a byte is assumed to be 8 bits). streamは同じストリーム内の他のメッセージとの間で順番に上位レイヤに送信されるユーザメッセージのsequenceを表すためにSCTPで使われる。これはbyteのsequenceを表すTCPの使用方法とは対照的である。 The SCTP user can specify at association startup time the number of streams to be supported by the association. This number is negotiated with the remote end (see Section 5.1.1). User messages are associated with stream numbers (SEND, RECEIVE primitives, Section 10). Internally, SCTP assigns a Stream Sequence Number to each message passed to it by the SCTP user. On the receiving side, SCTP ensures that messages are delivered to the SCTP user in sequence within a given stream. However, while one stream may be blocked waiting for the next in-sequence user message, delivery from other streams may proceed. SCTPユーザはassociation startup時にサポートされるassociation数を指定できる。 その数はremote end（Section 5.1.1）でネゴシエーションされる。 ユーザメッセージはstream number(SEND、RECEIVEプリミティブ。Section 10)に関連付けられる。 内部的には、SCTPはSCTPユーザから渡された各メッセージにStream Sequence Numberを付与する。 受信側ではSCTPはメッセージが指定されたstream内のsequenceのSCTPユーザに送信されることを保証する。 streamが次のsequence内のユーザメッセージ待ちのためブロック中、別のstreamの送信を進めてよい。 SCTP provides a mechanism for bypassing the sequenced delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received. SCTPはsequence deliveryのバイパスのためのメカニズムを提供する。 このメカニズムを使用して送信されたユーザメッセージは、受信したSCTPユーザにすぐに届けられる。 1.5.3. User Data Fragmentation When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. SCTPは下層に渡すSCTPパケットのパスMTUのを保証するためユーザメッセージをfragmentする。 受信ではfragmentはSCTPユーザに渡される前に元のメッセージにreassembleされる。 1.5.4. Acknowledgement and Congestion Avoidance SCTP assigns a Transmission Sequence Number (TSN) to each user data fragment or unfragmented message. The TSN is independent of any Stream Sequence Number assigned at the stream level. The receiving end acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separate from sequenced stream delivery. SCTPはTransmission Sequence Number(TSN)を各ユーザデータメッセージに付与する。 TSNはstream levelで割り当てられたStream Sequence Numberとは無関係である。 受信側はsequenceにgapがあってもすべてのTSNをacknowledgeする。 これにより、信頼性送信と順序送信の機能分割が保たれる。 Stewart Standards Track [Page 12] RFC 4960 Stream Control Transmission Protocol September 2007 The acknowledgement and congestion avoidance function is responsible for packet retransmission when timely acknowledgement has not been received. Packet retransmission is conditioned by congestion avoidance procedures similar to those used for TCP. See Section 6 and Section 7 for a detailed description of the protocol procedures associated with this function. acknowledgementと輻輳回避はacknowledgementが受信できない時のパケット再送を担う。 パケット再送はTCPで使用されるものと同様の輻輳回避プロシージャで調整される。 この機能に関連するプロシージャの詳細はSection6、7を参照。 1.5.5. Chunk Bundling As described in Section 3, the SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks. Each chunk may contain either user data or SCTP control information. The SCTP user has the option to request bundling of more than one user message into a single SCTP packet. The chunk bundling function of SCTP is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end. Section 3で説明したように、SCTP下位レイヤに送信されるSCTPパケットは1つ以上のチャンクと共通ヘッダで構成される。 各チャンクはSCTP control informationまたはユーザデータを含んでよい。 SCTPユーザは一つのSCTPパケットに複数のユーザデータのbundlingを要求するオプションをもつ。 チャンクbundling機能はSCTPパケットの分割と受信側での組み立てを担う。 During times of congestion, an SCTP implementation MAY still perform bundling even if the user has requested that SCTP not bundle. The user s disabling of bundling only affects SCTP implementations that may delay a small period of time before transmission (to attempt to encourage bundling). When the user layer disables bundling, this small delay is prohibited but not bundling that is performed during congestion or retransmission. 輻輳時、SCTPの実装ではユーザがSCTP bundleされないことを要求した場合でもbundlingを実行してもよい。 bundlingのユーザによる無効化は送信前のわずかな遅延に関するSCTPの実装に影響を与える（bundlingを試みるため）。 ユーザ層がbudlingを無効化したらわずかな遅延を抑えられるが、輻輳時や再送時にbundlingが実行されない。 1.5.6. Packet Validation A mandatory Verification Tag field and a 32-bit checksum field (see Appendix B for a description of the CRC32c checksum) are included in the SCTP common header. The Verification Tag value is chosen by each end of the association during association startup. Packets received without the expected Verification Tag value are discarded, as a protection against blind masquerade attacks and against stale SCTP packets from a previous association. The CRC32c checksum should be set by the sender of each SCTP packet to provide additional protection against data corruption in the network. The receiver of an SCTP packet with an invalid CRC32c checksum silently discards the packet. 必須のVerificaton Tagフィールドと32bitチェックサムフィールド(CRC32チェックサムの詳細はAppenix B参照)はSCTP common headerに含まれる。 Verification Tagの値はassociation startup時に各association間で選択される。 正しいVerification Tagなしで受信したパケットはblind masquerade attackと古いassociationパケットとして削除される。 CRC32チェックサムはネットワークによるデータ破損に対する保護を提供するため各SCTPパケットの送信者によって送信されること。 不正なCRCチェックサムのSCTPパケットの受信者はパケットを破棄する。 1.5.7. Path Management The sending SCTP user is able to manipulate the set of transport addresses used as destinations for SCTP packets through the primitives described in Section 10. The SCTP path management function chooses the destination transport address for each outgoing SCTP packet based on the SCTP user s instructions and the currently perceived reachability status of the eligible destination set. The path management function monitors reachability through heartbeats Stewart Standards Track [Page 13] RFC 4960 Stream Control Transmission Protocol September 2007 when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes. The path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup, and for reporting the transport addresses returned from the far end to the SCTP user. SCTP送信者はSection10で説明されるプリミティブによりSCTPパケットの宛先として使用されるtransport addressのsetを操作できる。 SCTP path managementはSCTPユーザの指定や宛先の到達性の状態に基づき、各送信SCTPパケットの宛先transport addressを選択する。 path managementはパケットトラヒックの情報が不足している場合、heartbeatで到達性を監視し、SCTPユーザに他のtransport addressの到達性の変化を通知する。 path managementはassociation startup時に相手へのlocal transport addressを通知と、相手のSCTPユーザから返されたtransport addressを報告を担い。 At association startup, a primary path is defined for each SCTP endpoint, and is used for normal sending of SCTP packets. association startup時、primary pathは各SCTP間に定義され、通常のSCTPパケット送信に使用される。 On the receiving end, the path management is responsible for verifying the existence of a valid SCTP association to which the inbound SCTP packet belongs before passing it for further processing. 受信側ではpath managementは受信したSCTPパケットをその後の処理に渡す前に正しいSCTP associationであるかの確認を担う。 Note Path Management and Packet Validation are done at the same time, so although described separately above, in reality they cannot be performed as separate items. Path ManagementとPacket Validationは同時には実行されるため、実際は上記に分けた説明が別々に実行されることはない。 1.6. Serial Number Arithmetic It is essential to remember that the actual Transmission Sequence Number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with Transmission Sequence Numbers must be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values. When referring to TSNs, the symbol = means less than or equal (modulo 2**32). Transmission Sequence Number空間は非常に大きいが有限（0～2^32-1）である。 有限であるため、Transmission Sequence Numberを扱う演算はmod 2^32をする必要がある。 この演算は0～2^32-1のサイクルとしてシーケンス番号を保持する。 moduloの計算には微妙な点があるため、値の比較には注意が必要である。 TSNを参照する際は = は以下(mod 2^32)を意味する。 Comparisons and arithmetic on TSNs in this document SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32. RFC1982で定義されるSERIAL_BITS = 32のSerial Number ArithmeticをTSNの比較や計算に使用すること。 An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more than 2**31 - 1 above the beginning TSN of its current send window. Doing so will cause problems in comparing TSNs. endpointは送信ウィンドウでTSN 2^31-1を超えるデータチャンクを送信しないこと。 そうするとTSNの計算で問題が生じる。 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN = 2*32 - 1 is TSN = 0. TSNは2^32-1に達すると重複する。 つまり次のTSN=0はTSN=2^32-1を送信した後に使用すること。 Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. All other arithmetic and comparisons in this document use normal arithmetic. RFC1982で定義されるSERIAL_BITS = 16のSerial Number ArithmeticをStream Sequence Numberを計算に使用すること。 このドキュメントのその他の計算、比較は通常の算術演算を使用する。 Stewart Standards Track [Page 14] RFC 4960 Stream Control Transmission Protocol September 2007 1.7. Changes from RFC 2960 SCTP was originally defined in [RFC2960], which this document obsoletes. Readers interested in the details of the various changes that this document incorporates are asked to consult [RFC4460]. SCTPはこのドキュメントが廃止したRFC2960で定義された。 このドキュメントに組み込まれた変更の詳細はRFC4460を参照。 2. Conventions The key words MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , MAY , and OPTIONAL in this document are to be interpreted as described in RFC 2119 [RFC2119]. このドキュメントのキーワード MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , MAY , and OPTIONAL はRFC2119で説明されるように解釈されること。 3. SCTP Packet Format An SCTP packet is composed of a common header and chunks. A chunk contains either control information or user data. SCTPパケットはcommon headerとチャンクで構成される。チャンクはcontrol informationまたはユーザデータを含む。 The SCTP packet format is shown below SCTPパケットフォーマットを下記に示す。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multiple chunks can be bundled into one SCTP packet up to the MTU size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks. These chunks MUST NOT be bundled with any other chunk in a packet. See Section 6.10 for more details on chunk bundling. INIT、INIT ACKとSHUTDOWN COMPLETEのチャンク除き、MTUサイズまで1つのSCTPパケットにチャンクをbundleできる。 これらのチャンクはパケット内の他のチャンクをbundleしないこと。 chunk bundlingの詳細はSection 6.10参照。 If a user data message doesn t fit into one SCTP packet it can be fragmented into multiple chunks using the procedure defined in Section 6.9. ユーザメッセージが1つのSCTPパケットに収まらない場合、Section 6.9のプロシージャを用いて複数のチャンクにfragmentできる。 All integer fields in an SCTP packet MUST be transmitted in network byte order, unless otherwise stated. SCTPパケット内のすべての整数フィールドはネットワークバイトオーダーで送信されること。 Stewart Standards Track [Page 15] RFC 4960 Stream Control Transmission Protocol September 2007 3.1. SCTP Common Header Field Descriptions SCTP Common Header Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | Destination Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verification Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Port Number 16 bits (unsigned integer) This is the SCTP sender s port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used. SCTP送信者のポート番号。 パケットのassociatinを識別するため送信元、宛先のIPアドレス、SCTP宛先ポートとともに受信者に使用される。 ポート番号0は使わないこと。 Destination Port Number 16 bits (unsigned integer) This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. The port number 0 MUST NOT be used. パケットの宛先ポート番号。 受信側が受信エンドポイント/アプリケーションにSCTPパケットをde-multiplexするために使用する。 ポート番号0は使わないこと。 Verification Tag 32 bits (unsigned integer) The receiver of this packet uses the Verification Tag to validate the sender of this SCTP packet. On transmit, the value of this Verification Tag MUST be set to the value of the Initiate Tag received from the peer endpoint during the association initialization, with the following exceptions パケットの受信者が送信者のSCTPパケットの検証のためにVerification Tagを使用する。 送信時、Verification Tagはassociation initialization中にピアエンドポイントから受信したInitiate Tagの値を設定すること。 下記の例外は除く。 - A packet containing an INIT chunk MUST have a zero Verification Tag. INITチャンクを含むパケットはzero Verification Tagであること。 - A packet containing a SHUTDOWN COMPLETE chunk with the T bit set MUST have the Verification Tag copied from the packet with the SHUTDOWN ACK chunk. T bitのSHUTDOWN COMPLETEチャンクを含むパケットは、SHUTDOWN ACKチャンクパケットからコピーされたVerification Tagであること。 - A packet containing an ABORT chunk may have the verification tag copied from the packet that caused the ABORT to be sent. For details see Section 8.4 and Section 8.5. ABORTチャンクを含むパケットは、ABORTが送信される原因となったパケットからコピーされたVerification Tagをコピーすること。 詳細はSection 8.4、8.5を参照。 Stewart Standards Track [Page 16] RFC 4960 Stream Control Transmission Protocol September 2007 An INIT chunk MUST be the only chunk in the SCTP packet carrying it. INITチャンクはこれを送信するSCTPの唯一のチャンクであること。 Checksum 32 bits (unsigned integer) This field contains the checksum of this SCTP packet. Its calculation is discussed in Section 6.8. SCTP uses the CRC32c algorithm as described in Appendix B for calculating the checksum. SCTPパケットのチェックサム。 計算方法はSection 6.8で述べる。 SCTPはCRC32アルゴリズム（Appendix B）を用いる。 3.2. Chunk Field Descriptions The figure below illustrates the field format for the chunks to be transmitted in the SCTP packet. Each chunk is formatted with a Chunk Type field, a chunk-specific Flag field, a Chunk Length field, and a Value field. SCTPパケットで送信されるチャンクフィールドフォーマットを示す。 各チャンクはChunk Type、Chunk-specific Flag、Chunk Length、Chunk Valueから構成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Type 8 bits (unsigned integer) This field identifies the type of information contained in the Chunk Value field. It takes a value from 0 to 254. The value of 255 is reserved for future use as an extension field. Chunk Value filedの情報の種類を識別する。 0～254をとる。255は今後の拡張のための予約。 The values of Chunk Types are defined as follows Chunk Typesは下記のように定義される。 ID Value Chunk Type ----- ---------- 0 - Payload Data (DATA) 1 - Initiation (INIT) 2 - Initiation Acknowledgement (INIT ACK) 3 - Selective Acknowledgement (SACK) 4 - Heartbeat Request (HEARTBEAT) 5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 6 - Abort (ABORT) 7 - Shutdown (SHUTDOWN) 8 - Shutdown Acknowledgement (SHUTDOWN ACK) 9 - Operation Error (ERROR) 10 - State Cookie (COOKIE ECHO) 11 - Cookie Acknowledgement (COOKIE ACK) Stewart Standards Track [Page 17] RFC 4960 Stream Control Transmission Protocol September 2007 12 - Reserved for Explicit Congestion Notification Echo (ECNE) 13 - Reserved for Congestion Window Reduced (CWR) 14 - Shutdown Complete (SHUTDOWN COMPLETE) 15 to 62 - available 63 - reserved for IETF-defined Chunk Extensions 64 to 126 - available 127 - reserved for IETF-defined Chunk Extensions 128 to 190 - available 191 - reserved for IETF-defined Chunk Extensions 192 to 254 - available 255 - reserved for IETF-defined Chunk Extensions Chunk Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Chunk Type. Chunk Typeは上位2bitがエンドポイントがChunk Typeを認識しない場合のアクションを指定するためにエンコードされる。 00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it. SCTPパケット処理を停止し、破棄する。Chunkを処理しない。 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized chunk in an Unrecognized Chunk Type . SCTPパケット処理を停止し、破棄する。Chunkを処理せず、Unrecognized Chunk TypeとしてChunkを報告する。 10 - Skip this chunk and continue processing. Chunkをスキップし、処理を継続する。 11 - Skip this chunk and continue processing, but report in an ERROR chunk using the Unrecognized Chunk Type cause of error. Chunkをスキップし、処理を継続する。Unrecognized Chunk Typeを使用したERROR Chunkで報告する。 Note The ECNE and CWR chunk types are reserved for future use of Explicit Congestion Notification (ECN); see Appendix A. ECNEとCWR chunkタイプはECN(明示的輻輳通知)で使用するためreserveされている。Appendix A参照。 Chunk Flags 8 bits The usage of these bits depends on the Chunk type as given by the Chunk Type field. Unless otherwise specified, they are set to 0 on transmit and are ignored on receipt. Chunk Type fieldで指定されたChunk typeに応じて使用される。 特に規定がない場合、送信側で0が設定され、受信側で無視される。 Chunk Length 16 bits (unsigned integer) This value represents the size of the chunk in bytes, including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding. Chunk Value、Chunk Length、Chunk Flags、Chunk Typesのバイト単位のchunkサイズを表す。 Chunk Value fieldが0の場合、Lengthは4に設定される。 Chunk Lengthはchunk paddingをカウントしない。 Stewart Standards Track [Page 18] RFC 4960 Stream Control Transmission Protocol September 2007 Chunks (including Type, Length, and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the chunk. However, it does include padding of any variable-length parameter except the last parameter in the chunk. The receiver MUST ignore the padding. Chunkは4バイトの倍数であるために、0バイトで送信者によってpaddingされる。 paddingは3バイトを超えてはいけない。 Chunk Lengthはchunkの終端のpaddingを含んでいない。 受信者はpaddingを無視すること。 Note A robust implementation should accept the chunk whether or not the final padding has been included in the Chunk Length. robustな実装ではpaddingがChunk Lengthに含まれているか確認する必要がある。 Chunk Value variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type. Chunk Value fieldはChunkで送信される情報が含まれている。 使用方法とフォーマットはChunk Typeに依存する。 The total length of a chunk (including Type, Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes, and this padding is not included in the Chunk Length field. The sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. chunkの合計のサイズは4バイトの倍数であること。 4バイトの倍数でない場合、送信者は0バイトでpaddingし、paddingはChunk Lengthに含めないこと。 送信者は3バイトより多くをpaddingしてはいけない。 受信者はpaddingバイトを無視すること。 SCTP-defined chunks are described in detail in Section 3.3. The guidelines for IETF-defined chunk extensions can be found in Section 14.1 of this document. SCTP定義のchunkはSection 3.3で詳しく述べる。 IETF定義のchunk拡張はSection 14.1で述べる。 3.2.1. Optional/Variable-Length Parameter Format Chunk values of SCTP control chunks consist of a chunk-type-specific header of required fields, followed by zero or more parameters. The optional and variable-length parameters contained in a chunk are defined in a Type-Length-Value format as shown below. SCTP control chunkのChunk valueは0以上のパラメータの必須フィールドのchunk-type-specificヘッダで構成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Parameter Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart Standards Track [Page 19] RFC 4960 Stream Control Transmission Protocol September 2007 Chunk Parameter Type 16 bits (unsigned integer) The Type field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534. パラメータのタイプの16bit識別子。0～65534。 The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific SCTP chunk descriptions are reserved for use by IETF. 65535はIETF定義の拡張のためのreserve。 特定のSCTP chunkで定義された値以外はIETFで使用するためreserveされている。 Chunk Parameter Length 16 bits (unsigned integer) The Parameter Length field contains the size of the parameter in bytes, including the Parameter Type, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes. Parameter Type、Parameter Length、Parameter Valueのバイト数。 Parameter Valueが0ならばLengthは4。 Parameter Lengthはpadding byteを含まない。 Chunk Parameter Value variable length The Parameter Value field contains the actual information to be transferred in the parameter. Parameter Valueはパラメータで転送される情報を含む。 The total length of a parameter (including Type, Parameter Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is not included in the Parameter Length field. A sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. パラメータ長の合計は4バイトの倍数であること。 4バイトの倍数でない場合、送信者は最後(Parameter Valueの後)に0でpaddingする。 padding長はParameter Lengthに含めない。 送信者は3バイトより多くのpaddingをしてはいけない。 受信者はpaddingを無視すること。 The Parameter Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type. Parameter Typeが認識できない場合にParameter Typeの上位2ビットでやるべきアクションが定義されている。 00 - Stop processing this parameter; do not process any further parameters within this chunk. パラメータの処理を停止し、パラメータを処理しない。 01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an Unrecognized Parameter , as described in Section 3.2.2. パラメータパケット処理を停止し、パラメータを処理しない。Unrecognized Parameterとしてパラメータを報告する。Section 3.2.2参照。 10 - Skip this parameter and continue processing. パラメータをスキップし、処理を継続する。 11 - Skip this parameter and continue processing but report the unrecognized parameter in an Unrecognized Parameter , as described in Section 3.2.2. パラメータをスキップし、処理を継続する。Unrecognized parameterで報告する。Section 3.2.2参照。 Stewart Standards Track [Page 20] RFC 4960 Stream Control Transmission Protocol September 2007 Please note that in all four cases, an INIT ACK or COOKIE ECHO chunk is sent. In the 00 or 01 case, the processing of the parameters after the unknown parameter is canceled, but no processing already done is rolled back. 4つのケースでINIT ACK、COOKIE ECHOが送信されるのに注意してください。 00 or 01のケースでは、キャンセルされ、未実施の処理はロールバックされない。 The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 14.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type 5 is used to represent an IPv4 address (see Section 3.3.2.1). The value 5 then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk. SCTPのパラメータはSCTP chunk sectionで定義される。 IETF定義のパラメータ拡張はSection 14.2で定義される。 すべてのchunkでParameter Typeは一意であること。 例えば、Parameter Type 5はIPv4アドレスを表すために使用される。(Section 3.3.1.1参照) 5はIPv4 アドレスを表すためにreserveされており、他のchunkで異なる意味の仕様をしてはいけない。 3.2.2. Reporting of Unrecognized Parameters If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the Unrecognized Parameter parameter(s) in the INIT ACK chunk sent in response to the INIT chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), an Unrecognized Parameter would NOT be included with any ABORT being sent to the sender of the INIT. INIT chunkの受信者がunrecognized parameterを検出し、Section 3.2.1に従って報告する場合、INIT chunkの応答としてINIT ACK chunkに Unrecognized Parameter parametersを付与すること。 INIT chunkの受信者がassociationの確立していない場合(リソース不足などにより)、送信者へのABORTには Unrecognized Parameter が含まれていないことに注意せよ。 If the receiver of an INIT ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the Unrecognized Parameters error cause with the COOKIE ECHO chunk sent in response to the INIT ACK chunk. If the receiver of the INIT ACK cannot bundle the COOKIE ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE ACK has been received. INIT ACK chunkの受信者が認識できないパラメータを検出し、Section 3.2.1に従って報告する場合、INIT ACK chunの応答のCOOKIE ECHO chunkで Unrecognized Parameters を含むERROR chunkをbundleすること。 INIT ACKの受信者がERROR chunkをCOOKIE ECHO chunkにbundleできない場合、ERROR chunkはCOOKIE ACKの受信前に分けて送られてもよい。 Note Any time a COOKIE ECHO is sent in a packet, it MUST be the first chunk. COOKIE ECHOをパケットで送信するときはそれは最初のchunkであること。 3.3. SCTP Chunk Definitions This section defines the format of the different SCTP chunk types. SCTP chunk typeのフォーマットを定義する。 Stewart Standards Track [Page 21] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.1. Payload Data (DATA) (0) The following format MUST be used for the DATA chunk 下記のフォーマットはDATAチャンクに使うこと。 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 = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data (seq n of Stream S) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 5 bits Should be set to all 0 s and ignored by the receiver. 0を設定し、受信者は無視すること U bit 1 bit The (U)nordered bit, if set to 1 , indicates that this is an unordered DATA chunk, and there is no Stream Sequence Number assigned to this DATA chunk. Therefore, the receiver MUST ignore the Stream Sequence Number field. 順不同のbit。1が設定された場合、DATA chunkは順不同であることを示し、SSNはDATA chunkはない。 そのため、受信者はSSN fieldを無視すること。 After reassembly (if necessary), unordered DATA chunks MUST be dispatched to the upper layer by the receiver without any attempt to reorder. 必要ならばreassemblyの後、順不同のDATA chunkは順序制御なしに受信者によって上位レイヤに転送されること。 If an unordered user message is fragmented, each fragment of the message MUST have its U bit set to 1 . 順不同のユーザデータがフラグメントされた場合、各フラグメントはU bitに1がセットされる。 B bit 1 bit The (B)eginning fragment bit, if set, indicates the first fragment of a user message. fragmentの開始bit。セットされた場合、ユーザメッセージの最初のフラグメントを示す。 E bit 1 bit The (E)nding fragment bit, if set, indicates the last fragment of a user message. fragmentの最終bit。セットされた場合、ユーザメッセージの最後のフラグメントを示す。 Stewart Standards Track [Page 22] RFC 4960 Stream Control Transmission Protocol September 2007 An unfragmented user message shall have both the B and E bits set to 1 . Setting both B and E bits to 0 indicates a middle fragment of a multi-fragment user message, as summarized in the following table fragmentされていないユーザメッセージはB、E bitに1を設定すること。 BとEに0が設定されることは、フラグメントの中間であることを示す。 要約を下記のテーブルに示す。 B E Description ============================================================ | 1 0 | First piece of a fragmented user message | +----------------------------------------------------------+ | 0 0 | Middle piece of a fragmented user message | +----------------------------------------------------------+ | 0 1 | Last piece of a fragmented user message | +----------------------------------------------------------+ | 1 1 | Unfragmented message | ============================================================ | Table 1 Fragment Description Flags | ============================================================ When a user message is fragmented into multiple chunks, the TSNs are used by the receiver to reassemble the message. This means that the TSNs for each fragment of a fragmented user message MUST be strictly sequential. ユーザメッセージが複数のチャンクにfragmentされる場合、TSNがメッセージをreassembleするために受信者に使用される。 これはfragmentされたユーザメッセージの各fragmentのTSNは正確に連続していることを意味している。 Length 16 bits (unsigned integer) This field indicates the length of the DATA chunk in bytes from the beginning of the type field to the end of the User Data field excluding any padding. A DATA chunk with one byte of user data will have Length set to 17 (indicating 17 bytes). このfieldにはpaddingを除いたType filedの開始からUser Data fieldの最後までのバイト数で、DATA chunkの長さを表す。 1バイトのユーザデータをもつDATA chunkはLengthに17が設定される。(17byteを表す) A DATA chunk with a User Data field of length L will have the Length field set to (16 + L) (indicating 16+L bytes) where L MUST be greater than 0. Lが0より大きいとき、長さLのUser Data fieldをもつDATA chunkはLength filedに16 + Lが設定される。(16 + Lbyteを示す。) TSN 32 bits (unsigned integer) This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 after reaching 4294967295. DATA chunkのTSNを表す。 TSNの範囲は0～4294967295である。 TSNは4294967295に達すると0に戻る。 Stream Identifier S 16 bits (unsigned integer) Identifies the stream to which the following user data belongs. user dataが属するstreamを識別する。 Stream Sequence Number n 16 bits (unsigned integer) This value represents the Stream Sequence Number of the following user data within the stream S. Valid range is 0 to 65535. Stream Sのuser dataのSSNを表す。範囲は0～65535。 Stewart Standards Track [Page 23] RFC 4960 Stream Control Transmission Protocol September 2007 When a user message is fragmented by SCTP for transport, the same Stream Sequence Number MUST be carried in each of the fragments of the message. SCTPにfragmentされた場合、同じSSNがメッセージの各fragmentに設定されること。 Payload Protocol Identifier 32 bits (unsigned integer) This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation; therefore, its byte order is NOT necessarily big endian. The upper layer is responsible for any byte order conversions to this field. この値はapplicationか上位レイヤにより指定されたprotocol identifierを表す。 この値は上位レイヤから渡され、peerに送られる。 この識別子はSCTPでは使われないが、DATA chunkで送信される情報のタイプを識別するためnetwork entity、peer applicationで使われる。 このfiledはfragmentのDATA chunkにでも送信されること。 このfieldはSCTPに関与されないことに注意せよ。バイトオーダーはビッグエンディアンである必要はない。 上位レイヤはこのfieldのバイトオーダー変換を担う。 The value 0 indicates that no application identifier is specified by the upper layer for this payload data. 0はこのpayload dataに上位レイヤによってapplication identifierが指定されていないことを示す。 User Data variable length This is the payload user data. The implementation MUST pad the end of the data to a 4-byte boundary with all-zero bytes. Any padding MUST NOT be included in the Length field. A sender MUST never add more than 3 bytes of padding. payload user data。4-byte boundaryのためall 0でpaddingすること。 paddingはLength fieldに含めないこと。 送信者は3byteを超えるpaddingを加えないこと。 3.3.2. Initiation (INIT) (1) This chunk is used to initiate an SCTP association between two endpoints. The format of the INIT chunk is shown below このchunkは2つのエンドポイント間のSCTP associationの初期化に使用する。 INIT chunkのformatを下記に示す。 Stewart Standards Track [Page 24] RFC 4960 Stream Control Transmission Protocol September 2007 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 = 1 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional/Variable-Length Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The INIT chunk contains the following parameters. Unless otherwise noted, each parameter MUST only be included once in the INIT chunk. INIT chunkには下記のパラメータが含まれている。 各パラメータは一つだけINIT chunkに含まれること。 Fixed Parameters Status ---------------------------------------------- Initiate Tag Mandatory Advertised Receiver Window Credit Mandatory Number of Outbound Streams Mandatory Number of Inbound Streams Mandatory Initial TSN Mandatory Variable Parameters Status Type Value ------------------------------------------------------------- IPv4 Address (Note 1) Optional 5 IPv6 Address(Note 1) Optional 6 Cookie Preservative Optional 9 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Supported Address Types (Note 4) Optional 12 Note 1 The INIT chunks can contain multiple addresses that can be IPv4 and/or IPv6 in any combination. Note 1 INIT chunkはIPv4 and/or IPv6の任意の組み合わせで複数のアドレスを含むことができる。 Note 2 The ECN Capable field is reserved for future use of Explicit Congestion Notification. ECN Capable filedはExplicit Congestion Notificationの今後の仕様のためのreserve領域。 Note 3 An INIT chunk MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT MUST NOT combine any other address types with the Host Name Address in the INIT. The receiver of INIT MUST ignore any other address types if the Host Name Address parameter is present in the received INIT chunk. INIT chunkは複数のHost Name Addressパラメータを含んではいけない。 INITの送信者はINITのHost Name Addressを他のアドレスタイプと組み合わせてはいけない。 Host Name Addressパラメータが受信したINIT chunkに存在する場合、INITの受信者は他のアドレスタイプを無視すること。 Stewart Standards Track [Page 25] RFC 4960 Stream Control Transmission Protocol September 2007 Note 4 This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type. このパラメータが存在する場合、送信エンドポイントがサポートできるすべてのアドレスタイプを指定する。 このパラメータが存在しない場合、送信エンドポイントが任意のアドレスタイプをサポートできることを示す。 IMPLEMENTATION NOTE If an INIT chunk is received with known parameters that are not optional parameters of the INIT chunk, then the receiver SHOULD process the INIT chunk and send back an INIT ACK. The receiver of the INIT chunk MAY bundle an ERROR chunk with the COOKIE ACK chunk later. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT chunk. INIT chunkがINIT chunkのオプションでない既知のパラメータとともに受信された場合、受信側はINIT chunkを処理し、INIT ACKを送信すること。 INIT chunkの受信者はCOOKIE ACK chunでERROR chunkをbundleしてもよい。 実装の制限では、INIT chunkに対してABORT chunkを返す。 The Chunk Flags field in INIT is reserved, and all bits in it should be set to 0 by the sender and ignored by the receiver. The sequence of parameters within an INIT can be processed in any order. INITのChunk Flag fieldはreserveであり、送信者によって0が設定され、受信者は無視する。 INITのパラメータは順序は任意の順序で処理できる。 Initiate Tag 32 bits (unsigned integer) The receiver of the INIT (the responding end) records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the receiver of the INIT transmits within this association. INITの受信者はInitiate Tag パラメータの値を記録する。 この値はINITの受信者がassociation中に送信するすべてのSCTPパケットのVerification Tag fieldに設定すること。 The Initiate Tag is allowed to have any value except 0. See Section 5.3.1 for more on the selection of the tag value. Initiate Tagは0以外の値をもつこと。 tag valueの選択についてはSection 5.2.1参照。 If the value of the Initiate Tag in a received INIT chunk is found to be 0, the receiver MUST treat it as an error and close the association by transmitting an ABORT. 受信したINIT chunkのInitiate Tagの値に0を見つけた場合、受信者はエラーとして扱い、ABORTを送信してassociationを終了する。 Advertised Receiver Window Credit (a_rwnd) 32 bits (unsigned integer) This value represents the dedicated buffer space, in number of bytes, the sender of the INIT has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association); however, an endpoint MAY change the value of a_rwnd it sends in SACK chunks. INITの送信者がassociationのwindow用に確保しているバッファ領域のバイト数。 Assosiationの存続中、このバッファスペースは減らされないこと(バッファはassosiationから取り除かれないこと)。ただし、エンドポイントはSACK chunkで送るa_rwndの値を変更してもよい。 Number of Outbound Streams (OS) 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT chunk wishes to create in this association. The value of 0 MUST NOT be used. INIT chunkの送信者がassociationで作成するoutbound stream数を定義する。 0は使用してはいけない。 Note A receiver of an INIT with the OS value set to 0 SHOULD abort the association. OSが0に設定されたINITの受信者はassociationをabortすること。 Stewart Standards Track [Page 26] RFC 4960 Stream Control Transmission Protocol September 2007 Number of Inbound Streams (MIS) 16 bits (unsigned integer) Defines the maximum number of streams the sender of this INIT chunk allows the peer end to create in this association. The value 0 MUST NOT be used. INIT chunkの送信者がpeer側で作成されるassociationで許可する最大のstream数を定義する。 0を使用しないこと。 Note There is no negotiation of the actual number of streams but instead the two endpoints will use the min(requested, offered). See Section 5.1.1 for details. Stream数のネゴシエーションはしないが、代わりに2エンドポイントはmin(requested, offered)を使用する。詳細はSection 5.1.1参照。 Note A receiver of an INIT with the MIS value of 0 SHOULD abort the association. MISが0のINITの受信者はassociationをabortすること。 Initial TSN (I-TSN) 32 bits (unsigned integer) Defines the initial TSN that the sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field. 送信側が使用するTSNの初期値を定義する。 範囲は0～4294967295。このフィールドはInitiate Tag fieldの値を設定してもよい。 3.3.2.1. Optional/Variable-Length Parameters in INIT The following parameters follow the Type-Length-Value format as defined in Section 3.2.1. Any Type-Length-Value fields MUST come after the fixed-length fields defined in the previous section. 下記のパラメータはSection 3.2.1で定義されたType-Length-Valueフォーマットに従うこと。 Type-Length-Value fieldは前のSectionで定義された固定長フィールドの後にあること。 IPv4 Address Parameter (5) 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 = 5 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Address 32 bits (unsigned integer) Contains an IPv4 address of the sending endpoint. It is binary encoded. 送信側のIPv4アドレスが含まれる。binary encodeである。 Stewart Standards Track [Page 27] RFC 4960 Stream Control Transmission Protocol September 2007 IPv6 Address Parameter (6) 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 = 6 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Address 128 bits (unsigned integer) Contains an IPv6 [RFC2460] address of the sending endpoint. It is binary encoded. 送信側のIPv4アドレスが含まれる。binary encodeである。 Note A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291], but should instead use an IPv4 Address parameter for an IPv4 address. 送信者はIPv4マップ IPv6アドレスを使用してはいけない。 IPv4でIPv4 address parameterを使用すること。 Combined with the Source Port Number in the SCTP common header, the value passed in an IPv4 or IPv6 Address parameter indicates a transport address the sender of the INIT will support for the association being initiated. That is, during the life time of this association, this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT, and can be used as a destination address of an IP datagram sent from the receiver of the INIT. SCTP common headerのSource Port Numberと組み合わされ、Transport addressのIPv4 or IPv6 アドレスパラメータの値はassociationを示す。 すなわち、associationの生存時間中、このIPアドレスはINIT送信者の送信したIP datagramの送信アドレスとなり、INIT受信側から送信されたIP datagramの宛先アドレスとして使用される。 More than one IP Address parameter can be included in an INIT chunk when the INIT sender is multi-homed. Moreover, a multi- homed endpoint may have access to different types of network; thus, more than one address type can be present in one INIT chunk, i.e., IPv4 and IPv6 addresses are allowed in the same INIT chunk. INIT送信側がmulti-homeの場合、複数のIPアドレスパラメータがINIT chunkに含まれる。 さらに、multi-home エンドポイントはネットワークの異なるタイプのアクセスがあってもよい。 従って、一つのINIT chunkに複数のアドレスタイプが存在してよい。すなわちIPv4、IPv6アドレスが同一のINIT chunkであることが許容される。 If the INIT contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT chunk and any additional address(es) provided within the INIT can be used as destinations by the endpoint receiving the INIT. If the INIT does not contain any IP Address parameters, the endpoint receiving the INIT MUST use the source address associated with the received IP datagram as its sole destination address for the association. INITが1つ以上のIPアドレスを含む場合、INIT内のaddress、INITを含むIP datagramのsource addressがINITを受信したエンドポイントに宛先として使用される。 INITがIP アドレスパラメータを含んでいない場合、INITを受信したエンドポイントはassociationに受信したIP datagramの送信元IPアドレスを宛先アドレスとして使用すること。 Note that not using any IP Address parameters in the INIT and INIT ACK is an alternative to make an association more likely to work across a NAT box. INIT、INIT ACKのIPアドレスパラメータを使用していないが、associationがNAT boxを経由するためである。 Stewart Standards Track [Page 28] RFC 4960 Stream Control Transmission Protocol September 2007 Cookie Preservative (9) The sender of the INIT shall use this parameter to suggest to the receiver of the INIT for a longer life-span of the State Cookie. INITの送信側はState Cookieのlife-spanをINITの受信側に提示するため、このパラメータを使用すること。 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 = 9 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suggested Cookie Life-Span Increment (msec.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Suggested Cookie Life-Span Increment 32 bits (unsigned integer) This parameter indicates to the receiver how much increment in milliseconds the sender wishes the receiver to add to its default cookie life-span. default cookie life-spanに受信側が追加するms単位の増分を受信側に示す。 This optional parameter should be added to the INIT chunk by the sender when it reattempts establishing an association with a peer to which its previous attempt of establishing the association failed due to a stale cookie operation error. The receiver MAY choose to ignore the suggested cookie life-span increase for its own security reasons. このオプションパラメータは送信者がピアとのcookieが古くなったエラーによりassociationを確立するとき、INIT chunkに追加すること。 受信側はセキュリティのため、提示されたcookie life-span増加を無視してもよい。 Host Name Address (11) The sender of INIT uses this parameter to pass its Host Name (in place of its IP addresses) to its peer. The peer is responsible for resolving the name. Using this parameter might make it more likely for the association to work across a NAT box. INITの送信者はピアにHost Name(IP addressの代わり)を渡すために使われる。 ピアは名前解決をする必要がある。このパラメータの使用によりNAT boxを経由してassociationを作成できる。 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 = 11 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Host Name / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Host Name variable length This field contains a host name in host name syntax per RFC 1123 Section 2.1 [RFC1123]. The method for resolving the host name is out of scope of SCTP. このフィールドはRFC 1123 Section 2.1の host name syntax のhost nameが含まれる。 ホスト名の解決方法はSCTPのスコープ外である。 Stewart Standards Track [Page 29] RFC 4960 Stream Control Transmission Protocol September 2007 Note At least one null terminator is included in the Host Name string and must be included in the length. 1以上のnull終端がHost Name stringに含まれ、lengthに含まれること。 Supported Address Types (12) The sender of INIT uses this parameter to list all the address types it can support. INITの送信者はサポートできるすべてのアドレスタイプの一覧のためこのパラメータを使用する。 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 = 12 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type #1 | Address Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ Address Type 16 bits (unsigned integer) This is filled with the type value of the corresponding address TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). 対応するアドレス TLVのタイプの値が設定される。 3.3.3. Initiation Acknowledgement (INIT ACK) (2) The INIT ACK chunk is used to acknowledge the initiation of an SCTP association. INIT ACK chunkはSCTP associationの開始をacknowledgeするために使用される。 The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters The State Cookie and the Unrecognized Parameter INIT ACKのパラメータはINIT chunkと同様に定義される。 2つの可変パラメータを使用する。State Cookie、Unrecognized Parameter。 Stewart Standards Track [Page 30] RFC 4960 Stream Control Transmission Protocol September 2007 The format of the INIT ACK chunk is shown below 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 = 2 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional/Variable-Length Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Initiate Tag 32 bits (unsigned integer) The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association. INIT ACKの受信者はInitiate Tagの値を記録する。 この値はassociationでINIT ACK受信者が送信するすべてのSCTPパケットのVerification Tagに設定されること。 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value. Initiate Tagは0を設定してはいけない。Initiate Tagの値についてはSection 5.3.1参照。 If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST destroy the association discarding its TCB. The receiver MAY send an ABORT for debugging purpose. 受信したINIT ACK chunkのInitiate Tagの値が0の場合、受信者はassociationを破棄すること。受信者はデバッグのためABORTを送ってもよい。 Advertised Receiver Window Credit (a_rwnd) 32 bits (unsigned integer) This value represents the dedicated buffer space, in number of bytes, the sender of the INIT ACK has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association). INIT ACKの送信者がassociationのwindow用に確保しているバッファ領域のバイト数。 Associationの存続中、このバッファスペースは減らされないこと(バッファはassosiationから取り除かれないこと)。 Stewart Standards Track [Page 31] RFC 4960 Stream Control Transmission Protocol September 2007 Number of Outbound Streams (OS) 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used, and the value MUST NOT be greater than the MIS value sent in the INIT chunk. INIT ACK chunkの送信者がassociationで作成するoutbound stream数を定義する。 0は使用してはいけない。INIT chunkで送信されたMIS値より大きくしてはいけない。 Note A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB. OSに0が設定されたINIT ACKの受信者はassociationを削除し、TCBを破棄すること。 Number of Inbound Streams (MIS) 16 bits (unsigned integer) Defines the maximum number of streams the sender of this INIT ACK chunk allows the peer end to create in this association. The value 0 MUST NOT be used. INIT ACK chunkの送信者がpeer側で作成されるassociationで許可する最大のstream数を定義する。 0を使用しないこと。 Note There is no negotiation of the actual number of streams but instead the two endpoints will use the min(requested, offered). See Section 5.1.1 for details. Stream数のネゴシエーションはしないが、代わりに2エンドポイントはmin(requested, offered)を使用する。詳細はSection 5.1.1参照。 Note A receiver of an INIT ACK with the MIS value set to 0 SHOULD destroy the association discarding its TCB. MISに0が設定されたINIT ACKの受信者はassociationを削除し、TCBを破棄すること。 Initial TSN (I-TSN) 32 bits (unsigned integer) Defines the initial TSN that the INIT ACK sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field. INIT ACKの送信側が使用するTSNの初期値を定義する。 範囲は0～4294967295。このフィールドはInitiate Tag fieldの値を設定してもよい。 Fixed Parameters Status ---------------------------------------------- Initiate Tag Mandatory Advertised Receiver Window Credit Mandatory Number of Outbound Streams Mandatory Number of Inbound Streams Mandatory Initial TSN Mandatory Variable Parameters Status Type Value ------------------------------------------------------------- State Cookie Mandatory 7 IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 Unrecognized Parameter Optional 8 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Note 1 The INIT ACK chunks can contain any number of IP address parameters that can be IPv4 and/or IPv6 in any combination. INIT ACK chunkは任意の組み合わせでIPv4/IPv6アドレスを複数含むことができる。 Note 2 The ECN Capable field is reserved for future use of Explicit Congestion Notification. ECN fieldはExplicit Congestion Notification(明示的輻輳通知)のためにreserveされている。 Stewart Standards Track [Page 32] RFC 4960 Stream Control Transmission Protocol September 2007 Note 3 The INIT ACK chunks MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT ACK MUST NOT combine any other address types with the Host Name Address in the INIT ACK. The receiver of the INIT ACK MUST ignore any other address types if the Host Name Address parameter is present. INIT ACK chunkは複数のHost Name Addressパラメータを含んではいけない。INIT ACKの送信者はINIT ACKのHost Name Addressを他のアドレスタイプと組み合わせてはいけない。 Host Name Addressパラメータが受信したINIT ACK chunkに存在する場合、INIT ACKの受信者は他のアドレスタイプを無視すること。 IMPLEMENTATION NOTE An implementation MUST be prepared to receive an INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the State Cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK. 実装では、State Cookieと可変長アドレスリストのため1500byte以上のINIT ACKを受信する準備をすること。 例えば、INITの送信者が送りたいIPv4アドレスを1000個持っている場合、INIT ACKでencodeすると8000byte以上は必要になる。 IMPLEMENTATION NOTE If an INIT ACK chunk is received with known parameters that are not optional parameters of the INIT ACK chunk, then the receiver SHOULD process the INIT ACK chunk and send back a COOKIE ECHO. The receiver of the INIT ACK chunk MAY bundle an ERROR chunk with the COOKIE ECHO chunk. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT ACK chunk. INIT ACK chunkがINIT ACK chunkのオプションでない既知のパラメータとともに受信された場合、受信側はINIT ACK chunkを処理し、COOKIE ECHOを送信すること。 INIT ACK chunkの受信者はCOOKIE ECHO chunkでERROR chunkをbundleしてもよい。 実装の制限では、INIT ACK chunkに対してABORT chunkを返してもよい。 In combination with the Source Port carried in the SCTP common header, each IP Address parameter in the INIT ACK indicates to the receiver of the INIT ACK a valid transport address supported by the sender of the INIT ACK for the life time of the association being initiated. SCTP common header内のSource Portと組み合わせ、INIT ACK内の各IP AddressパラメータはINIT ACKの受信側にINIT ACKの送信者がサポートしてるassociationで有効なtransport addressを示す。 If the INIT ACK contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT ACK and any additional address(es) provided within the INIT ACK may be used as destinations by the receiver of the INIT ACK. If the INIT ACK does not contain any IP Address parameters, the receiver of the INIT ACK MUST use the source address associated with the received IP datagram as its sole destination address for the association. INIT ACKが一つ以上IP Address paramterを含んでいる場合、INIT ACKに含まれるIPアドレスとIP datagramの送信元アドレスはINIT ACKの受信側に宛先として使用されてよい。 INIT ACKがIP address paramterを含まない場合、INIT ACKの受信側は受信したIP datagramの送信元IPアドレスをassociationの宛先アドレスとして使用すること。 The State Cookie and Unrecognized Parameters use the Type-Length- Value format as defined in Section 3.2.1 and are described below. The other fields are defined the same as their counterparts in the INIT chunk. State CookieとUnrecognized Parmterは Section 3.2.1と下記に定義されたType-Length-Value formatを使用する。 他のfiledはINIT chunkの対応するfieldと同様に定義される。 3.3.3.1. Optional or Variable-Length Parameters State Cookie Parameter Type Value 7 Parameter Length Variable size, depending on size of Cookie. Stewart Standards Track [Page 33] RFC 4960 Stream Control Transmission Protocol September 2007 Parameter Value This parameter value MUST contain all the necessary state and parameter information required for the sender of this INIT ACK to create the association, along with a Message Authentication Code (MAC). See Section 5.1.3 for details on State Cookie definition. このparamterはINIT ACKの送信者がassociation作成に必要なparameterとstateをMessage Authentication Code(MAC)とともに含むこと。 State Cookieの定義の詳細は5.1.3 Unrecognized Parameter Parameter Type Value 8 Parameter Length Variable size. Parameter Value This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter that has a value that indicates it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length, and Value fields. INITが送信側に報告するべき未認識のパラメータを含んでいる場合、このパラメータはINIT chunkの送信側に返される。 このparamter value field はParamter Type、Length、ValueをINIT chunkからコピーした未認識のパラメータを含む。