[要約] RFC 3396は、DHCPv4で長いオプションをエンコードする方法を提案しています。目的は、DHCPv4メッセージに長いオプションを含めるための標準化と互換性の向上です。

Network Working Group                                           T. Lemon
Request for Comments: 3396                                 Nominum, Inc.
Updates: 2131                                                S. Cheshire
Category: Standards Track                           Apple Computer, Inc.
                                                           November 2002
        

Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)

ダイナミックホスト構成プロトコル(DHCPV4)の長いオプションのエンコード

Status of this Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の現在のエディションを参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2002). All Rights Reserved.

Copyright(c)The Internet Society(2002)。無断転載を禁じます。

Abstract

概要

This document specifies the processing rules for Dynamic Host Configuration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing.

このドキュメントは、同じメッセージに複数回表示される動的ホスト構成プロトコル(DHCPV4)オプションの処理ルールを指定します。同じオプションの複数のインスタンスは、オプションのサイズが255オクターを超えている場合(単一のオプションの最大サイズ)、またはDHCPオプションのオーバーロードを活用するためにオプションを分割する必要がある場合に生成されます。同じオプションの複数のインスタンスがオプション、ファイルフィールド、および/またはSNAMEフィールドにDHCPパケットに表示されると、これらのオプションの内容が連結されて、処理する前に単一のオプションを形成します。

1. Introduction
1. はじめに

This document updates RFC 2131 [3] by clarifying the rules for option concatenation specified in section 4.1. It is expected that the reader will be familiar with this portion of RFC 2131. The text in section 4.1 that reads "Options may appear only once, unless otherwise specified in the options document." should be considered as deleted.

このドキュメントは、セクション4.1で指定されたオプション連結のルールを明確にすることにより、RFC 2131 [3]を更新します。読者は、RFC 2131のこの部分に精通していることが期待されています。「オプションは、オプションドキュメントで特に指定されていない限り、オプションが一度だけ表示される可能性がある」と書かれたセクション4.1のテキストを読み取ります。削除されたと見なす必要があります。

The DHCP protocol [3] specifies objects called "options" that are encoded in the DHCPv4 packet to pass information between DHCP protocol agents. These options are encoded as a one-byte type code, a one-byte length, and a buffer consisting of the number of bytes specified in the length, from zero to 255.

DHCPプロトコル[3]は、DHCPプロトコルエージェント間で情報を渡すためにDHCPV4パケットにエンコードされた「オプション」と呼ばれるオブジェクトを指定します。これらのオプションは、ゼロから255の長さで指定されたバイト数で構成される1バイトタイプコード、1バイトの長さ、およびバッファーとしてエンコードされます。

However, in some cases it may be useful to send options that are longer than 255 bytes. RFC 2131 [3] specifies that when more than one option with a given type code appears in the DHCP packet, all such options should be concatenated together. It does not, however, specify the order in which this concatenation should occur.

ただし、場合によっては、255バイトより長いオプションを送信すると便利かもしれません。RFC 2131 [3]は、特定のタイプコードを持つ複数のオプションがDHCPパケットに表示される場合、そのようなオプションはすべて連結する必要があることを指定します。ただし、この連結が発生する順序は指定されていません。

We specify here the ordering that MUST be used by DHCP protocol agents when sending options with more than 255 bytes. This method also MUST be used for splitting options that are shorter than 255 bytes, if for some reason the encoding agent needs to do so. DHCP protocol agents MUST use this method whenever they receive a DHCP packet containing more than one occurrence of a certain type of option.

ここでは、255バイト以上のオプションを送信する際にDHCPプロトコルエージェントが使用する必要がある順序を指定します。この方法は、エンコーディングエージェントがそうする必要がある場合、255バイトより短いオプションを分割するためにも使用する必要があります。DHCPプロトコルエージェントは、特定のタイプのオプションの複数の発生を含むDHCPパケットを受け取るときはいつでもこの方法を使用する必要があります。

2. Terminology
2. 用語

DHCP Throughout this document, the acronym "DHCP" is used to refer to the Dynamic Host Configuration Protocol as specified in RFC 2131 [3] and RFC 2132 [4].

DHCPこのドキュメント全体で、「DHCP」という頭字語は、RFC 2131 [3]およびRFC 2132 [4]で指定されている動的ホスト構成プロトコルを参照するために使用されます。

DHCPv4 We have used the term "DHCPv4" in the abstract for this document to distinguish between the DHCP protocol for IPv4 as defined in RFC 2131 and RFC 2132 and the DHCP protocol for IPv6, which, at the time that this document was written, was still under development.

