[要約] RFC 2974は、セッションアナウンスプロトコル（SAP）に関する仕様です。SAPは、マルチキャストセッションのアナウンスと制御を行うためのプロトコルです。このRFCの目的は、SAPの仕様と機能を提供し、マルチキャストセッションの効率的な管理を可能にすることです。
Network Working Group M. Handley
Request for Comments: 2974 ACIRI
Category: Experimental C. Perkins
USC/ISI
E. Whelan
UCL
October 2000
Session Announcement Protocol
セッションアナウンスプロトコル
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.
このドキュメントでは、マルチキャストセッションディレクトリアナウンスアナウンスプロトコル、セッションアナウンスアナウンスプロトコル（SAP）のバージョン2、および実装者が考慮すべきセキュリティとスケーラビリティに影響する関連する問題について説明します。
1 Introduction
1はじめに
In order to assist the advertisement of multicast multimedia conferences and other multicast sessions, and to communicate the relevant session setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically multicasts packets containing a description of the session, and these advertisements are received by other session directories such that potential remote participants can use the session description to start the tools required to participate in the session.
マルチキャストマルチメディア会議やその他のマルチキャストセッションの広告を支援し、関連するセッションのセットアップ情報を将来の参加者に伝えるために、分散セッションディレクトリを使用できます。このようなセッションディレクトリのインスタンスは、セッションの説明を含む定期的にマルチキャストパケットであり、これらの広告は他のセッションディレクトリによって受信され、潜在的なリモート参加者がセッションの説明を使用してセッションに参加するために必要なツールを開始できます。
This memo describes the issues involved in the multicast announcement of session description information and defines an announcement protocol to be used. Sessions are described using the session description protocol which is described in a companion memo [4].
このメモは、セッション説明情報のマルチキャストアナウンスに関連する問題について説明し、使用する発表プロトコルを定義します。セッションは、コンパニオンメモ[4]で説明されているセッション説明プロトコルを使用して説明されています。
2 Terminology
2用語
A SAP announcer periodically multicasts an announcement packet to a well known multicast address and port. The announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement are within the scope of the session the announcement describes (bandwidth and other such constraints permitting). This is also important for the scalability of the protocol, as it keeps local session announcements local.
SAPアナウンサーは、定期的によく知られているマルチキャストアドレスとポートにアナウンスパケットをマルチキャストします。発表は、発表されているセッションと同じ範囲のマルチキャストであり、発表の受信者が発表が説明するセッションの範囲内にあることを保証します（帯域幅およびそのような制約が許可するその他の制約）。これは、ローカルセッションのアナウンスをローカルに保つため、プロトコルのスケーラビリティにとっても重要です。
A SAP listener learns of the multicast scopes it is within (for example, using the Multicast-Scope Zone Announcement Protocol [5]) and listens on the well known SAP address and port for those scopes. In this manner, it will eventually learn of all the sessions being announced, allowing those sessions to be joined.
SAPリスナーは、その内部（たとえば、マルチキャストスコープゾーンアナウンスプロトコル[5]を使用して）内にあるマルチキャストスコープを学び、それらのスコープのよく知られているSAPアドレスとポートに耳を傾けます。この方法で、最終的に発表されているすべてのセッションについて学び、それらのセッションに参加できるようになります。
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 [1].
「必須」、「必須」、「必須」、「「しなければならない」、「そうでない」、「そうは思わない」、「そうでない」、「推奨」、「5月」、「オプション」は、[1]に記載されているとおりに解釈される。
3 Session Announcement
3セッションの発表
As noted previously, a SAP announcer periodically sends an announcement packet to a well known multicast address and port. There is no rendezvous mechanism - the SAP announcer is not aware of the presence or absence of any SAP listeners - and no additional reliability is provided over the standard best-effort UDP/IP semantics.
前述のように、SAPアナウンサーは定期的に発表パケットをよく知られているマルチキャストアドレスとポートに送信します。ランデブーメカニズムはありません - SAPアナウンサーは、SAPリスナーの存在または不在を認識していません - 標準のベストエフォルトUDP/IPセマンティクスに対して追加の信頼性は提供されません。
That announcement contains a session description and SHOULD contain an authentication header. The session description MAY be encrypted although this is NOT RECOMMENDED (see section 7).
その発表にはセッションの説明が含まれており、認証ヘッダーが含まれている必要があります。セッションの説明は暗号化される場合がありますが、これは推奨されません（セクション7を参照）。
A SAP announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement are within the scope of the session the announcement describes. There are a number of possibilities:
SAPの発表は、発表しているセッションと同じ範囲のマルチキャストであり、発表の受信者が発表が説明するセッションの範囲内であることを保証します。多くの可能性があります：
IPv4 global scope sessions use multicast addresses in the range 224.2.128.0 - 224.2.255.255 with SAP announcements being sent to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete SAPv0 and MUST NOT be used).
IPv4グローバルスコープセッションは、範囲224.2.2.128.0-224.2.255.255のマルチキャストアドレスを使用し、SAPアナウンスは224.2.2.127.254に送信されます（224.2.2.127.255は、廃止されたSAPV0によって使用されていないことに注意してください）。
IPv4 administrative scope sessions using administratively scoped IP multicast as defined in [7]. The multicast address to be used for announcements is the highest multicast address in the relevant administrative scope zone. For example, if the scope range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used for SAP announcements.
[7]で定義されている管理上スコープIPマルチキャストを使用したIPv4管理スコープセッション。発表に使用されるマルチキャストアドレスは、関連する管理スコープゾーンで最高のマルチキャストアドレスです。たとえば、スコープ範囲が239.16.32.0-239.16.33.255の場合、SAPアナウンスに239.16.33.255が使用されます。
IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE where X is the 4-bit scope value. For example, an announcement for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678, should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE.
IPv6セッションは、アドレスFF0x：0：0：0：0：0：0：2：7ffeで発表されます。ここで、xは4ビットスコープ値です。たとえば、アドレスFF02：0：0：0：0：0：0：0：5678を割り当てたリンクローカルセッションの発表は、SAPアドレスFF02：0：0：0：0：0：0：2に宣伝する必要があります。7ffe。
Ensuring that a description is not used by a potential participant outside the session scope is not addressed in this memo.
このメモでは、セッションスコープの外側の潜在的な参加者が説明が使用されないことを確認してください。
SAP announcements MUST be sent on port 9875 and SHOULD be sent with an IP time-to-live of 255 (the use of TTL scoping for multicast is discouraged [7]).
SAPアナウンスはポート9875に送信する必要があり、255のIP時間までの時間を送信する必要があります（マルチキャストのためにTTLスコープの使用は落胆します[7]）。
If a session uses addresses in multiple administrative scope ranges, it is necessary for the announcer to send identical copies of the announcement to each administrative scope range. It is up to the listeners to parse such multiple announcements as the same session (as identified by the SDP origin field, for example). The announcement rate for each administrative scope range MUST be calculated separately, as if the multiple announcements were separate.
セッションで複数の管理スコープ範囲でアドレスを使用する場合、アナウンサーが各管理範囲の範囲に同一のコピーを送信する必要があります。同じセッションとしてこのような複数の発表を解析するのはリスナー次第です（たとえば、SDP Originフィールドで識別されます）。複数の発表が別々であるかのように、各管理スコープ範囲の発表率は別々に計算する必要があります。
Multiple announcers may announce a single session, as an aid to robustness in the face of packet loss and failure of one or more announcers. The rate at which each announcer repeats its announcement MUST be scaled back such that the total announcement rate is equal to that which a single server would choose. Announcements made in this manner MUST be identical.
複数のアナウンサーは、パケットの損失と1つ以上のアナウンサーの障害に直面した堅牢性への支援として、単一のセッションを発表する場合があります。各アナウンサーが発表を繰り返すレートは、総アナウンスレートが単一のサーバーが選択するものと等しくなるように拡大する必要があります。この方法で行われた発表は同一でなければなりません。
If multiple announcements are being made for a session, then each announcement MUST carry an authentication header signed by the same key, or be treated as a completely separate announcement by listeners.
セッションのために複数の発表が行われている場合、各発表は同じキーによって署名された認証ヘッダーを搭載するか、リスナーによる完全に個別の発表として扱われる必要があります。
An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address and on the SAP addresses for each IPv4 administrative scope zone it is within. The discovery of administrative scope zones is outside the scope of this memo, but it is assumed that each SAP listener within a particular scope zone is aware of that scope zone. A SAP listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses.
IPv4 SAPリスナーは、IPv4グローバルスコープSAPアドレスと、各IPv4管理スコープゾーンのSAPアドレスで聞く必要があります。管理スコープゾーンの発見はこのメモの範囲外ですが、特定のスコープゾーン内の各SAPリスナーはそのスコープゾーンを認識していると想定されています。IPv6をサポートするSAPリスナーは、IPv6 SAPアドレスも聴く必要があります。
The time period between repetitions of an announcement is chosen such that the total bandwidth used by all announcements on a single SAP group remains below a preconfigured limit. If not otherwise specified, the bandwidth limit SHOULD be assumed to be 4000 bits per second.
発表の繰り返しの間の期間は、単一のSAPグループのすべての発表で使用される総帯域幅が、事前に設定された制限を下回ることを選択します。特に指定されていない場合、帯域幅の制限は1秒あたり4000ビットであると想定する必要があります。
Each announcer is expected to listen to other announcements in order to determine the total number of sessions being announced on a particular group. Sessions are uniquely identified by the combination of the message identifier hash and originating source fields of the SAP header (note that SAP v0 announcers always set the message identifier hash to zero, and if such an announcement is received the entire message MUST be compared to determine uniqueness).
各アナウンサーは、特定のグループで発表されているセッションの総数を決定するために、他の発表に耳を傾けることが期待されています。セッションは、メッセージ識別子ハッシュとSAPヘッダーのソースフィールドの発信ソースフィールドの組み合わせによって一意に識別されます（SAP V0アナウンサーは常にメッセージ識別子ハッシュをゼロに設定し、そのようなアナウンスを受信した場合、メッセージ全体を比較する必要があります。独自性）。
Announcements are made by periodic multicast to the group. The base interval between announcements is derived from the number of announcements being made in that group, the size of the announcement and the configured bandwidth limit. The actual transmission time is derived from this base interval as follows:
発表は、定期的なマルチキャストによってグループに行われます。アナウンス間の基本間隔は、そのグループで行われている発表の数、発表のサイズ、構成された帯域幅の制限から導き出されます。実際の伝送時間は、次のようにこのベース間隔から導き出されます。
1. The announcer initializes the variable tp to be the last time a particular announcement was transmitted (or the current time if this is the first time this announcement is to be made).
1. アナウンサーは、変数TPを初期化して、特定の発表が送信されたのは最後になりました（または、この発表が初めて行われる場合は現在の時刻です）。
2. Given a configured bandwidth limit in bits/second and an announcement of ad_size bytes, the base announcement interval in seconds is
2. ビット/秒で構成された帯域幅の制限とAD_SIZEバイトの発表が与えられた場合、秒単位の基本発表間隔は
interval =max(300; (8*no_of_ads*ad_size)/limit)
3. An offset is calculated based on the base announcement interval
3. オフセットは、基本発表間隔に基づいて計算されます
offset= rand(interval* 2/3)-(interval/3)
4. The next transmission time for an announcement derived as
4. 次の伝送時間として派生したアナウンス
tn =tp+ interval+ offset
The announcer then sets a timer to expire at tn and waits. At time tn the announcer SHOULD recalculate the next transmission time. If the new value of tn is before the current time, the announcement is sent immediately. Otherwise the transmission is rescheduled for the new tn. This reconsideration prevents transient packet bursts on startup and when a network partition heals.
その後、アナウンサーはTNで期限切れになるタイマーを設定し、待機します。時間TNでは、アナウンサーは次の送信時間を再計算する必要があります。TNの新しい値が現在の時刻より前にある場合、発表はすぐに送信されます。それ以外の場合は、新しいTN用に送信が再スケジュールされます。この再考により、スタートアップ時の一時的なパケットバーストと、ネットワークパーティションが癒されたときに防止されます。
4 Session Deletion
4セッションの削除
Sessions may be deleted in one of several ways:
セッションは、いくつかの方法のいずれかで削除される場合があります。
Explicit Timeout The session description payload may contain timestamp information specifying the start- and end-times of the session. If the current time is later than the end-time of the session, then the session SHOULD be deleted from the receiver's session cache.
明示的なタイムアウトセッションの説明ペイロードには、セッションの開始と終了を指定するタイムスタンプ情報が含まれている場合があります。現在の時刻がセッションの終了時間より遅い場合、セッションは受信者のセッションキャッシュから削除される必要があります。
Implicit Timeout A session announcement message should be received periodically for each session description in a receiver's session cache. The announcement period can be predicted by the receiver from the set of sessions currently being announced. If a session announcement message has not been received for ten times the announcement period, or one hour, whichever is the greater, then the session is deleted from the receiver's session cache. The one hour minimum is to allow for transient network partitionings.
暗黙的なタイムアウトセッションアナウンスメッセージは、受信者のセッションキャッシュでセッションの説明ごとに定期的に受信する必要があります。発表期間は、現在発表されている一連のセッションの受信者によって予測できます。セッションアナウンスメッセージが発表期間の10倍、または1時間のいずれか大きい方で受信されていない場合、セッションは受信者のセッションキャッシュから削除されます。最低1時間は、一時的なネットワークパーティションを可能にすることです。
Explicit Deletion A session deletion packet is received specifying the session to be deleted. Session deletion packets SHOULD have a valid authentication header, matching that used to authenticate previous announcement packets. If this authentication is missing, the deletion message SHOULD be ignored.
明示的削除セッション削除パケットが受信され、削除されるセッションを指定します。セッション削除パケットには、以前のアナウンスパケットを認証するために使用される有効な認証ヘッダーが必要です。この認証が欠落している場合、削除メッセージは無視する必要があります。
5 Session Modification
5セッションの変更
A pre-announced session can be modified by simply announcing the modified session description. In this case, the version hash in the SAP header MUST be changed to indicate to receivers that the packet contents should be parsed (or decrypted and parsed if it is encrypted). The session itself, as distinct from the session announcement, is uniquely identified by the payload and not by the message identifier hash in the header.
事前に発表されたセッションは、変更されたセッションの説明をアナウンスするだけで変更できます。この場合、SAPヘッダーのバージョンハッシュを変更して、受信機にパケットコンテンツを解析する（または暗号化されている場合は復号化され、解析される）ことを示す必要があります。セッションの発表とは異なるセッション自体は、ヘッダー内のメッセージ識別子ハッシュによってではなく、ペイロードによって一意に識別されます。
The same rules apply for session modification as for session deletion:
セッションの削除と同じルールがセッションの変更に適用されます。
o Either the modified announcement must contain an authentication header signed by the same key as the cached session announcement it is modifying, or:
o 修正されたアナウンスには、変更されているキャッシュセッションの発表と同じキーによって署名された認証ヘッダーを含める必要があります。
o The cached session announcement must not contain an authentication header, and the session modification announcement must originate from the same host as the session it is modifying.
o キャッシュされたセッションの発表には、認証ヘッダーが含まれていてはなりません。また、セッション修正の発表は、変更されているセッションと同じホストから発生する必要があります。
If an announcement is received containing an authentication header and the cached announcement did not contain an authentication header, or it contained a different authentication header, then the modified announcement MUST be treated as a new and different announcement, and displayed in addition to the un-authenticated announcement. The same should happen if a modified packet without an authentication header is received from a different source than the original announcement.
認証ヘッダーを含む発表を受け取った場合、およびキャッシュされた発表に認証ヘッダーが含まれていない場合、または別の認証ヘッダーが含まれていた場合、変更されたアナウンスを新しい異なる発表として扱い、un-に加えて表示する必要があります。認証された発表。認証ヘッダーのない変更されたパケットが、元の発表とは異なるソースから受信された場合も同じことが起こるはずです。
These rules prevent an announcement having an authentication header added by a malicious user and then being deleted using that header, and it also prevents a denial-of-service attack by someone putting out a spoof announcement which, due to packet loss, reaches some participants before the original announcement. Note that under such circumstances, being able to authenticate the message originator is the only way to discover which session is the correct session.
これらのルールは、悪意のあるユーザーによって認証ヘッダーが追加され、そのヘッダーを使用して削除されるという認証ヘッダーを持つ発表を妨げます。また、パケットの損失により、一部の参加者に到達するスプーフィングアナウンスを発表する人によるサービス拒否攻撃も防止されます。元の発表の前。このような状況では、メッセージオリジネーターを認証できることが、どのセッションが正しいセッションであるかを発見する唯一の方法であることに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet format
図1：パケット形式
6 Packet Format
6パケット形式
SAP data packets have the format described in figure 1.
SAPデータパケットには、図1で説明されている形式があります。
V: Version Number. The version number field MUST be set to 1 (SAPv2 announcements which use only SAPv1 features are backwards compatible, those which use new features can be detected by other means, so the SAP version number doesn't need to change).
V：バージョン番号。バージョン番号フィールドは1に設定する必要があります（SAPV1機能のみを使用するSAPV2アナウンスメントは後方互換性があり、新しい機能を使用するものは他の手段で検出できます。したがって、SAPバージョン番号を変更する必要はありません）。
A: Address type. If the A bit is 0, the originating source field contains a 32-bit IPv4 address. If the A bit is 1, the originating source contains a 128-bit IPv6 address.
A：アドレスタイプ。Aが0の場合、発信元のソースフィールドには32ビットIPv4アドレスが含まれています。Aが1の場合、元のソースには128ビットIPv6アドレスが含まれています。
R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST ignore the contents of this field.
R：予約済み。SAPアナウンサーはこれを0に設定する必要があります。SAPリスナーは、このフィールドの内容を無視する必要があります。
T: Message Type. If the T field is set to 0 this is a session announcement packet, if 1 this is a session deletion packet.
T：メッセージタイプ。Tフィールドが0に設定されている場合、これはセッションアナウンスパケットです。これがセッション削除パケットである場合。
E: Encryption Bit. If the encryption bit is set to 1, the payload of the SAP packet is encrypted. If this bit is 0 the packet is not encrypted. See section 7 for details of the encryption process.
E：暗号化ビット。暗号化ビットが1に設定されている場合、SAPパケットのペイロードが暗号化されます。このビットが0の場合、パケットは暗号化されていません。暗号化プロセスの詳細については、セクション7を参照してください。
C: Compressed bit. If the compressed bit is set to 1, the payload is compressed using the zlib compression algorithm [3]. If the payload is to be compressed and encrypted, the compression MUST be performed first.
C：圧縮ビット。圧縮ビットが1に設定されている場合、ZLIB圧縮アルゴリズム[3]を使用してペイロードが圧縮されます。ペイロードを圧縮して暗号化する場合、最初に圧縮を実行する必要があります。
Authentication Length. An 8 bit unsigned quantity giving the number of 32 bit words following the main SAP header that contain authentication data. If it is zero, no authentication header is present.
認証長。認証データを含むメインSAPヘッダーに続く32ビットワードの数を与える8ビットの署名数量。ゼロの場合、認証ヘッダーは存在しません。
Authentication data containing a digital signature of the packet, with length as specified by the authentication length header field. See section 8 for details of the authentication process.
認証長ヘッダーフィールドで指定されている長さのパケットのデジタル署名を含む認証データ。認証プロセスの詳細については、セクション8を参照してください。
Message Identifier Hash. A 16 bit quantity that, used in combination with the originating source, provides a globally unique identifier indicating the precise version of this announcement. The choice of value for this field is not specified here, except that it MUST be unique for each session announced by a particular SAP announcer and it MUST be changed if the session description is modified (and a session deletion message SHOULD be sent for the old version of the session).
メッセージ識別子ハッシュ。発信元のソースと組み合わせて使用される16ビットの数量は、この発表の正確なバージョンを示すグローバルに一意の識別子を提供します。このフィールドの価値の選択はここでは指定されていませんが、特定のSAPアナウンサーによって発表された各セッションで一意でなければならず、セッションの説明が変更された場合は変更する必要があります（そして、古いものに対してセッション削除メッセージを送信する必要がありますセッションのバージョン）。
Earlier versions of SAP used a value of zero to mean that the hash should be ignored and the payload should always be parsed. This had the unfortunate side-effect that SAP announcers had to study the payload data to determine how many unique sessions were being advertised, making the calculation of the announcement interval more complex that necessary. In order to decouple the session announcement process from the contents of those announcements, SAP announcers SHOULD NOT set the message identifier hash to zero.
SAPの以前のバージョンでは、ゼロの値を使用して、ハッシュを無視し、ペイロードを常に解析する必要があることを意味します。これには、SAPアナウンサーがペイロードデータを調査して宣伝されている一意のセッションの数を判断する必要があるという不幸な副作用があり、発表間隔の計算が必要なものをより複雑にしました。これらの発表の内容からセッションアナウンスプロセスを分離するために、SAPアナウンサーはメッセージ識別子ハッシュをゼロに設定してはなりません。
SAP listeners MAY silently discard messages if the message identifier hash is set to zero.
SAPリスナーは、メッセージ識別子ハッシュがゼロに設定されている場合、黙ってメッセージを破棄する場合があります。
Originating Source. This gives the IP address of the original source of the message. This is an IPv4 address if the A field is set to zero, else it is an IPv6 address. The address is stored in network byte order.
発生源。これにより、メッセージの元のソースのIPアドレスが得られます。これは、Aフィールドがゼロに設定されている場合、IPv4アドレスです。そうでなければ、IPv6アドレスです。アドレスはネットワークバイトの順序で保存されます。
SAPv0 permitted the originating source to be zero if the message identifier hash was also zero. This practise is no longer legal, and SAP announcers SHOULD NOT set the originating source to zero. SAP listeners MAY silently discard packets with the originating source set to zero.
SAPV0は、メッセージ識別子ハッシュもゼロである場合、元のソースをゼロにすることを許可しました。この慣行はもはや合法ではなく、SAPアナウンスは発信元のソースをゼロに設定すべきではありません。SAPリスナーは、ゼロに設定されている発信元のソースを備えたパケットを静かに破棄できます。
The header is followed by an optional payload type field and the payload data itself. If the E or C bits are set in the header both the payload type and payload are encrypted and/or compressed.
ヘッダーの後に、オプションのペイロードタイプフィールドとペイロードデータ自体が続きます。EまたはCビットがヘッダーに設定されている場合、ペイロードタイプとペイロードの両方が暗号化および/または圧縮されます。
The payload type field is a MIME content type specifier, describing the format of the payload. This is a variable length ASCII text string, followed by a single zero byte (ASCII NUL). The payload type SHOULD be included in all packets. If the payload type is `application/sdp' both the payload type and its terminating zero byte MAY be omitted, although this is intended for backwards compatibility with SAP v1 listeners only.
ペイロードタイプフィールドは、ペイロードの形式を説明するMIMEコンテンツタイプの仕様です。これは可変長さのASCIIテキスト文字列で、その後にシングルゼロバイト（ASCII nul）が続きます。ペイロードタイプはすべてのパケットに含める必要があります。ペイロードタイプが「アプリケーション/SDP」の場合、ペイロードタイプとその終了ゼロバイトの両方が省略される場合がありますが、これはSAP V1リスナーのみとの逆方向の互換性を目的としています。
The absence of a payload type field may be noted since the payload section of such a packet will start with an SDP `v=0' field, which is not a legal MIME content type specifier.
このようなパケットのペイロードセクションがSDP `v = 0 'フィールドから始まるため、ペイロードタイプのフィールドがないことが記録される場合があります。
All implementations MUST support payloads of type `application/sdp' [4]. Other formats MAY be supported although since there is no negotiation in SAP an announcer which chooses to use a session description format other than SDP cannot know that the listeners are able to understand the announcement. A proliferation of payload types in announcements has the potential to lead to severe interoperability problems, and for this reason, the use of non-SDP payloads is NOT RECOMMENDED.
すべての実装は、タイプ `Application/SDP '[4]のペイロードをサポートする必要があります。SAPに交渉がないため、SDP以外のセッション説明形式を使用することを選択したアナウンサーは、リスナーが発表を理解できることを知ることができません。発表におけるペイロードタイプの急増は、深刻な相互運用性の問題につながる可能性があり、このため、非SDPペイロードの使用は推奨されません。
If the packet is an announcement packet, the payload contains a session description.
パケットがアナウンスパケットの場合、ペイロードにはセッションの説明が含まれています。
If the packet is a session deletion packet, the payload contains a session deletion message. If the payload format is `application/sdp' the deletion message is a single SDP line consisting of the origin field of the announcement to be deleted.
パケットがセッション削除パケットの場合、ペイロードにはセッション削除メッセージが含まれます。ペイロード形式が「アプリケーション/SDP」の場合、削除メッセージは、削除される発表のオリジンフィールドで構成される単一のSDP行です。
It is desirable for the payload to be sufficiently small that SAP packets do not get fragmented by the underlying network. Fragmentation has a loss multiplier effect, which is known to significantly affect the reliability of announcements. It is RECOMMENDED that SAP packets are smaller than 1kByte in length, although if it is known that announcements will use a network with a smaller MTU than this, then that SHOULD be used as the maximum recommended packet size.
SAPパケットが基礎となるネットワークによって断片化されないように、ペイロードが十分に小さくなることが望ましいです。フラグメンテーションには、発表の信頼性に大きく影響することが知られている損失乗数効果があります。SAPパケットの長さは1kbyteよりも小さいことをお勧めしますが、発表がこれよりも小さいMTUのネットワークを使用することが知られている場合、最大推奨パケットサイズとして使用する必要があります。
7 Encrypted Announcements
7つの暗号化されたアナウンス
An announcement is received by all listeners in the scope to which it is sent. If an announcement is encrypted, and many of the receivers do not have the encryption key, there is a considerable waste of bandwidth since those receivers cannot use the announcement they have received. For this reason, the use of encrypted SAP announcements is NOT RECOMMENDED on the global scope SAP group or on administrative scope groups which may have many receivers which cannot decrypt those announcements.
発表は、送信される範囲内のすべてのリスナーによって受け取られます。発表が暗号化され、レシーバーの多くが暗号化キーを持っていない場合、受信機が受け取ったアナウンスを使用できないため、かなりの帯域幅の無駄があります。このため、暗号化されたSAPアナウンスの使用は、グローバルスコープSAPグループまたはこれらの発表を復号化できない多くの受信機がいる可能性のある管理スコープグループでは推奨されません。
The opinion of the authors is that encrypted SAP is useful in special cases only, and that the vast majority of scenarios where encrypted SAP has been proposed may be better served by distributing session details using another mechanism. There are, however, certain scenarios where encrypted announcements may be useful. For this reason, the encryption bit is included in the SAP header to allow experimentation with encrypted announcements.
著者の意見は、暗号化されたSAPは特別なケースのみで有用であり、暗号化されたSAPが提案されているシナリオの大部分は、別のメカニズムを使用してセッションの詳細を配布することにより、より適切に対応できるというものです。ただし、暗号化されたアナウンスが役立つ可能性のある特定のシナリオがあります。このため、暗号化ビットをSAPヘッダーに含めて、暗号化されたアナウンスを実験できるようにします。
This memo does not specify details of the encryption algorithm to be used or the means by which keys are generated and distributed. An additional specification should define these, if it is desired to use encrypted SAP.
このメモでは、使用する暗号化アルゴリズムの詳細や、キーが生成および分布する手段の詳細は指定されていません。暗号化されたSAPを使用する必要がある場合は、追加の仕様を定義する必要があります。
Note that if an encrypted announcement is being announced via a proxy, then there may be no way for the proxy to discover that the announcement has been superseded, and so it may continue to relay the old announcement in addition to the new announcement. SAP provides no mechanism to chain modified encrypted announcements, so it is advisable to announce the unmodified session as deleted for a short time after the modification has occurred. This does not guarantee that all proxies have deleted the session, and so receivers of encrypted sessions should be prepared to discard old versions of session announcements that they may receive. In most cases however, the only stateful proxy will be local to (and known to) the sender, and an additional (local-area) protocol involving a handshake for such session modifications can be used to avoid this problem.
プロキシを介して暗号化された発表が発表されている場合、プロキシが発表が置き換えられていることを発見する方法がない可能性があることに注意してください。したがって、新しい発表に加えて古い発表を中継し続ける可能性があります。SAPは、変更された暗号化されたアナウンスをチェーンするメカニズムを提供しないため、変更が行われてから短時間削除されているため、変更されていないセッションを発表することをお勧めします。これは、すべてのプロキシがセッションを削除したことを保証するものではないため、暗号化されたセッションの受信者は、受け取る可能性のあるセッションアナウンスの古いバージョンを破棄するために準備する必要があります。ただし、ほとんどの場合、唯一のステートフルプロキシは送信者のローカル（および知られている）であり、このようなセッションの変更の握手を含む追加（ローカルエリア）プロトコルを使用して、この問題を回避できます。
Session announcements that are encrypted with a symmetric algorithm may allow a degree of privacy in the announcement of a session, but it should be recognized that a user in possession of such a key can pass it on to other users who should not be in possession of such a key. Thus announcements to such a group of key holders cannot be assumed to have come from an authorized key holder unless there is an appropriate authentication header signed by an authorized key holder. In addition the recipients of such encrypted announcements cannot be assumed to only be authorized key holders. Such encrypted announcements do not provide any real security unless all of the authorized key holders are trusted to maintain security of such session directory keys. This property is shared by the multicast session tools themselves, where it is possible for an un-trustworthy member of the session to pass on encryption keys to un-authorized users. However it is likely that keys used for the session tools will be more short lived than those used for session directories.
対称アルゴリズムで暗号化されたセッションの発表は、セッションの発表である程度のプライバシーを可能にする可能性がありますが、そのようなキーを所有しているユーザーは、それを所有するべきではない他のユーザーに渡すことができることを認識する必要があります。そのような鍵。したがって、そのようなキーホルダーのグループへの発表は、承認されたキーホルダーによって署名された適切な認証ヘッダーがない限り、承認されたキー保有者から来たと想定することはできません。さらに、このような暗号化された発表の受信者は、主要な所有者のみが承認されていると想定することはできません。このような暗号化されたアナウンスは、認定されたすべてのキー保有者がそのようなセッションディレクトリキーのセキュリティを維持するために信頼されない限り、実際のセキュリティを提供しません。このプロパティは、マルチキャストセッションツール自体によって共有されており、セッションの信頼できないメンバーが暗号化キーを無許可ユーザーに渡すことができます。ただし、セッションツールに使用されるキーは、セッションディレクトリに使用されるキーよりも短命になる可能性があります。
Similar considerations should apply when session announcements are encrypted with an asymmetric algorithm, but then it is possible to restrict the possessor(s) of the private key, so that announcements to a key-holder group can not be made, even if one of the untrusted members of the group proves to be un-trustworthy.
セッションの発表が非対称アルゴリズムで暗号化されている場合、同様の考慮事項が適用される必要がありますが、秘密鍵の所有者を制限することができます。グループの信頼されていないメンバーは、信頼できないことが証明されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Auth | |
+-+-+-+-+-+-+-+-+ |
| Format specific authentication subheader |
: .................. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of the authentication data in the SAP header
図2：SAPヘッダーの認証データの形式
8 Authenticated Announcements
8つの認証されたアナウンス
The authentication header can be used for two purposes:
認証ヘッダーは、2つの目的に使用できます。
o Verification that changes to a session description or deletion of a session are permitted.
o セッションの説明またはセッションの削除の変更が許可されていることを確認します。
o Authentication of the identity of the session creator.
o セッション作成者のアイデンティティの認証。
In some circumstances only verification is possible because a certificate signed by a mutually trusted person or authority is not available. However, under such circumstances, the session originator may still be authenticated to be the same as the session originator of previous sessions claiming to be from the same person. This may or may not be sufficient depending on the purpose of the session and the people involved.
状況によっては、相互に信頼された人または権限によって署名された証明書が利用できないため、検証のみが可能です。ただし、そのような状況では、セッションのオリジネーターは、同じ人物からのものであると主張する以前のセッションのセッションオリジネーターと同じであると認証される可能性があります。これは、セッションの目的と関係者に応じて十分である場合とそうでない場合があります。
Clearly the key used for the authentication should not be trusted to belong to the session originator unless it has been separately authenticated by some other means, such as being certified by a trusted third party. Such certificates are not normally included in an SAP header because they take more space than can normally be afforded in an SAP packet, and such verification must therefore take place by some other mechanism. However, as certified public keys are normally locally cached, authentication of a particular key only has to take place once, rather than every time the session directory retransmits the announcement.
明らかに、認証に使用されるキーは、信頼できる第三者によって認定されるなど、他の手段によって個別に認証されていない限り、セッションオリジネーターに属すると信頼されるべきではありません。このような証明書は、通常、SAPパケットで提供できるよりも多くのスペースをとるため、SAPヘッダーに通常含まれていません。したがって、そのような検証は他のメカニズムによって行われなければなりません。ただし、認定されたパブリックキーは通常ローカルでキャッシュされているため、特定のキーの認証は、セッションディレクトリが発表を再送信するたびに、1回だけ行う必要があります。
SAP is not tied to any single authentication mechanism. Authentication data in the header is self-describing, but the precise format depends on the authentication mechanism in use. The generic format of the authentication data is given in figure 2. The structure of the format specific authentication subheader, using both the PGP and the CMS formats, is discussed in sections 8.1 and 8.2 respectively. Additional formats may be added in future.
SAPは、単一の認証メカニズムに関連付けられていません。ヘッダー内の認証データは自己記述的ですが、正確な形式は使用中の認証メカニズムに依存します。認証データの一般的な形式を図2に示します。PGP形式とCMS形式の両方を使用した形式の特定の認証サブヘッダーの構造について、それぞれセクション8.1と8.2で説明します。将来、追加の形式が追加される場合があります。
Version Number, V: The version number of the authentication format specified by this memo is 1.
バージョン番号、V：このメモで指定された認証形式のバージョン番号は1です。
Padding Bit, P: If necessary the authentication data is padded to be a multiple of 32 bits and the padding bit is set. In this case the last byte of the authentication data contains the number of padding bytes (including the last byte) that must be discarded.
パディングビット、P：必要に応じて、認証データは32ビットの倍数にパッドで装飾され、パディングビットが設定されています。この場合、認証データの最後のバイトには、破棄する必要があるパディングバイト（最後のバイトを含む）の数が含まれています。
Authentication Type, Auth: The authentication type is a 4 bit encoded field that denotes the authentication infrastructure the sender expects the recipients to use to check the authenticity and integrity of the information. This defines the format of the authentication subheader and can take the values: 0 = PGP format, 1 = CMS format. All other values are undefined and SHOULD be ignored.
認証タイプ、AUTH：認証タイプは、送信者が情報の信頼性と整合性を確認するために受信者が使用することを期待する認証インフラストラクチャを示す4ビットエンコードフィールドです。これは、認証サブヘッダーの形式を定義し、値を取得できます：0 = PGP形式、1 = CMS形式。他のすべての値は未定義であり、無視する必要があります。
If a SAP packet is to be compressed or encrypted, this MUST be done before the authentication is added.
SAPパケットを圧縮または暗号化する場合、これは認証が追加される前に実行する必要があります。
The digital signature in the authentication data MUST be calculated over the entire packet, including the header. The authentication length MUST be set to zero and the authentication data excluded when calculating the digital signature.
認証データのデジタル署名は、ヘッダーを含むパケット全体で計算する必要があります。認証の長さはゼロに設定し、デジタル署名を計算するときに認証データを除外する必要があります。
It is to be expected that sessions may be announced by a number of different mechanisms, not only SAP. For example, a session description may placed on a web page, sent by email or conveyed in a session initiation protocol. To ease interoperability with these other mechanisms, application level security is employed, rather than using IPsec authentication headers.
SAPだけでなく、セッションがさまざまなメカニズムによって発表される可能性があることが予想されます。たとえば、セッションの説明は、電子メールで送信された、またはセッション開始プロトコルで送信されるWebページに配置される場合があります。これらの他のメカニズムとの相互運用性を容易にするために、IPSEC認証ヘッダーを使用するのではなく、アプリケーションレベルのセキュリティが採用されています。
A full description of the PGP protocol can be found in [2]. When using PGP for SAP authentication the basic format specific authentication subheader comprises a digital signature packet as described in [2]. The signature type MUST be 0x01 which means the signature is that of a canonical text document.
PGPプロトコルの完全な説明は[2]に記載されています。SAP認証にPGPを使用する場合、[2]に記載されているように、基本形式固有の認証サブヘッダーがデジタル署名パケットを構成します。署名タイプは0x01でなければなりません。つまり、署名は標準的なテキストドキュメントのものです。
A full description of the Cryptographic Message Syntax can be found in [6]. The format specific authentication subheader will, in the CMS case, have an ASN.1 ContentInfo type with the ContentType being signedData.
暗号化メッセージの構文の完全な説明は[6]にあります。Format固有の認証サブヘッダーは、CMSの場合、asn.1 contentinfoタイプを持ち、contentTypeはsignedDataです。
Use is made of the option available in PKCS#7 to leave the content itself blank as the content which is signed is already present in the packet. Inclusion of it within the SignedData type would duplicate this data and increase the packet length unnecessarily. In addition this allows recipients with either no interest in the authentication, or with no mechanism for checking it, to more easily skip the authentication information.
PKCS＃7で利用可能なオプションで使用されているため、署名されているコンテンツがパケットに既に存在するため、コンテンツ自体を空白のままにします。SignedDataタイプにそれを含めると、このデータが複製され、パケットの長さが不必要に増加します。さらに、これにより、認証に関心がないか、それをチェックするメカニズムが認証情報をより簡単にスキップできるようになります。
There SHOULD be only one signerInfo and related fields corresponding to the originator of the SAP announcement. The signingTime SHOULD be present as a signedAttribute. However, due to the strict size limitations on the size of SAP packets, certificates and CRLs SHOULD NOT be included in the signedData structure. It is expected that users of the protocol will have other methods for certificate and CRL distribution.
SAP発表の発信者に対応するSignerinfoと関連フィールドは1つだけです。署名時間は署名式として存在する必要があります。ただし、SAPパケットのサイズに厳密なサイズの制限があるため、証明書とCRLはSignedData構造に含まれてはなりません。プロトコルのユーザーには、証明書とCRL分布の他の方法があると予想されます。
9 Scalability and caching
9スケーラビリティとキャッシュ
SAP is intended to announce the existence of long-lived wide-area multicast sessions. It is not an especially timely protocol: sessions are announced by periodic multicast with a repeat rate on the order of tens of minutes, and no enhanced reliability over UDP. This leads to a long startup delay before a complete set of announcements is heard by a listener. This delay is clearly undesirable for interactive browsing of announced sessions.
SAPは、長寿命の広いエリアマルチキャストセッションの存在を発表することを目的としています。これは特にタイムリーなプロトコルではありません。セッションは定期的なマルチキャストによって発表され、数十分の順序で繰り返しレートがあり、UDPに対する信頼性が向上しません。これにより、リスナーが発表する完全な発表が聞こえる前に、長いスタートアップの遅延が発生します。この遅延は、発表されたセッションのインタラクティブなブラウジングでは明らかに望ましくありません。
In order to reduce the delays inherent in SAP, it is recommended that proxy caches are deployed. A SAP proxy cache is expected to listen to all SAP groups in its scope, and to maintain an up-to-date list of all announced sessions along with the time each announcement was last received. When a new SAP listeners starts, it should contact its local proxy to download this information, which is then sufficient for it to process future announcements directly, as if it has been continually listening.
SAPに固有の遅延を減らすために、プロキシキャッシュを展開することをお勧めします。SAPプロキシキャッシュは、その範囲内のすべてのSAPグループに耳を傾け、各発表が最後に受信された時間とともに、発表されたすべてのセッションの最新リストを維持することが期待されます。新しいSAPリスナーが開始すると、ローカルプロキシに連絡してこの情報をダウンロードする必要があります。これにより、将来のアナウンスが直接継続的に聞いているかのように直接処理するのに十分です。
The protocol by which a SAP listener contacts its local proxy cache is not specified here.
SAPリスナーがローカルプロキシキャッシュに接触するプロトコルは、ここでは指定されていません。
10 Security Considerations
10のセキュリティ上の考慮事項
SAP contains mechanisms for ensuring integrity of session announcements, for authenticating the origin of an announcement and for encrypting such announcements (sections 7 and 8).
SAPには、セッションアナウンスの完全性を確保するためのメカニズム、発表の起源を認証し、そのような発表を暗号化するためのメカニズムが含まれています（セクション7および8）。
As stated in section 5, if a session modification announcement is received that contains a valid authentication header, but which is not signed by the original creator of the session, then the session must be treated as a new session in addition to the original session with the same SDP origin information unless the originator of one of the session descriptions can be authenticated using a certificate signed by a trusted third party. If this were not done, there would be a possible denial of service attack whereby a party listens for new announcements, strips off the original authentication header, modifies the session description, adds a new authentication header and re-announces the session. If a rule was imposed that such spoof announcements were ignored, then if packet loss or late starting of a session directory instance caused the original announcement to fail to arrive at a site, but the spoof announcement did so, this would then prevent the original announcement from being accepted at that site.
セクション5で述べたように、有効な認証ヘッダーを含むがセッションの元の作成者によって署名されていないセッション修正アナウンスが受信された場合、セッションは、元のセッションに加えて新しいセッションとして扱わなければなりません。セッションの説明の1つの創始者が、信頼できる第三者によって署名された証明書を使用して認証できる場合を除き、同じSDP起源の情報。これが行われなかった場合、当事者が新しい発表のために耳を傾け、元の認証ヘッダーを取り除き、セッションの説明を変更し、新しい認証ヘッダーを追加し、セッションを再発表する可能性のあるサービス攻撃の可能性があります。そのようなスプーフィングアナウンスが無視されているというルールが課された場合、セッションディレクトリインスタンスのパケットの損失または遅い開始により、当初の発表がサイトに到着できなかったが、スプーフィングの発表はそうしました、これは元の発表を妨げますそのサイトで受け入れられることから。
A similar denial-of-service attack is possible if a session announcement receiver relies completely on the originating source and hash fields to indicate change, and fails to parse the remainder of announcements for which it has seen the origin/hash combination before.
セッションアナウンスレシーバーが、変化を示すために発信元のソースとハッシュフィールドに完全に依存している場合、同様のサービス拒否攻撃が可能であり、以前に起源/ハッシュの組み合わせを見た残りの発表を解析できません。
A denial of service attack is possible from a malicious site close to a legitimate site which is making a session announcement. This can happen if the malicious site floods the legitimate site with huge numbers of (illegal) low TTL announcements describing high TTL sessions. This may reduce the session announcement rate of the legitimate announcement to below a tenth of the rate expected at remote sites and therefore cause the session to time out. Such an attack is likely to be easily detectable, and we do not provide any mechanism here to prevent it.
セッションの発表を行っている合法的なサイトに近い悪意のあるサイトから、サービス拒否攻撃が可能です。これは、悪意のあるサイトが正当なサイトに、高いTTLセッションを説明する膨大な数の（違法な）低TTLアナウンスであふれている場合に発生する可能性があります。これにより、合法的な発表のセッションアナウンス率が、リモートサイトで予想されるレートの10分の1を下回るため、セッションのタイムアウトを引き起こす可能性があります。このような攻撃は簡単に検出できる可能性が高く、ここでそれを防ぐためのメカニズムを提供しません。
A. Summary of differences between SAPv0 and SAPv1
A. SAPV0とSAPV1の違いの概要
For this purpose SAPv0 is defined as the protocol in use by version 2.2 of the session directory tool, sdr. SAPv1 is the protocol described in the 19 November 1996 version of this memo. The packet headers of SAP messages are the same in V0 and V1 in that a V1 tool can parse a V0 announcement header but not vice-versa. In SAPv0, the fields have the following values:
このため、SAPV0は、セッションディレクトリツールSDRのバージョン2.2で使用されているプロトコルとして定義されます。SAPV1は、このメモの1996年11月19日バージョンで説明されているプロトコルです。SAPメッセージのパケットヘッダーは、V0とV1で同じです。V1ツールはV0アナウンスヘッダーを解析できますが、その逆ではありません。SAPV0では、フィールドには次の値があります。
o Version Number: 0
o バージョン番号：0
o Message Type: 0 (Announcement)
o メッセージタイプ：0（発表）
o Authentication Type: 0 (No Authentication)
o 認証タイプ：0（認証なし）
o Encryption Bit: 0 (No Encryption)
o 暗号化ビット：0（暗号化なし）
o Compression Bit: 0 (No compression)
o 圧縮ビット：0（圧縮なし）
o Message Id Hash: 0 (No Hash Specified)
o メッセージIDハッシュ：0（ハッシュが指定されていません）
o Originating Source: 0 (No source specified, announcement has not been relayed)
o 発信元：0（ソースが指定されておらず、発表が中継されていません）
B. Summary of differences between SAPv1 and SAPv2
B. SAPV1とSAPV2の違いの概要
The packet headers of SAP messages are the same in V1 and V2 in that a V2 tool can parse a V1 announcement header but not necessarily vice-versa.
SAPメッセージのパケットヘッダーは、V1とV2で同じです。V2ツールはV1アナウンスヘッダーを解析できますが、必ずしもその逆ではありません。
o The A bit has been added to the SAP header, replacing one of the bits of the SAPv1 message type field. If set to zero the announcement is of an IPv4 session, and the packet is backwards compatible with SAPv1. If set to one the announcement is of an IPv6 session, and SAPv1 listeners (which do not support IPv6) will see this as an illegal message type (MT) field.
o SAPヘッダーに少し追加され、SAPV1メッセージタイプフィールドのビットの1つを置き換えました。ゼロに設定されている場合、アナウンスはIPv4セッションであり、パケットはSAPV1と逆方向に互換性があります。1つに設定されている場合、発表はIPv6セッションのものであり、SAPV1リスナー（IPv6をサポートしていない）は、これを違法なメッセージタイプ（MT）フィールドと見なします。
o The second bit of the message type field in SAPv1 has been replaced by a reserved, must-be-zero, bit. This bit was unused in SAPv1, so this change just codifies existing usage.
o SAPV1のメッセージタイプフィールドの2番目のビットは、予約済みの必須ゼロに置き換えられました。このビットはSAPV1で使用されていなかったため、この変更は既存の使用法を成文化するだけです。
o SAPv1 specified encryption of the payload. SAPv2 includes the E bit in the SAP header to indicate that the payload is encrypted, but does not specify any details of the encryption.
o SAPV1は、ペイロードの暗号化を指定しました。SAPV2には、Payloadが暗号化されているが、暗号化の詳細を指定していないことを示すために、SAPヘッダーにEビットが含まれています。
o SAPv1 allowed the message identifier hash and originating source fields to be set to zero, for backwards compatibility. This is no longer legal.
o SAPV1により、メッセージ識別子ハッシュと発信元のソースフィールドをゼロに設定して、後方互換性を許可しました。これはもはや合法ではありません。
o SAPv1 specified gzip compression. SAPv2 uses zlib (the only known implementation of SAP compression used zlib, and gzip compression was a mistake).
o SAPV1はGZIP圧縮を指定しました。SAPV2はZLIBを使用します（ZLIBを使用したSAP圧縮の唯一の既知の実装であり、GZIP圧縮は間違いでした）。
o SAPv2 provides a more complete specification for authentication.
o SAPV2は、認証のためのより完全な仕様を提供します。
o SAPv2 allows for non-SDP payloads to be transported. SAPv1 required that the payload was SDP.
o SAPV2を使用すると、非SDPペイロードを輸送できます。SAPV1は、ペイロードがSDPであることを要求しました。
o SAPv1 included a timeout field for encrypted announcement, SAPv2 does not (and relies of explicit deletion messages or implicit timeouts).
o SAPV1には、暗号化された発表のためのタイムアウトフィールドが含まれています。SAPV2は、明示的な削除メッセージまたは暗黙のタイムアウトに依存していません）。
C. Acknowledgements
C.謝辞
SAP and SDP were originally based on the protocol used by the sd session directory from Van Jacobson at LBNL. Version 1 of SAP was designed by Mark Handley as part of the European Commission MICE (Esprit 7602) and MERCI (Telematics 1007) projects. Version 2 includes authentication features developed by Edmund Whelan, Goli Montasser-Kohsari and Peter Kirstein as part of the European Commission ICE-TEL project (Telematics 1005), and support for IPv6 developed by Maryann P. Maher and Colin Perkins.
SAPとSDPは、もともとLBNLのVan JacobsonのSDセッションディレクトリで使用されているプロトコルに基づいていました。SAPのバージョン1は、欧州委員会のマウス（Esprit 7602）およびMerci（Telematics 1007）プロジェクトの一部としてMark Handleyによって設計されました。バージョン2には、欧州委員会のICE-TELプロジェクト（Telematics 1005）の一環として、Edmund Whelan、Goli Montasser-Kohsari、Peter Kirsteinが開発した認証機能と、Maryann P. MaherとColin Perkinsが開発したIPv6のサポートが含まれています。
D. Authors' Addresses
D.著者の住所
Mark Handley AT&T Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
マークハンドリーAT＆TセンターICSIのインターネット研究センター、国際コンピューターサイエンス研究所、1947年センターストリート、スイート600、バークレー、カリフォルニア州94704、米国
EMail: mjh@aciri.org
Colin Perkins USC Information Sciences Institute 4350 N. Fairfax Drive, Suite 620 Arlington, VA 22203, USA
Colin Perkins USC Information Sciences Institute 4350 N. Fairfax Drive、Suite 620 Arlington、VA 22203、USA
EMail: csp@isi.edu
Edmund Whelan Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, UK
エドマンド・ウィーラン・コンピュータサイエンス局、ユニバーシティカレッジロンドン、ガワーストリート、ロンドン、WC1E 6BT、英国
EMail: e.whelan@cs.ucl.ac.uk
References
参考文献
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer. "OpenPGP message format", RFC 2440, November 1998.
[2] Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer。「OpenPGPメッセージフォーマット」、RFC 2440、1998年11月。
[3] Deutsch, P. and J.-L. Gailly, "Zlib compressed data format specification version 3.3", RFC 1950, May 1996.
[3] Deutsch、P。およびJ.-L。Gailly、「Zlib圧縮データ形式の仕様バージョン3.3」、RFC 1950、1996年5月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[5] Handley, M., Thaler, D. and R. Kermode, "Multicast-scope zone announcement protocol (MZAP)", RFC 2776, February 2000.
[5] Handley、M.、Thaler、D。、およびR. Kermode、「マルチキャストスコープゾーンアナウンスアナウンスプロトコル（MZAP）」、RFC 2776、2000年2月。
[6] Housley, R., "Cryptographic message syntax", RFC 2630, June 1999.
[6] Housley、R。、「暗号化メッセージ構文」、RFC 2630、1999年6月。
[7] Mayer, D., "Administratively scoped IP multicast", RFC 2365, July 1998.
[7] Mayer、D。、「管理上スコープIPマルチキャスト」、RFC 2365、1998年7月。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。