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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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].
キーワード `MUST '` MUST NOT'、 `REQUIRED '`ものと'、 `SHALL NOT '` SHOULD'、 ` '`推奨' べきではない、 `MAY 'そして` OPTIONAL' この文書に記載されています[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).
（224.2.127.255が廃止SAPv0によって使用され、使用してはならないことに注意）224.2.127.254に送信されるSAPアナウンスと224.2.255.255 - IPv4グローバルスコープセッションは範囲224.2.128.0でマルチキャストアドレスを使用します。
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、次いで、239.16.33.255は、SAPアナウンスのために使用されます。
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：2：Xは、4ビットの範囲の値である7FFE。例えば、リンクローカルセッションの発表は、アドレスFF02を割り当て：0：0：0：0：0：1234：5678、SAPアドレスFF02に公示しなければならない：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上で送信されなければならないとIPとの時間をツーライブ送信されるべきである255の（マルチキャスト用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起点フィールドによって識別される）同じセッションのような複数のアナウンスメントを解析するリスナーまでです。複数のアナウンスは別個であるかのように、各管理スコープ範囲の発表率は、別々に計算しなければなりません。
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.
複数のアナウンサーは、一つ以上のアナウンサーのパケット損失および障害の面におけるロバスト性の補助として、単一のセッションをアナウンスすることができます。各アナウンサーがそのアナウンスを繰り返し速度は、全発表率は、単一のサーバが選択するであろうものに等しくなるように縮小しなければなりません。このようにして作られたアナウンスは同じでなければなりません。
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グループのすべての発表で使用される総帯域幅は、事前設定された限界以下のままであるように選択されます。特に指定しない場合、帯域幅の制限は、毎秒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)
間隔= MAX（300;（8 * no_of_ads * ad_size）/限界）
offset= rand(interval* 2/3)-(interval/3)
（インターバル/ 3） - =ランド（間隔* 2/3）オフセット
tn =tp+ interval+ offset
TN = TP +間隔+オフセット
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のために再スケジュールされています。この見直しは、スタートアップとするときネットワークパーティションが治癒に過渡パケットバーストを防ぐことができます。
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.
明示的な削除は、セッション削除パケットを削除するセッションを指定して受信します。セッション削除パケットは、以前の発表パケットを認証するために使用される有効な認証ヘッダ、マッチングを持つべきである（SHOULD）。この認証が欠落している場合は、削除メッセージは無視されるべきです。
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.
アナウンスは、認証ヘッダを含む受信され、キャッシュされたアナウンスは、認証ヘッダが含まれていなかった、またはそれが異なる認証ヘッダが含まれている場合、次いで変性発表は新しいと異なる発表として扱われ、未に加えて表示されなければなりません発表を認証されました。認証ヘッダなしで変更されたパケットは、元の発表とは異なるソースから受信された場合にも同じことが起こるべきです。
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：バージョン番号。バージョン番号フィールドは、（のみSAPv1機能を使用SAPv2アナウンスは、SAPのバージョン番号を変更する必要がないように、新しい機能を使用するものは、他の手段によって検出することができ、下位互換性がある）を1に設定しなければなりません。
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：アドレスタイプ。ビットが0である場合、元のソース・フィールドは、32ビットのIPv4アドレスを含みます。ビットが1であれば、発信源は、128ビットのIPv6アドレスを含んでいます。
R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST ignore the contents of this field.
R：予約済み。 SAPのアナウンサーは、SAPのリスナーはこのフィールドの内容を無視しなければなりません、これを0に設定しなければなりません。
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に設定されている場合は1、これはセッション削除パケットの場合、これは、そのセッションの発表パケットです。
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アドレスを提供します。フィールドがゼロに設定されている場合、これは、IPv6アドレスである他、IPv4アドレスです。アドレスはネットワークバイト順に格納されます。
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 NUL）、続いて可変長ASCIIテキスト文字列です。ペイロードタイプは、すべてのパケットに含まれるべきです。ペイロードタイプが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.
そのようなパケットのペイロード部が法的MIMEコンテンツタイプ指定子ない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.
すべての実装は、SDPタイプ `アプリケーション/」のペイロードをサポートしなければならない[4]。何の交渉はSDPは、リスナーが発表を理解することができることを知ることができないよりも、他のセッションの記述形式を使用することを選択したアナウンサーがSAPに存在しないので、他のフォーマットがサポートされるかもしれません。発表では、ペイロードタイプの増殖が深刻な相互運用性の問題につながる可能性を秘めている、そしてこのような理由のために、非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
ペイロードは、SAPパケットは、基礎となるネットワークによって断片化されませんので、十分に小さいであることが望ましいです。断片化は大幅に発表の信頼性に影響を与えることが知られている損失乗数効果を持っています。それはあります
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.
それはアナウンスがこれよりも小さいMTUでネットワークを使用することが知られている場合、それは推奨される最大パケットサイズとして使用されるべきであるSAPパケットは、長さが1Kバイトよりも小さいことをお勧めします。
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グループの信頼されていないメンバーは、非信頼できることが証明されています。
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ヘッダーに含まれていない、そして、そのような検証は、したがって、他のいくつかのメカニズムによって行われなければなりません。認定された公開鍵は、通常、ローカルにキャッシュされているようしかし、特定のキーの認証はのみではなく、セッションディレクトリが発表を再送するたびに比べて、一回行われなければなりません。
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.
認証タイプ、認証：認証タイプは、送信者は受信者が情報の真正性および完全性をチェックするために使用する予定の認証インフラストラクチャを表す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が発表されることが予想されます。例えば、セッション記述は、電子メールによって送信されたウェブページ上に配置され得るか、またはセッション開始プロトコルに搬送されます。これらの他の機構との相互運用性を容易にするために、アプリケーションレベルのセキュリティではなく、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]に見出すことができます。形式特定の認証サブヘッダは、CMSの場合には、ContentTypeをされたsignedDataとASN.1 ContentInfoタイプを持っています。
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の発表の発信元に対応して1個のみのSignerInfoおよび関連分野があるはずです。 signingTimeはsignedAttributeとして存在すべきです。しかし、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で述べたようにセッション変更通知が有効な認証ヘッダが含まれて受信されるが、セッションの元の作成者によって署名されていない場合、セッションは、元のセッションに加えて、新しいセッションとして処理されなければなりませんセッション記述の一つの創始者でない限り、同じ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発表の膨大な数で合法的なサイトをフラッディング場合に発生します。これは、セッションがタイムアウトになり、リモートサイトで、したがって、期待収益率の第十以下に合法的な発表のセッション告知率を減らすことができます。このような攻撃は容易に検出可能性がある、と我々はそれを防ぐために、ここで任意のメカニズムを提供しません。
A. Summary of differences between SAPv0 and SAPv1
SAPv0とSAPv1の違いA.概要
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メッセージのパケットヘッダは、V1ツールがV0発表ヘッダはなく、その逆を解析することができるという点で、V0とV1は同じです。 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
SAPv1とSAPv2間の違いのB.概要
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ツールでV1とV2で同じであるが、必ずしもその逆です。
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ビットはSAPv1メッセージタイプフィールドのビットの1つ置き換え、SAPヘッダに追加されています。アナウンスをゼロに設定した場合のIPv4セッションのものであり、パケットはSAPv1との下位互換性があります。 1に設定すると発表は、IPv6セッションのものであり、（IPv6をサポートしていません）SAPv1リスナーは違法なメッセージタイプ（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は、ペイロードが暗号化されていることを示すために、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使用（SAP圧縮用いZLIBの唯一の既知の実装、および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でのバン・ジェイコブソンからのsdセッションディレクトリで使用されるプロトコルに基づいていました。 SAPのバージョン1は、欧州委員会のMICE（エスプリ7602）とMERCI（テレマティクス1007）のプロジェクトの一環として、マーク・ハンドリーによって設計されました。バージョン2は、マリアンP.マヘルとコリンパーキンスによって開発された認証欧州委員会ICE-TELプロジェクト（テレマティクス1005）の一環としてエドマンド・ウィーラン、ゴリMontasser-Kohsariとピーター・カースティンによって開発された機能、および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
ICSI、国際コンピュータサイエンス研究所、1947センターストリート、スイート600、バークレー、CA 94704、USAでのインターネットリサーチのためのマーク・ハンドリーAT＆Tセンター
EMail: mjh@aciri.org
メールアドレス：mjh@aciri.org
Colin Perkins USC Information Sciences Institute 4350 N. Fairfax Drive, Suite 620 Arlington, VA 22203, USA
コリン・パーキンスUSC情報科学研究所4350 N.フェアファックスドライブ、スイート620アーリントン、VA 22203、USA
EMail: csp@isi.edu
メールアドレス：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
メールアドレス：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]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月を。
[2] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer. "OpenPGP message format", RFC 2440, November 1998.
[2]カラス、J.、Donnerhacke、L.、フィニー、H.及びR.セイヤー。 "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]ドイツ、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]ハンドレー、M.および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]ハンドレー、M.、ターラー、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]メイヤー、D.は、RFC 2365、1998年7月、 "管理上のIPマルチキャストスコープ"。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。