dhcpv4このドキュメントの要約で「DHCPV4」という用語を使用して、RFC 2131とRFC 2132で定義されているIPv4のDHCPプロトコルと、このドキュメントが書かれたIPv6のDHCPプロトコルを区別しました。まだ開発中です。

DHCP protocol agents This refers to any device on the network that sends or receives DHCP packets - any DHCP client, server or relay agent. The nature of these devices is not important to this specification.

DHCPプロトコルエージェントこれは、DHCPパケット(DHCPクライアント、サーバー、またはリレーエージェント)を送信または受信するネットワーク上の任意のデバイスを指します。これらのデバイスの性質は、この仕様にとって重要ではありません。

Encoding agent The DHCP protocol agent that is composing a DHCP packet to send.

エンコードエージェント送信するDHCPパケットを構成しているDHCPプロトコルエージェント。

Decoding agent The DHCP protocol agent that is processing a DHCP packet it has received.

デコードエージェント受信したDHCPパケットを処理しているDHCPプロトコルエージェント。

Options DHCP options are collections of data with type codes that indicate how the options should be used. Options can specify information that is required for the DHCP protocol, IP stack configuration parameters for the client, information allowing the client to rendezvous with DHCP servers, and so on.

オプションDHCPオプションは、オプションの使用方法を示すタイプコードを備えたデータのコレクションです。オプションでは、DHCPプロトコル、クライアントのIPスタック構成パラメーター、クライアントがDHCPサーバーでランデブーできるようにする情報などに必要な情報を指定できます。

Option overload The DHCP packet format is based on the BOOTP packet format defined in RFC 951 [1]. When used by DHCP protocol agents, BOOTP packets have three fields that can contain options. These are the optional parameters field, the sname field, and the filename field. The DHCP options specification [4] defines the DHCP Overload option, which specifies which of these three fields is actually being used in any given DHCP message to store DHCP options.

オプションオーバーロードDHCPパケット形式は、RFC 951 [1]で定義されているBOOTPパケット形式に基づいています。DHCPプロトコルエージェントが使用する場合、BOOTPパケットにはオプションを含めることができる3つのフィールドがあります。これらは、オプションのパラメーターフィールド、スナムフィールド、およびファイル名フィールドです。DHCPオプションの仕様[4]は、DHCPオプションを保存するために特定のDHCPメッセージで実際に使用されているこれらの3つのフィールドのどれが実際に使用されているDHCP過負荷オプションを定義します。

3. Requirements Language
3. 要件言語

In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in BCP 14, RFC 2119 [2].

このドキュメントでは、キーワード「可能性があります」、「必要はない」、「オプション」、「推奨」、「必要」、「必要はありません」は、BCP 14、RFC 2119で説明されているように解釈されます[2]。

4. Applicability
4. 適用可能性

This specification applies when a DHCP agent is encoding a packet containing options, where some of those options must be broken into parts. This need can occur for two reasons. First, it can occur because the value of an option that needs to be sent is longer than 255 bytes. In this case, the encoding agent MUST follow the algorithm specified here. It can also occur because there is not sufficient space in the current output buffer to store the option, but there is space for part of the option, and there is space in another output buffer for the rest. In this case, the encoding agent MUST either use this algorithm or not send the option at all.

この仕様は、DHCPエージェントがオプションを含むパケットをエンコードしている場合に適用されます。これらのオプションの一部をパーツに分割する必要があります。この必要性は2つの理由で発生する可能性があります。まず、送信する必要があるオプションの値が255バイトより長いために発生する可能性があります。この場合、エンコーディングエージェントはここで指定されているアルゴリズムに従う必要があります。また、現在の出力バッファーにオプションを保存するのに十分なスペースがないために発生する可能性がありますが、オプションの一部のためのスペースがあり、残りには別の出力バッファーにスペースがあります。この場合、エンコーディングエージェントはこのアルゴリズムを使用するか、オプションをまったく送信しないかどうかを確認する必要があります。

This specification also applies in any case where a DHCP protocol agent has received a DHCP packet that contains more than one instance of an option of a given type. In this case, the agent MUST concatenate these separate instances of the same option in the way that we specify here.

この仕様は、DHCPプロトコルエージェントが特定のタイプのオプションの複数のインスタンスを含むDHCPパケットを受信した場合にも適用されます。この場合、エージェントは、ここで指定する方法で、同じオプションのこれらの個別のインスタンスを連結する必要があります。

