この文書はRFC4183の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group E. Warnicke
Request for Comments: 4183 Cisco Systems
Category: Informational September 2005
A Suggested Scheme for DNS Resolution of Networks and Gateways
ネットワークのＤＮＳ解決とゲートウェイの示唆される案
Status of This Memo
このメモの状況
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
このメモはインターネット共同体に情報を提供します。これはインターネッ
ト標準を指定しません。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
IESG Note
ＩＥＳＧメモ
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and notes that the decision to publish is not based on IETF
review apart from IESG review for conflict with IETF work. The RFC
Editor has chosen to publish this document at its discretion. See
RFC 3932 [6] for more information.
このＲＦＣはインターネット標準の候補ではありません。ＩＥＴＦはどんな
目的でもこのＲＦＣの適性を否定し、そしてＩＥＴＦの仕事との矛盾のため、
ＩＥＳＧレビューを別として、公開の決定がＩＥＴＦレビューに基づいてい
ないと記載します。ＲＦＣ編集者はその裁量でこの文書の公開を決めました。
より多くの情報のためにＲＦＣ３９３２[6]を見てください。
Abstract
概要
This document suggests a method of using DNS to determine the network
that contains a specified IP address, the netmask of that network,
and the address(es) of first-hop routers(s) on that network. This
method supports variable-length subnet masks, delegation of subnets
on non-octet boundaries, and multiple routers per subnet.
この文書はそのネットワーク上の指定されたＩＰアドレスを含むネットワー
クで、そのネットワークのネットマスクとそのネットワークの最初のホップ
のルータのアドレスをＤＮＳを用いて決定する方法を示唆します。この方法
は可変長サブネットマスクと、オクテット境界以外での委任と、サブネット
毎の多数のルータをサポートします。
1. Introduction
1. はじめに
As a variety of new devices are introduced to the network, many of
them not traditional workstations or routers, there are requirements
that the first-hop router provide some network service for a host.
It may be necessary for a third-party server in the network to
request some service related to the host from the first-hop router(s)
for that host. It would be useful to have a standard mechanism for
such a third-party device to find the first-hop router(s) for that
host.
いろいろな新しい装置がネットワークに導入され、その多くは伝統的なワー
クステーションやルータではなく、最初のホップのルータがホストにあるネッ
トワークサービスを提供するという必要条件があります。ネットワークの第
三のサービスが、ホストの最初のホップのルータからホストと関係があるあ
るサービスを求めることが必要かもしれません。そのホストの最初のホップ
のルータを見いだすこのような第三者装置の標準的なメカニズムを持つこと
は有用であるでしょう。
DNS-based mechanisms have been defined for the resolution of router
addresses for classful networks (RFC 1035 [1]) and of subnets (RFC
1101 [2]). RFC 1101 suffers from a number of defects, chief among
which are that it does not support variable-length subnet masks,
which are commonly deployed in the Internet. The present document
defines DNS-based mechanisms to cure these defects.
クラスフルネットワークとサブネットのルータアドレスのＤＮＳに基づく解
決メカニズムが明確にされました（RFC 1035][1]とRFC 1101][2]）。RFC
1101に多くの欠陥があり、最も問題なのはインターネットで一般的な可変長
サブネットマスクをサポートしないということです。この文書はこれらの欠
陥を治すためのＤＮＳベースのメカニズムを定義します。
Since the writing of RFC 1101, DNS mechanisms for dealing with
classless networks have been defined, for example, RFC 2317 [3].
This document describes a mechanism that uses notation similar to
that of RFC 2317 to specify a series of PTR records enumerating the
subnets of a given network in the RFC 2317 notation. This lookup
process continues until the contents of the PTR records are not an
in-addr.arpa.-derived domain name. These terminal PTR record values
are treated as the hostname(s) of the router(s) on that network.
This RFC also specifies an extension to the method of RFC 2317 to
support delegation at non-octet boundaries.
RFC 1101の記述以降に、クラスレスネットワークを扱うことに対して、ＤＮ
Ｓメカニズムが明確にされました、例えば、RFC 2317[3]です。この文書は
RFC 2317の表記法に類似した方法で、RFC 2317のネットワークのサブネット
を列挙する、一連のＰＴＲレコードを指定する方法を記述します。この参照
処理は、ＰＴＲレコードの中身がaddr.arpa.から得られたドメイン名でなく
なるまで継続します。これらの最終のＰＴＲレコードの値はそのネットワー
ク上のルータのホスト名として扱われます。このＲＦＣはまた、オクテット
境界以外での委任をサポートするRFC 2317の拡張を指定します。
2. Generic Format of a Network Domain Name
2. ネットワークドメイン名の一般的なフォーマット
Using the Augmented BNF of RFC 2234 [4], we can describe a generic
domain name for a network as follows:
RFC 2234[4]の拡張ＢＮＦを使い、我々は次のようにネットワークの一般的
なドメイン名を記述することができます：
networkdomainname = maskedoctet "." *( decimaloctet / maskedoctet
".") "in-addr.arpa."
maskedoctet = decimaloctet "-" mask
mask = 1*2DIGIT ; representing a decimal integer value in the
; range 1-32
; 範囲１〜３２で１０進整数値を表します。
decimaloctet = 1*3DIGIT ; representing a decimal integer value in
; the range 0 through 255
; ０から２５５までの範囲で１０進整数値を表
; します。
By way of reference, an IPv4 CIDR notation network address would
be written
参照を通して、ＩＰｖ４ＣＩＤＲ表記ネットワークアドレスが以下の通りに
書かれるでしょう
IPv4CIDR = decimaloctet "." decimaloctet "." decimaloctet "."
decimaloctet "/" mask
A "-" is used as a delimiter in a maskedoctet instead of a "/" as in
RFC 2317 out of concern about compatibility with existing DNS
servers, many of which do not consider "/" to be a valid character in
a hostname.
既存ＤＮＳサーバの多くがホスト名で"/"が正当な文字と考えないたえめ、Ｄ
ＮＳサーバの互換性の懸念からRFC 2317の"/"の代わりに"-"をマスクオク
テットの区切り文字として使用します。
3. Non-Octet Boundary Delegation
3. 非オクテット境界委任
In RFC 2317, there is no mechanism for non-octet boundary delegation.
Networks would be represented as being part of the domain of the next
octet.
RFC 2317で、非オクテット境界線委任のメカニズムがありません。ネットワー
クが次のオクテットドメインの一部と述べられるでしょう。
Examples:
例：
10.100.2.0/26 -> 0-26.2.100.10.in-addr.arpa.
10.20.128.0/23 -> 128-23.20.10.in-addr.arpa.
10.192.0.0/13 -> 192-13.10.in-addr.arpa.
In the event that the entity subnetting does not actually own the
network being subnetted on an octet break, a mechanism needs to be
available to allow for the specification of those subnets. The
mechanism is to allow the use of maskedoctet labels as delegation
shims.
オクテット区切でサブネット化されたネットワークを保有しないサブネット
の所有者はでも、そのサブネットの仕様を許すために、メカニズムは利用可
能でなければなりません。メカニズムは委任くさびとしてマスクオクテット
ラベルの使用を許すはずです。
For example, consider an entity A that controls a network
10.1.0.0/16. Entity A delegates to entity B the network 10.1.0.0/18.
In order to avoid having to update entries for entity B whenever
entity B updates subnetting, entity A delegates the
0-18.1.10.in-addr.arpa domain (with an NS record in A's DNS tables as
usual) to entity B. Entity B then subnets off 10.1.0.0/25. It would
provide a domain name for this network of
0-25.0.0-18.1.10.in-addr.arpa (in B's DNS tables).
例えば、10.1.0.0/16の管理者Ａを考えます。管理者Ａが管理者Ｂにネット
ワーク10.1.0.0/18を委任します。管理者Ｂがサブネットを更新するときに、
管理者Ｂの項目を管理者Ａが更新するのを避けるために、管理者Ａが管理者
Ｂに0-18.1.10.in-addr.arpa domainを委任します（通常のＡのＤＮＳ表の
ＮＳレコードで）。それから管理者Ｂが10.1.0.0/25をサブネットにします。
これは（ＢのＤＮＳ表で）このネットワークの
0-25.0.0-18.1.10.in-addr.arpaのにドメイン名を提供するでしょう。
In order to speak about the non-octet boundary case more easily, it
is useful to define a few terms.
いっそう容易に非オクテット境界の場合を話すために、少数の用語を定義す
ることは有用です。
Network domain names that do not contain any maskedoctets after the
first (leftmost) label are hereafter referred to as canonical domain
names for that network. 0-25.0.1.10.in-addr.arpa. is the canonical
domain name for the network 10.1.0.0/25.
最初（最左）以降で、マスクオクテットを含まないラベルが、今後、ネット
ワークドメイン名の標準ドメイン名として参照されます。
0-25.0.1.10.in-addr.arpa.はネットワーク10.1.0.0/25の標準ドメイン名で
す。
Network domain names that do contain maskedoctet labels after the
first (leftmost) label can be reduced to a canonical domain name by
dropping all maskedoctet labels after the first (leftmost) label.
They are said to be reducible to the canonical network domain name.
So for example 0-25.0.0-18.1.10.in-addr.arpa. is reducible to
0-25.0.1.10.in-addr.arpa. Note that a network domain name represents
the same network as the canonical domain name to which it can be
reduced.
最初（最左）以降の全てのラベルのマスクオクテットラベルを捨てることで、
マスクオクテットラベルを含むネットワークドメイン名が標準ドメイン名に
変換できます。これらは標準ネットワークドメイン名に還元可能と言われま
す。それで例えば0-25.0.0-18.1.10.in-addr.arpa.は
0-25.0.1.10.in-addr.arpa.に還元可能です。ネットワークドメイン名が還元
して得られる標準ドメイン名と同じネットワークを表すことに注意してくだ
さい。
4. Lookup Procedure for a Network Given an IP Address
4. 与えられたＩＰアドレスのネットワークの参照手順
4.1. Procedure
4.1. 手順
1. Take the initial IP address x.y.z.w and create a candidate
network by assuming a 24-bit subnet mask. Thus, the initial
candidate network is x.y.z.0/24.
1. 最初のＩＰアドレスx.y.z.wに取り、２４ビットのサブネットマスクを
想定して、候補ネットワークを作ります。それで、最初の候補ネットワー
クはx.y.z.0/24です。
2. Given a candidate network of the form x.y.z.n/m create an
in-addr.arpa candidate domain name:
2. x.y.z.n/m形式の候補ネットワークに対し、addr.arpaの候補ドメイン名
を作成します：
1. If the number of mask bits m is greater than or equal to 24
but less than or equal to 32, then the candidate domain name
is n-m.z.y.x.in-addr.arpa.
1. もしマスクビットmが24以上32以下であるなら、候補ドメイン名は
n-m.z.y.x.in-addr.arpa.です。
2. If the number of mask bits m is greater than or equal to 16
but less than 24, then the candidate domain name is
z-m.y.x.in-addr.arpa.
2. もしマスクビットmが16以上24未満なら、候補ドメイン名は
z-m.y.x.in-addr.arpa.です。
3. If the number of mask bits m is greater than or equal to 8
but less than 16, then the candidate domain name is
y-m.x.in-addr.arpa.
3. もしマスクビットmが8以上16未満なら、候補ドメイン名は
y-m.x.in-addr.arpa.です。
4. The notion of fewer than 8 mask bits is not reasonable.
4. 8以下のマスク部は合理的ではありません。
3. Perform a DNS lookup for a PTR record for the candidate domain
name.
3. 候補ドメイン名のＰＴＲレコードのＤＮＳ参照を行なってください。
4. If the PTR records returned from looking up the candidate domain
name are of the form of a domain name for a network as defined
previously (Section 2), then for each PTR record reduce that
returned domain name to the canonical form
p1-q1.z1.y1.x1.in-addr.arpa. This represents a network
x1.y1.z1.p1/q1.
4. もし、候補ドメイン名の検索で返されたＰＴＲレコードが、前に定義し
た（２章）ネットワークのドメイン名の形式ならなら、それぞれのＰＴ
Ｒレコードは標準書式に還元します。これはネットワークx1.y1.z1.p1/q1
を表します。
1. If one of the x1.y1.z1.p1/q1 subnets contains the original IP
address x.y.z.w, then the PTR record return becomes the new
candidate domain name. Repeat steps 3-4.
1. もしx1.y1.z1.p1/q1サブネットの１つが元のＩＰアドレスx.y.z.w
を含むなら、その返されたレコードは新しい候補ドメイン名になり
ます。ステップ３−４を繰り返してください。
2. If none of the x1.y1.z1.p1/q1 subnets contain the original IP
address x.y.z.w, then this process has failed.
2. もしx1.y1.z1.p1/q1サブネットのどれも元のＩＰアドレスx.y.z.w
を含まないなら、この処理は失敗です。
5. If the PTR record(s) for the candidate network is not of the form
of a network domain name, then they are presumed to be the
hostname(s) of the gateway(s) for the subnet being resolved.
5. もし候補ネットワークのＰＴＲレコードがネットワークドメイン名の形
式ではないなら、それらはゲートウェイのホスト名であると推測され、
サブネットが解決されます。
6. If the PTR lookup fails (no PTR records are returned).
6. もしＰＴＲ参照が失敗するなら（返されるＰＴＲレコードがない）なら
1. If no candidate network PTR lookup for this IP address has
succeeded in the past and the netmask for the last candidate
network was 24 or 16 bits long, then presume a netmask of 8
fewer bits for the candidate network and repeat steps 2-4.
1. もしこのＩＰアドレスの候補ネットワーク参照が過去に成功し、そ
して最後の候補ネットワークのネットマスクが２４ビットあるいは
１６ビットであるなら、候補ネットワークの８ビット未満のネット
マスクを仮定し、ステップ２−４を繰り返してください。
2. If no candidate network PTR lookup for this IP address has
succeeded in the past and the netmask of the last candidate
network was not 24 or 16 bits long, then increase the netmask
by 1 bit and repeat steps 2-4.
2. もしこのＩＰアドレスの候補ネットワーク参照が過去に成功し、そ
して最後の候補ネットワークのネットマスクが２４ビットでも１６
ビットでもないなら、ネットマスクを１増加し、ステップ２−４を
繰り返してください。
3. If a candidate network PTR lookup for this IP address has
succeeded in the past or the netmask of the last candidate
network was 32 bits, then this process has failed.
3. もしこのＩＰアドレスの候補ネットワーク参照が過去に成功しない
か、最後の候補ネットワークのネットマスクが３２ビットなら、こ
の処理は失敗です。
7. Perform a DNS A record lookup for the domain name of the gateway
to determine the IP number of the gateway.
7. ゲートウェイのドメイン名がゲートウェイのＩＰ番号を決定するために
ＤＮＳのＡレコード検索を行なってください。
4.2. IPv6 Support
4.2. ＩＰｖ６サポート
RFC 3513 [5] requires all IPv6 unicast addresses that do not begin
with binary 000 have a 64-bit interface ID. From the point of view
of identifying the last hop router for an IPv6 unicast address, this
means that almost all hosts may be considered to live on a /64
subnet. Given the requirement that for any subnet there must be an
anycast address for the routers on that subnet, the process described
for IPv4 in this document can just as easily be achieved by querying
the anycast address via SNMP. Therefore, this document does not
speak to providing a DNS-based mechanism for IPv6.
RFC 3513 [5]が２進法で０００から始まらないすべてのＩＰｖ６ユニキャス
トアドレスが６４ビットのインタフェースＩＤを持つことを要求します。Ｉ
Ｐｖ６ユニキャストアドレスの最後のホップルータを識別する見地から、こ
れはほとんどすべてのホストが/64のサブネットにあると考えられるかもしれ
ないことを意味します。どんなサブネットでもそのサブネットのルータのエ
ニキャストアドレスがあるという必要条件のもとで、ＳＮＭＰでエニキャス
トアドレスを照会することで、この文書で記述されたＩＰｖ４のための処理
は同じぐらい容易に達成できます。そのために、この文書はＩＰｖ６にＤＮ
Ｓベースの機構を提供することことを示していません。
4.3. Example
4.3. 例
Imagine we begin with the IP number 10.15.162.3.
ＩＰ番号10.15.162.3から始めると想定します。
1. Form a candidate network of 10.15.162.0/24.
1. 10.15.162.0/24の候補ネットワークを構成します。
2. Form a domain name 0-24.162.15.10.in-addr.arpa.
2. ドメイン名 0-24.162.15.10.in-addr.arpa.を構成ます。
3. Look up the PTR records for 0-24.162.15.10.in-addr.arpa.
3. 0-24.162.15.10.in-addr.arpa.のＰＴＲレコードを調べます。
4. Suppose the lookup fails ( no PTR records returned ), then
4. 参照が失敗するとします（ＰＴＲレコードが返って来ない）
5. Form a new candidate network 10.15.0.0/16.
5. 新しい候補ネットワーク10.15.0.0/16.を生成します。
6. Form a domain name 0-16.15.10.in-addr.arpa.
6. ドメイン名0-16.15.10.in-addr.arpa.を構成します。
7. Look up the PTR records for 0-16.15.10.in-addr.arpa.
7. 0-16.15.10.in-addr.arpa.のＰＴＲレコードを調べます。
8. Lookup returns:
8. 次の参照が返ります：
1. 0-17.15.10.in-addr.arpa.
2. 128-18.15.10.in-addr.arpa.
3. 192-18.15.10.in-addr.arpa.
9. So 10.15.0.0/16 is subnetted into 10.15.0.0/17, 10.15.128.0/18,
and 10.15.192.0/18.
9. これで10.15.0.0/16が10.15.0.0/17と10.15.128.0/18と10.15.192.0/18
にサブネット化されます。
10. Since 10.15.162.3 is in 10.15.128.0/18, the new candidate domain
name is 128-18.15.10.in-addr.arpa.
10. 10.15.162.3が10.15.128.0/18にありますから、新しい候補ドメイン名
は128-18.15.10.in-addr.arpa.です。
11. Look up the PTR records for 128-18.15.10.in-addr.arpa.
11. 128-18.15.10.in-addr.arpa.のＰＴＲレコードを調べてください。
12. Lookup returns
12. 次の参照が返ります
1. 128-19.128-18.15.10.in-addr.arpa.
2. 0-25.160.128-18.15.10.in-addr.arpa.
3. 128-25.160.128-18.15.10.in-addr.arpa.
4. 0-24.161.128-18.15.10.in-addr.arpa.
5. 162-23.128-18.15.10.in-addr.arpa.
13. The canonical network domains for these returned records are
13. これらの返送されたレコードの標準的ネットワークドメインは以下です
1. 128-19.15.10.in-addr.arpa.
2. 0-25.160.15.10.in-addr.arpa.
3. 128-25.160.15.10.in-addr.arpa.
4. 0-24.161.15.10.in-addr.arpa.
5. 162-23.15.10.in-addr.arpa.
14. So the network 10.15.128.0/18 is subnetted into 10.15.128.0/19,
10.15.160.0/25, 10.15.160.128/25, 10.15.161.0/25, 10.15.162.0/
23.
14. これでネットワーク10.15.128.0/18は10.15.128.0/19と10.15.160.0/25
と10.15.160.128/25と10.15.161.0/25と10.15.162.0/23にサブネット
化されます。
15. Since 10.15.162.3 is in 10.15.162.0/23, the new candidate domain
name is 162-23.128-18.15.10.in-addr.arpa.
15. 10.15.162.3が10.15.162.0/23にあるので、新しい候補ドメイン名は
162-23.128-18.15.10.in-addr.arpa.です。
16. Look up the PTR records for 162-23.128-18.15.10.in-addr.arpa.
16. 162-23.128-18.15.10.in-addr.arpa.のＰＴＲレコードを調べてください。
17. Lookup returns:
17. 次の参照が返ります
1. gw1.example.net.
2. gw2.example.net.
18. Look up the A records for gw1.example.net. and gw2.example.net.
18. gw1.example.net.とgw2.example.netのＡレコードを調べてください。
19. Lookup returns
19. 次の参照が返ります
1. gw1.example.net: 10.15.162.1
2. gw2.example.net: 10.15.162.2
So the 10.15.162.3 is in network 10.15.162.0/23, which has gateways
10.15.162.1 and 10.15.162.2.
これで10.15.162.3はネットワーク10.15.162.0/23にあり、そしてでゲート
ウェイ10.15.162.1と10.15.162.2があるとわかります。
5. Needed DNS Entries
5. 必要なＤＮＳ項目
The example of the lookup procedure (Section 4.3) would require
DNS records as follows:
参照手順の例（４.３章）は次のようなＤＮＳレコードを必要とするでしょう：
In entity A's DNS zone files:
項目ＡのＤＮＳゾーンファイル：
0-16.15.10.in-addr.arpa. IN PTR 0-17.15.10.in-addr.arpa.
0-16.15.10.in-addr.arpa. IN PTR 128-18.15.10.in-addr.arpa.
0-16.15.10.in-addr.arpa. IN PTR 192-18.15.10.in-addr.arpa.
0-17.15.10.in-addr.arpa. IN NS ns1.example.org
128-18.15.10.in-addr.arpa. IN NS ns1.example.net
192-18.15.10.in-addr.arpa. IN NS ns1.example.com
ns1.example.net IN A 10.15.0.50
ns1.example.org IN A 10.15.128.50
ns1.example.com IN A 10.15.192.50
In entity B's DNS zone files:
項目ＢのＤＮＳゾーンファイル：
128-18.15.10.in-addr.arpa. IN PTR
128-19.128-18.15.10.in-addr.arpa.
128-18.15.10.in-addr.arpa. IN PTR
0-25.160.128-18.15.10.in-addr.arpa.
128-18.15.10.in-addr.arpa. IN PTR
128-25.160.128-18.15.10.in-addr.arpa.
128-18.15.10.in-addr.arpa. IN PTR
0-24.161.128-18.15.10.in-addr.arpa.
128-18.15.10.in-addr.arpa. IN PTR
162-23.128-18.15.10.in-addr.arpa.
162-23.128-18.15.10.in-addr.arpa. IN PTR gw1.example.net.
162-23.128-18.15.10.in-addr.arpa. IN PTR gw2.example.net.
gw1.example.net. IN A 10.15.162.1
gw2.example.net. IN A 10.15.162.2
6. Alternate Domain Suffix
6. 代わりのドメインサフィックス
Proper functioning of this method may required the cooperation of
upstream network providers. Not all upstream network providers may
wish to implement this method. If an upstream provider does not wish
to implement this method, the method may still be used with an
alternate domain suffix.
この方法が適切に機能するには上流ネットワークプロバイダの協力を必要と
するかもしれません。すべての上流のネットワークプロバイダがこの方法を
実装することを望むのではないかもしれません。もし上流のプロバイダがこ
の方法を実装することを望まないなら、方法は代わりのドメインサフィック
スで使われるかもしれません。
For example, if the upstream network provider of example.com did not
wish to provide glue records in its branch of the in-addr.arpa.
domain, then example.com might elect to use the suffix in-
addr.example.com as an alternate domain suffix for that purpose.
例えば、もしexample.comの上流のネットワークプロバイダがin-addr.arpa.
ドメインの一部に接着用レコードを提供することを望まなかければの、
example.comがこの目的のための代わりのドメインサフィックスとして
in-addr.example.comサフィックスを使うことを選ぶかもしれません。
For this reason, implementations of clients intending to use this
method should use in-addr.arpa. as the default suffix, but allow for
configuration of an alternate suffix.
この理由で、この方法を使うつもりであるクライアントの実装がin-addr.arpa.
をデフォルトサフィックスとして使用するが、代わりのサフィックスの設定
も考慮に入れるべきです。
7. Security Considerations
7. セキュリティの考察
Any revelation of information to the public internet about the
internal structure of your network may make it easier for nefarious
persons to mount diverse attacks upon a network. Consequently, care
should be exercised in deciding which (if any) of the DNS resource
records described in this document should be made visible to the
public internet.
ネットワークの内部構造の情報が公共インターネットへ発覚すると、悪人が
ネットワーク上の多様な攻撃を開始することをより容易にするかもしれませ
ん。従って、この文書で記述したＤＮＳ資源レコードのどれを公共インター
ネットに見えるようにするか決める際に、（もしあるとしたら）注意をすべ
きです。
8. Informative References
8. 有益な参考文献
[1] Mockapetris, P., "Domain Names - Implementation and
Specficication", STD 13, RFC 1035, November 1987.
[2] Mockapetris, P., "DNS Encoding of Network Names and Other
Types", RFC 1101, April 1989.
[3] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA
delegation", RFC 2317, March 1998.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[6] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures",
BCP 92, RFC 3932, October 2004.
Author's Address
著者のアドレス
Edward A. Warnicke
Cisco Systems Inc.
12515 Research Blvd., Building 4
Austin, TX 78759
USA
Phone: (919) 392-8489
EMail: eaw@cisco.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2005).
著作権（Ｃ）インターネット学会（２００５）。
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。