This option updates the Dynamic Host Configuration Protocol [3] and DHCP Options and BOOTP vendor extensions [4] documents. However, because many currently-deployed DHCP protocol agents do not implement option concatenation, DHCP protocol agents should be careful not to transmit split options unless either it will not matter if the recipient cannot correctly reassemble the options, or it is certain that the recipient implements concatenation.

このオプションは、動的ホスト構成プロトコル[3]およびDHCPオプションとBOOTPベンダー拡張[4]ドキュメントを更新します。ただし、現在展開されているDHCPプロトコルエージェントがオプションの連結を実装していないため、DHCPプロトコルエージェントは、受信者がオプションを正しく再組み立てできないか、または受信者が実装しているかどうかは関係ない場合を除き、分割オプションを送信しないように注意する必要があります。連結。

Let us divide all DHCP options into two categories - those that, by definition, require implementation of the mechanisms defined in this document, and those that do not. We will refer to the former as concatenation-requiring options, and the latter as non-concatenation-requiring options. In order for an option to be a concatenation-requiring option, the protocol specification that defines that option must require implementation of option splitting and option concatenation as described in this document, by specifically referencing this document.

すべてのDHCPオプションを2つのカテゴリに分割しましょう。定義上、このドキュメントで定義されているメカニズムの実装とそうでないカテゴリが必要なカテゴリです。前者を連結解除オプションと呼び、後者は非cant療法を要求するオプションと呼びます。オプションが連結解除オプションであるために、このドキュメントを具体的に参照することにより、このドキュメントで説明されているようにオプションの分割とオプションの連結の実装が必要であることを定義するプロトコル仕様。

A DHCP protocol agent SHOULD NOT split an option as described in this document unless it has no choice, or it knows that its peer can properly handle split options. A peer is assumed to properly handle split options if it has provided or requested at least one concatenation-requiring option. Alternatively, the administrator of the agent generating the option can specifically configure the agent to assume that the recipient can correctly concatenate options split as described in this document.

DHCPプロトコルエージェントは、選択肢がない場合を除き、このドキュメントで説明されているようにオプションを分割してはなりません。または、ピアが分割オプションを適切に処理できることがわかっています。ピアは、少なくとも1つの連結要求オプションを提供または要求した場合、分割オプションを適切に処理すると想定されます。あるいは、オプションを生成するエージェントの管理者は、このドキュメントで説明されているように、受信者が分割されたオプションを正しく連結できると仮定するようにエージェントを特別に構成できます。

Some implementors may find it easiest to only split concatenation-requiring options, and never split non-concatenation-requiring options. This is permissible. However, an implementation which supports any concatenation-requiring option MUST be capable of concatenating received options for both concatenation-requiring and non-concatenation-requiring options.

一部の実装者は、連結解除オプションを分割するだけで最も簡単であると感じる場合があり、非結合を回避するオプションを分割することはありません。これは許容されます。ただし、連結要求オプションをサポートする実装は、連結要求と非canate式の要求オプションの両方の受信オプションを連結することができなければなりません。

No restrictions apply to option concatenation when a DHCP agent receives a DHCP message. Any DHCP protocol agent that implements the mechanisms described in this document can assume that when it receives two options of the same type, it should concatenate them.

DHCPエージェントがDHCPメッセージを受信した場合、オプション連結に制限は適用されません。このドキュメントで説明されているメカニズムを実装するDHCPプロトコルエージェントは、同じタイプの2つのオプションを受信すると、それらを連結する必要があると想定できます。

5. The Aggregate Option Buffer
5. 集約オプションバッファー

DHCP options can be stored in the DHCP packet in three separate portions of the packet. These are the optional parameters field, the sname field, and the file field, as described in RFC 2131 [3]. This complicates the description of the option splitting mechanism because there are three separate fields into which split options may be placed.

DHCPオプションは、パケットの3つの別々の部分にDHCPパケットに保存できます。これらは、RFC 2131 [3]で説明されているように、オプションのパラメーターフィールド、Snameフィールド、およびファイルフィールドです。これにより、オプションの分割メカニズムの説明が複雑になります。これは、分割オプションを配置できる3つの個別のフィールドがあるためです。

To further complicate matters, an option that doesn't fit into one field can't overlap the boundary into another field - the encoding agent must instead break the option into two parts and store one part in each buffer.

さらに複雑な問題を複雑にするために、あるフィールドに収まらないオプションは境界を別のフィールドに重複させることはできません。エンコーディングエージェントは、オプションを2つの部分に分割し、各バッファーに1つの部品を保存する必要があります。

To simplify this discussion, we will talk about an aggregate option buffer, which will be the aggregate of the three buffers. This is a logical aggregation - the buffers MUST appear in the locations in the DHCP packet described in RFC 2131 [3].

この議論を簡素化するために、3つのバッファーの集合体となる集約オプションバッファーについて説明します。これは論理的な集約です - バッファーは、RFC 2131 [3]で説明されているDHCPパケットの場所に表示する必要があります。

The aggregate option buffer is made up of the optional parameters field, the file field, and the sname field, in that order.

集約オプションバッファーは、オプションのパラメーターフィールド、ファイルフィールド、およびSnameフィールドで構成されています。

WARNING: This is not the physical ordering of these fields in the DHCP packet.

警告:これは、DHCPパケット内のこれらのフィールドの物理的な順序ではありません。

Options MUST NOT be stored in the aggregate option buffer in such a way that they cross either boundary between the three fields in the aggregate buffer.

アグリゲートバッファー内の3つのフィールド間のいずれかの境界を通過するように、オプションを集計オプションバッファーに保存してはなりません。

The encoding agent is free to choose to use either or both the sname field and file field. If the encoding agent does not choose to use either or both of these two fields, then they MUST NOT be considered part of the aggregate option buffer in that case.

エンコーディングエージェントは、Snameフィールドとファイルフィールドのいずれかまたは両方を使用することを自由に選択できます。エンコーディングエージェントがこれら2つのフィールドのいずれかまたは両方を使用することを選択しない場合、その場合、それらは集約オプションバッファーの一部と見なされてはなりません。

6. Encoding Agent Behavior
6. エンコードエージェントの動作

Encoding agents decide to split options based on the reasons we have described in the preceding section entitled "applicability".

エンコーディングエージェントは、「適用可能性」と題された前のセクションで説明した理由に基づいてオプションを分割することを決定します。

Options can be split on any octet boundary. No split portion of an option that has been split can contain more than 255 octets. The split portions of the option MUST be stored in the aggregate option buffer in sequential order - the first split portion MUST be stored first in the aggregate option buffer, then the second portion, and so on. The encoding agent MUST NOT attempt to specify any semantic information based on how the option is split.

オプションは、任意のオクテットの境界で分割できます。分割されたオプションの分割部分は、255以上のオクテットを含めることができません。オプションの分割部分は、総合的な順序で集約オプションバッファーに保存する必要があります - 最初のスプリット部分は、最初に集計オプションバッファー、次に2番目の部分などに保存する必要があります。エンコーディングエージェントは、オプションの分割方法に基づいてセマンティック情報を指定しようとしてはなりません。

Note that because the aggregate option buffer does not represent the physical ordering of the DHCP packet, if an option were split into three parts and each part went into one of the possible option fields, the first part would go into the optional parameters field, the second part would go into the file field, and the third part would go into the sname field. This maintains consistency with section 4.1 of RFC 2131 [3].

集約オプションバッファーはDHCPパケットの物理的順序を表していないため、オプションが3つの部分に分割され、各パーツが可能なオプションフィールドの1つに入った場合、最初の部分はオプションパラメーターフィールドに移動します。2番目の部分はファイルフィールドに入り、3番目の部分はSnameフィールドに入ります。これにより、RFC 2131 [3]のセクション4.1との一貫性が維持されます。

Each split portion of an option MUST be stored in the aggregate option buffer as if it were a normal variable-length option as described in RFC 2132 [4]. The length fields of each split portion of the option MUST add up to the total length of the option data. For any given option being split, the option code field in each split portion MUST be the same.

オプションの各スプリット部分は、RFC 2132 [4]で説明されているように、通常の可変長オプションであるかのように、集約オプションバッファーに保存する必要があります。オプションの各分割部分の長さフィールドは、オプションデータの総長さに合計する必要があります。分割されている特定のオプションの場合、各スプリット部分のオプションコードフィールドは同じでなければなりません。

7. Decoding Agent Behavior
7. デコードエージェントの動作

When a decoding agent is scanning an incoming DHCP packet's option buffer and finds two or more options with the same option code, it MUST consider them to be split portions of an option as described in the preceding section.

デコードエージェントが着信DHCPパケットのオプションバッファーをスキャンしている場合、同じオプションコードを使用して2つ以上のオプションを見つけた場合、前のセクションで説明したように、オプションの分割部分であると考える必要があります。

In the case that a decoding agent finds a split option, it MUST treat the contents of that option as a single option, and the contents MUST be reassembled in the order that was described above under encoding agent behavior.

デコード剤が分割オプションを見つけた場合、そのオプションの内容を単一のオプションとして扱う必要があり、内容はエンコードエージェントの動作で上記の順序で再組み立てされる必要があります。

The decoding agent should ensure that when the option's value is used, any alignment issues that are particular to the machine architecture on which the decoding agent is running are accounted for - there is no requirement that the encoding agent align the options in any particular way.

デコードエージェントは、オプションの値が使用されたときに、デコードエージェントが実行しているマシンアーキテクチャに特有のアライメントの問題が考慮されるようにする必要があります。エンコードエージェントが特定の方法でオプションを整列させる要件はありません。

There is no semantic meaning to where an option is split - the encoding agent is free to split the option at any point, and the decoding agent MUST reassemble the split option parts into a single object, and MUST NOT treat each split portion of the option as a separate object.

オプションが分割されている場所には意味的な意味はありません - エンコードエージェントは任意のポイントでオプションを自由に分割でき、デコードエージェントは分割オプションパーツを単一のオブジェクトに再構築する必要があり、オプションの各スプリット部分を処理してはなりません別のオブジェクトとして。

8. Example
8. 例

Consider an option, Bootfile name (option code 67), with a value of "/diskless/foo". Normally, this would be encoded as a single option, as follows:

「/diskless/foo」の値を持つオプション、ブートファイル名(オプションコード67)を考えてみましょう。通常、これは次のように、単一のオプションとしてエンコードされます。

      +----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
      | 67 | 13 | / | d | i | s | k | l | e | s | s | / | f | o | o |
      +----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
        

If an encoding agent needed to split the option in order to fit it into the option buffer, it could encode it as two separate options, as follows, and store it in the aggregate option buffer in the following sequence:

オプションをオプションバッファーに取り付けるためにオプションを分割する必要がある場合、次のように2つの個別のオプションとしてエンコードし、次のシーケンスに集約オプションバッファーに保存できます。

      +----+---+---+---+---+---+---+---+---+
      | 67 | 7 | / | d | i | s | k | l | e |
      +----+---+---+---+---+---+---+---+---+
        
      +----+---+---+---+---+---+---+---+
      | 67 | 6 | s | s | / | f | o | o |
      +----+---+---+---+---+---+---+---+
        
9. Security Considerations
9. セキュリティに関する考慮事項

This document raises no new security issues. Potential exposures to attack in the DHCP protocol are discussed in section 7 of the DHCP protocol specification [3] and in Authentication for DHCP Messages [5].

このドキュメントは、新しいセキュリティの問題を提起しません。DHCPプロトコルでの攻撃への潜在的な暴露については、DHCPプロトコル仕様[3]のセクション7およびDHCPメッセージの認証[5]で説明します。

Note that the authentication option itself can be split; in such cases implementations must be careful when setting the authentication field to zero (prior to generation or verification of the MAC) as it may be split across multiple options.

認証オプション自体を分割できることに注意してください。このような場合、実証は、複数のオプションに分割される可能性があるため、認証フィールドをゼロ(MACの生成または検証前)に設定する場合は注意する必要があります。

10. References
10. 参考文献
10.1. Normative References
10.1. 引用文献

[1] Croft, W. and J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 951, September 1985.

[1] Croft、W。およびJ. Gilmore、「Bootstrap Protocol(BOOTP)」、RFC 951、1985年9月。

[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.

[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[3] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。

[4] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.

[4] Alexander、S。and Droms、R。、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。

10.2. Informative References
10.2. 参考引用

[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.

[5] Droms、R。およびW. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月。

11. Intellectual Property Statement
11. 知的財産声明

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスに基づく免許にある範囲に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。

12. Authors' Addresses
12. 著者のアドレス

Ted Lemon Nominum, Inc. 2385 Bay Road Redwood City, CA 94043 USA

Ted Lemon Nominum、Inc。2385 Bay Road Redwood City、CA 94043 USA

   EMail: mellon@nominum.com
        

Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014 USA

Stuart Cheshire Apple Computer、Inc。1 Infinite Loop Cupertino California 95014 USA

   Phone: +1 408 974 3207
   EMail: rfc@stuartcheshire.org
        
13. 完全な著作権声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

Copyright(c)The Internet Society(2002)。無断転載を禁じます。

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エディター機能の資金は現在、インターネット協会によって提供されています。