Network Working Group                                      Tony Bates
Internet Draft                                          cisco Systems
Expiration Date: July 1998                                 Randy Bush
                                                                RGnet
                                                              Tony Li
                                                     Juniper Networks
                                                        Yakov Rekhter
                                                        cisco Systems

              DNS-based NLRI origin AS verification in BGP

                BGPでのDNSを基としたNLRI origin AS照合

                draft-bates-bgp4-nlri-orig-verif-00.txt


1. Status of this Memo

1. このメモの状態

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   このメモはInternet-Draftです。Internet-Draftは、IETF、そのエリア、そし
   てそれらの作業を行うグループの作業上のドキュメントです。他のグループへ
   のメモとしてもInternet-Draftのような作業ドキュメントを配布するでしょう。

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   Internet-Draftは、６ヵ月を最長として有効な提案文章であり、そして、いつ
   でも他のドキュメントにより、更新、置換、旧式化されるでしょう。作業進行
   中に他の物に引用したり、題材を参照することはInternet-Draftの不適当な利
   用です。

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   どのInternet-Draftの最新の状態を知るにも、ftp.is.co.za(アフリカ)、
   nic.nordu.net(ヨーロッパ)、munnari.oz.au(太平洋地域)、ds.internic.net
   (米国東海岸)、または、ftp.isi.edu(米国西海岸)のInternet-Draftのシャド
   ウディレクトリに置かれている"1id-abstracts.txt"をどうぞチェックして下
   さい。


2. Abstract

2. 概要

   This document describes how a BGP speaker may verify that the Network
   Layer Reachability Information (NLRI) of a prefix received from a
   peer is consistent with the allocation of IP address space as
   determined by the Internet Registry system.  These verification
   procedures rely on the DNS to provide a repository of information
   about address space allocation provided by the Internet Registry
   system.

   BGP SpeakerにおけるPeerから受信したPrefixのネットワーク層到達情報(NLRI)
   の照合方法について、Internet Registryシステムによって決定されるような
   IPアドレス空間の矛盾のない配置をどのように行うかを記述したドキュメント
   です。これらのアドレススペースアロケーションについての情報の置場所を
   DNS上で提供する事をあてにする照合手順は、Internet Registryシステムに
   よって提供されます。

   Note that this is not a repository of announceable prefixes, but
   rather of allocation of delegated address space.

   これは、アナウンス可能なPrefixの置き場所ではなく、むしろ、代理で送信され
   たアドレススペースの配置です。





                                                                [Page 1]





Internet Draft  draft-bates-bgp4-nlri-orig-verif-00.txt     January 1998


3. Motivations

3. 動機

   IP address space is allocated by the Internet Registry system
   [RFC2050].  To provide Internet-wide IP connectivity it is imperative
   that the information provided by the Internet routing system be
   consistent with IP address allocation.  Specifically, the consistency
   requirement implies that an organization should inject a route for a
   particular IP address prefix into inter-domain routing only if the
   address space covered by the prefix was allocated to the organization
   via the Internet Address Registry system. To provide adequate fault
   isolation and robust Internet-wide routing in the presence of either
   misconfiguration or malicious attacks on routing,
   procedures/mechanisms which allow operators to enforce this
   consistency requirement are essential.

   IPアドレススペースはInternet Registryシステム[RFC2050]によって配置され
   ます。Internet-wideにIPの接続性を提供することは、情報がInternetのルー
   テイングシステムのIPアドレス配置の矛盾によって提供されることは避けられ
   ません。特に、もし、アドレススペースがInternet Address Registryシステ
   ムから団体に配布されたPrefixによって変換されたのであれば、矛盾の要求は、
   団体がドメイン間の経路だけの中の特定のIPアドレスPrefixに対して経路を注
   入することを含みます。どちらかの設定ミスの面前でのInternet-wideなルー
   ティングをすること、または、悪意ある経路のアタック強靭に、かつ、絶縁す
   る事を十分に提供し、この矛盾の要求を実行するオペレータを許す手順／機構
   は本質です。

   This document describes procedures and mechanisms that will allow
   operators to determine the correct origin AS of a prefix advertised
   into interdomain routing.  While other procedures and mechanisms are
   also necessary to provide reasonably secure routing, such procedures
   and mechanisms are beyond the scope of this document.

   このドキュメントは、内部ルーティングでのPrefixの広告の正しいorigin AS
   を決定するオペレータを許すであろう手順と機構を記述します。他の手順と
   機構が合理的なSecureルーティングを提供する事も必要とされている間、その
   ような手順と機構はこのドキュメントの範疇を越えています。

   This document does not address the related, but orthogonal, issue of
   determining the authenticated identity of the routing domain
   advertising a given prefix.

   このドキュメントはアドレスが関係ありません、しかし、与えられたPrefix
   を広告するルーティングドメインの認証を識別する決定の項目です。


4. Overview of Operations

4. オペレーションの概略

   We propose that information about IP address space allocation
   provided by the Internet Registry system be maintained within the DNS
   [DNS] under the bgp.in-addr.arpa domain.  This domain is to be
   further subdivided into additional sub-domains to reflect the
   allocation structure associated with IP address space.  Within this
   domain, and all of its subdomains, each node in the DNS tree (i.e.,
   each fully qualified domain name (FQDN)) represents one or more IP
   address prefixes allocated by the Internet Registry system.

   我々は、IPアドレススペースの配布についての情報がInternet Registryシステ
   ムのDNSでのbgp.in-addr.arpaドメインで保持される事によって提供されること
   を提案します。このドメインは、IPアドレス空間と関連する配置構造を反射す
   る追加のサブドメインとして将来的に細分されます。このドメイン、そして、
   それら全てのサブドメイン内部で、DNSの木構造でのそれぞれのノード(例えば、
   それぞれの完全な条件付きドメイン名(FQDN))は、Internet Registryシステム
   によって配置される一つ以上のIPアドレスのPrefixを提供します。

   This document uses Autonomous System numbers (ASs) to identify
   entities to which address space has been allocated.

   このドキュメントは、アドレス空間が配布されているものと一致する実体に自
   律システム番号を使います。

   For each address prefix, the DNS may contain either (a) the AS to
   which the address space described by the prefix has been allocated,
   or (b) NS delegation to name servers authoritative for the zone
   identified by the address prefix, or (c) no information about the
   prefix.

   それぞれのアドレスPrefixに対してDNSは、(a)アドレス空間が配置されている
   Prefixによって記述されているAS、(b)NSがアドレスPrefixによって一致される
   ゾーンに対して信頼できるネームサーバにdelegateする、または、(c)Prefixに
   関する情報がない、のいづれかに含まれます。

   When a BGP speaker receives a route from an external neighbor, the
   speaker uses the information provided by the DNS to verify that the



                                                                [Page 2]





Internet Draft  draft-bates-bgp4-nlri-orig-verif-00.txt     January 1998


   prefix was legitimately allocated to the AS/organization that
   injected the route into the inter-domain routing system.  If the
   speaker determines that the NLRI of the route wasn't legitimately
   allocated to the organization, the speaker rejects the route.

   BGP Speakerが外部のneighborから経路を受け取るとき、Speakerは、Prefixが
   ドメイン間のルーティングシステムに経路を注入するAS/organizationに適切
   に配置されることを照合するDNSによって提供される情報を利用します。もし、
   Speakerが、経路のNLRIを団体に正当配置されていないと限定すれば、Speaker
   はその経路を破棄します。

5. Extensions to the DNS

5. DNSの拡張

   The mechanism described in this document requires one new Resource
   Record (RR):

   このドキュメントで記述されるメカニズムは、一つの新しいRosource Record
   (RR)を要求します。

      Autonomous System RR (AS):

      自律システムリソースレコード:

         This RR consists of two fields, 'AS' and 'Prefix Length'.  The
         AS field contains an AS number, encoded as a two octet unsigned
         integer (0 through 65535), with 0 and 65535 having special
         meanings.  The Prefix Length field contains an octet encoding
         the length of the address prefix associated with the node named
         by the RR (0 through 32).

         このRRは、"AS"と"Prefix Length"の２つのフィールドから成ります。
         ASフィールドは、２オクテットにエンコードされた非符号整数(0〜
         65535)で、0と65535は特別な意味を持つAS番号で表現します。Prefix
         Lengthフィールドは、１オクテットで表現するRRによって名付けられ
         たノードに関係するアドレスPrefixの長さ(0〜32)です。


6. Procedures for populating the DNS with the Address Allocation
   information

6. アドレス配置情報をDNSに移植する為の手順

   A node under the bgp.in-addr.arpa domain may contain either (a) a set
   of NS RRs that specify name servers authoritative for the zone
   covered by the address prefix associated with the node, or (b) a
   CNAME RR, or (c) a set of one or more AS RRs, where each AS RR
   specifies the AS to which the address prefix has been allocated via
   the Internet Registry procedures and the length of the allocated
   address prefix.

   bgp.in-addr.arpaドメイン配下のノードは、(a)NS RRの設定がノードと関係のあ
   るアドレスPrefixによってカバーされるゾーンに対して信頼できる特別な名前
   のサーバ、(b)CNAMEがRR、または、(c)それぞれのAS RRがアドレスPrefixの
   Internet Registry手順、そして、アドレスPrefixが配置される長さから配置さ
   れているASに定義する一つ以上のAS RRを設定、のいづれかで表現されるでしょ
   う。

   Discussion: An alternative to constructing this information under the
   in-addr.arpa domain would be to pick up some other domain
   (e.g.,ipv4.nlri.ietf.org).  Comments and suggestions are welcome.

   議論：in-addr.arpaドメイン配下のこの情報をもう一つ作成することは
   (ipv4.nlri.ietf.orgのような)いくつかの他のドメインをピックアップするこ
   とになるでしょう。コメントや提案は歓迎です。

   CNAME RRs are used for allocations which occur on non-octet
   boundaries as described in draft-ietf-dnsind-classless-inaddr-04.txt.

   CNAME RRは、draft-ietf-dnsind-classless-inaddr-04.txtで書かれているよう
   にオクテットに依らないバウンダリを起こす配置に対して利用されます。

   The AS field of an AS RR may contain the special value zero (0).
   This value indicates that the DNS may not contain all the information
   about allocations out of the address prefix as defined by a
   combination of the node and the Prefix Length field of the AS RR.  In
   other words, the allocation status of this space is not known.  This
   is distinct from the case where the space is not allocated or it is
   known to be allocated to some particular AS.

   AS RRのASフィールドは、特別な値として零(０)を持ちます。この値は、DNSが
   AS RRのPrefix Lengthフィールドとノードのコンビネーションによって定義さ
   れるようなアドレスPrefixの外の配置についての全ての情報を表現しないこと
   を指摘します。他の言葉では、この空間の配置状態は知りません。これは、
   空間がいくつかの特定のASに配置される事をしっているか、配置されない場合
   とは異なります。




                                                                [Page 3]





Internet Draft  draft-bates-bgp4-nlri-orig-verif-00.txt     January 1998


   The AS field of the AS RR may also contain the special value 65535.
   This value indicates that the address prefix associated with the
   address space has not been allocated by the Internet Registries.  An
   AS RR with an AS value of 65535 can also be used to prevent
   authentication of certain prefixes.

   AS RRのASフィールドは、特別な65535という値をも表現するでしょう。この値
   は、アドレス空間に関係あるアドレスPrefixがInternet Registryによって配
   置されていることを指摘しています。65535の値のASでのAS RRは、確実な
   Prefixの照合を妨げにも利用することができます。

   While 0/0 is not allocated address space per se, as some routing
   domains use default announcement, default should be allowed in
   practice.  Hence we propose 0/0 be considered unauthenticated (AS of
   zero) and all truely unallocated space be specifically so marked (AS
   65535).

   0/0がいくつかのルーティングドメインのデフォルトアナウンスで利用する
   ような、seごとのアドレス空間に配置されない間、デフォルトは慣例的に許さ
   れるでしょう。その結果、我々は、(０のASを)照合なしに考慮される0/0を提
   案し、そして、全ての信用できる配置されていない空間は(AS65535で)特別に
   マークされます。


7. Conventions for encoding address allocations in DNS names

7. DNS名のアドレス配置をエンコードすることに対する慣例

   Syntactically, a DNS name is a series of text 'labels', separated by
   the '.' character.  Within the bgp.in-addr.arpa domain, a label that
   is a decimal number is used to represent an octet within a prefix.
   To indicate partial octets, we use the notation <value>/<length>
   where the <value> contains the value of the last significant octet in
   the prefix and the <length> is the prefix length.  Thus, the prefix
   10.1.128/20 may be encoded in a DNS name as 128/20.1.10.bgp.in-
   addr.arpa.

   構文的に、DNS名は"."文字で分割された"ラベル"テキストの列です。
   bgp.in-addr.arpaにおいて、10進数のラベルは1オクテットのPrefixを示すこ
   とに利用されます。部分的にオクテットを指摘為に、我々は、<value>/<length>
   の記法を利用します、このとき、<value>はPrefixでの最後の意味のあるオク
   テットの値を表し、<length>はPrefixの長さを表します。このように、
   10.1.128/20のPrefixは128/20.1.10.bgp.in-addr.arpaのようなDNS名でエン
   コードされるでしょう。

   In addition, for this proposal to work, the hierarchy of address
   allocations must be explicitly encoded in the name through the
   addition of one or more labels.  This also implies that no labels may
   be removed as part of the allocation of portions of a prefix.

   追加として、この仕事の提案にのために、アドレス配置の階層は、一つ以上
   のラベルの追加の為の名前に明確にエンコードされなくてはなりません。こ
   れは、無いラベルがPrefixの位置の配置の一部が削除されるということも含
   みます。

   If a prefix is allocated on a non-octet boundary, then the allocating
   domain constructs the name by first adding the labels for the
   additional full octets, if any, in reversed order to the leftmost
   position in the name.  Then, the label for the partial octet is added
   as the leftmost position in the name.  This name is given an NS RR.
   As always, normal DNS syntax applies and the resulting name need not
   be fully qualified.

   もし、Prefixがオクテットに依存しないバウンダリで配置されるならば、配
   置するドメインは、追加する全てのオクテットに対してラベルを最初に追加
   する個とによって名前が作成されます、たとえそれが、部分的なオクテット
   に対するラベルが名前の一番左の位置に追加されます。この名前は、NS RRが
   与えられます。常に、通常のDNS構文で与えれるものと名前の結果は完全に
   限定される必要はありません。

   For non-octet allocations, the NS record is necessary but not
   sufficient.  In addition, a number of CNAME RRs must be added.
   Recall that the partial octet specifies a number of significant bits
   in the least significant octet in the prefix.  One CNAME RR must be
   created for each possible value of the remaining bits.  The name that
   the CNAME RR points to (i.e., the name on the right hand side) is
   constructed by using the value of the least significant octet
   concatenated with the fully qualified name used for the NS RR.  These
   RRs allow lookups for longer prefixes to redirect through the correct
   allocation.

   オクテットに依存しない配置に対して、NSレコードは必要です、しかし、十
   分ではありません。追加として、CNAME RRの番号を追加しなくてはなりませ
   ん。部分的なオクテットの取消は、Prefixでの残りの意味のあるオクテット
   で意味のあるビットの番号を定義します。一つのCNAME RRは、残っているビ
   ットのそれぞれの可能な値に対して作成されなくてはなりません。(右側の名
   前への)CNAME RR位置の名前は、NS RRに対して利用される完全に条件付けさ
   れた名前と連結された残りの意味のあるオクテットの値を使うことによって
   作成されます。これらのRRは、正しい配置を通して方向を変える長いPrefix
   を見つけ出すことを許します。




                                                                [Page 4]





Internet Draft  draft-bates-bgp4-nlri-orig-verif-00.txt     January 1998


   A prefix can be extracted from a DNS name constructed using the above
   conventions by using the labels that represent full octets and the
   leftmost label (if any) that represents a partial octet.  These
   labels are then reversed in the normal in-addr.arpa manner.

   Prefixは、部分的なオクテットを提供する最も左のラベル、そして、全ての
   オクテットを提供するラベルを利用することによって、先の慣例を使用して
   作成されるDNS名から抜粋されることができます。これらのラベルは、通常の
   in-addr.arpaのマナーで予約されています。

   This particular naming scheme is a suggested convention, and
   alternate semantically equivalent conventions are also perfectly
   acceptable.

   この特殊なネーミングの案は、会議で提案され、そして、もう一つの意味的に
   同等な会議においても完全に賛同しています。


8. An Example

8. 例

   The following example illustrates how the DNS might be populated with
   address allocation information.

   下記の例にどのようにDNSがアドレス配置情報を移植されるべきかを説明しま
   す。

   ; the root
   $ORIGIN     bgp.in-addr.arpa.       ;well-known root zone
   @           SOA     (...)           ;presume ns etc. for zone
   0           AS      0 0             ;default not allocated but Ok
   1           NS      ns0.bbn.com.    ;allocate 1/8 to bbn
   205         NS      ns0.arin.net.   ;allocate 205/8 to arin

   ; ns0.bbn.com  -  bbn's server
   $ORIGIN     1.bgp.in-addr.arpa.
   @           SOA     (...)           ;presume ns etc. for zone
               AS      1 8             ;claim allocation for 1/8

   ; ns0.arin.net  -  arin's server
   $ORIGIN     205.bgp.in-addr.arpa.
   @           SOA     (...)           ;presume ns etc. for zone
               AS      65535 8         ;205/8 is delegated in parts
   0           NS      ns0.digex.net.  ;delegating 205.0/16
   1           NS      ns0.verio.net.  ;delegating 205.1/16

   ; ns0.digex.net  -  digex's server
   $ORIGIN     0.205.bgp.in-addr.arpa.
   @           SOA     (...)           ;presume ns etc. for zone
               AS      2548 16         ;claim allocation for 205.0/16

   ; ns0.verio.net  -  verio's server
   $ORIGIN     1.205.bgp.in-addr.arpa.
   @           SOA     (...)           ;presume ns etc. for zone
               AS      2914 16         ;205.1/16 is allocated to AS 2914
   0           AS      777  24         ;205.1.0/24 is allocated to AS 777
   1           AS      2914 24         ;205.1.1/24 is allocated to AS 2914
   ; delegate 205.1.2/23 using the classless in-addr hack
   2           CNAME   2.2/23.1.205.bgp.in-addr.arpa.
   3           CNAME   3.2/23.1.205.bgp.in-addr.arpa.



                                                                [Page 5]





Internet Draft  draft-bates-bgp4-nlri-orig-verif-00.txt     January 1998


   2/23        NS      ns.cust.com.    ;delegate 205.1.2/23, or
                                       ;205.1.2/24 and 205.1.3/24
                                       ;to customer server
   4           AS      42 22           ;205.1.4/22 is allocated to AS 42
               AS      0  22           ;also allocated elsewhere
   8           AS      666 21          ;205.1.8/21 is allocated to AS 666
   ; delegate 205.1.16/22 using the classless in-addr hack
   16          CNAME   16.16/22.1.205.bgp.in-addr.arpa.
   17          CNAME   17.16/22.1.205.bgp.in-addr.arpa.
   18          CNAME   18.16/22.1.205.bgp.in-addr.arpa.
   19          CNAME   19.16/22.1.205.bgp.in-addr.arpa.
   16/22       NS      ns.cust.net.    ;delegate 205.1.16/22 and longer
                                       ;to customer

   ; ns.cust.com - 2/23 server
   $ORIGIN     2/23.1.205.bgp.in-addr.arpa.
   @           SOA     (...)           ;presume ns etc. for zone
               AS      4242 23         ;AS 4242 claims 205.1.2/23

   ; ns.cust.net - 16/22 server
   $ORIGIN     16/22.1.205.bgp.in-addr.arpa.
   @           SOA     (...)           ;presume ns etc. for zone
   16          AS      222  23         ;AS 222 claims 205.1.16/23
   18          NS      ns.c1.cust.net. ;delegate 205.1.18/24
                                       ;to a customer's campus


9. Procedures for verifying BGP routing information

9. BGP経路情報の照合手順

   Given a prefix, a lookup in the bgp.in-addr.arpa domain is done by
   padding the least significant side of the prefix with zeros to an
   octet boundary and then reversing the octets, as is normally done
   within the bgp.in-addr.arpa domain.  A normal DNS lookup on the
   resulting name may involve multiple CNAME records, eventually
   resulting in a FQDN.

   与えられたPrefixをbgp.in-addr.arpaドメインで見つけ出すには、通常
   bgp.in-addr.arpaドメインで行われるような、予約したオクテットと、
   オクテットバウンダリで０をPrefixの残りの意味のある方向にあてがう
   ことによって行われます。通常のDNSが結果の名前を見つけるには、複数
   のCNAMEレコードを含むでしょう、結局はFQDNでの結果です。

   We define that a DNS node, authenticated by DNSSEC and under the
   bgp.in-addr.arpa domain, 'matches' a particular prefix if (a) the
   result of a lookup on the prefix is the node, and (b) the node
   contains an AS RR with the value of the Prefix Length field less than
   or equal to the length of the prefix.  We refer to any such AS RR as
   a "matching" AS RR.

   我々は、DNSノード、DNSSECによる認証、そして、bgp.in-addr.arpa配下の
   ドメインが、(a)Prefixで見つけ出す結果がノードである、かつ、(b)ノー
   ドがPrefixの長さ以下であるPrefix Lengthフィールドの値にAS RRが含ま
   れる、場合の特殊なPrefixに「マッチする」ように定義する。我々は、AS RR
   に「マッチする」ようなどのAS RRも参照します。

   If a BGP speaker performs a lookup on a prefix and cannot find a
   match, it first clears the least significant set bit in the least
   significant octet in the prefix and performs another lookup.  If
   there is no set bit in the least significant octet, it then discards
   the least significant octet from the prefix and performs another



                                                                [Page 6]





Internet Draft  draft-bates-bgp4-nlri-orig-verif-00.txt     January 1998


   lookup.  The AS RRs that result from this lookup are compared to the
   original, unmodified prefix to determine if there is a match.

   もし、BGP SpeakerがPrefixで調べることを実行し、そして、マッチする物が
   見つける事ができなければ、最初にPrefixに最小限の意味のあるオクテットの
   最小限の意味のあるビットをクリアし、そして、他のものを見つける事を実行
   します。もし、最小限の意味のあるオクテットにビットをセットしなければ、
   Prefixから最小限の意味のあるオクテットを捨て、そして、他のものを見つけ
   る事を実行します。この見つけだしから得られる結果のAS RRはオリジナルの
   ものと比較され、それがマッチしたならば、変更されないPrefixoが決定され
   ます。

   Using the example from the previous section, an address prefix
   205.1.4/22 matches the node 4.1.205.bgp.in-addr.arpa.  The matching
   AS RR is "AS 42 22".  An address prefix 205.1/16 matches the node
   1.205.bgp.in-addr.arpa with a matching AS RR of (AS 2914 16).

   前節からの使用例では、205.1.4/22のアドレスPrefixは、ノードの4.1.205.
   bgp.in-addr.arpaにマッチします。AS RRにマッチすることは、"AS 42 22"
   です。205.1/16のアドレスPrefixは、(AS 2914 16)にマッチするAS RRでの
   ノード1.205.bgp.in-addr.arpaにマッチします。

   Further, an address prefix 205.1.0/18 matches the node 1.205.bgp.in-
   addr.arpa, with the matching AS RR as (AS 2914 16).  Note that in
   this case, the first lookup fails and requires a second lookup.
   Similarly, the prefix 205.1.5/24 matches the node 4.1.205.bgp.in-
   addr.arpa with the matching AS RR as (AS 42 22).

   さらに、205.1.0/18のアドレスPrefixは、(AS 2914 16)のようなAS RRにマッチ
   するとともに、ノード1.205.bgp.in-addr.arpaにマッチします。このケースに
   おいて、最初の見つけだしの失敗し、そして、２回目の見つけだしで要求され
   ます。様に、Prefix、205.1.5/24は、(AS 42 22)のようなAS RRにマッチする
   とともにノード4.1.205.bgp.in-addr.arpaにマッチします。

   The following assumes that a BGP speaker has sufficient routing
   information to have access into the DNS system.

   BGP SpeakerがDNSシステムにアクセスして得られる十分な経路情報をもつこと
   を引き受ける物を下記に示します。

   A route may be marked "Authenticated", "Unauthenticated", or
   "Authentication Failed".

   経路は、"Authenticated"、"Unauthenticated"、または、"Authentication
   Failed"に印を付けられるでしょう。

   When a BGP speaker receives a route from an external peer, the
   speaker marks the route as "Unauthenticated", and then performs the
   following:

   BGP Speakerが外部Peerからの経路を受信したとき、Speakerは"Unauthenticated"
   な経路をマークし、そして、下記のような事を実行します。

      - the speaker checks the DNS for the presence of a node that
      "matches" the NLRI of the route.

      - Speakerは、経路のNLRIに「マッチする」ノードの存在に対してDNSをチェ
        ックします。

      - if there is a matching node with an AS RR where the value of the
      AS field is equal to the origin AS of the BGP AS_PATH attribute of
      the received prefix, the route is marked as "Authenticated."

      - もし、ASフィールドの値が受信したPrefixのBGP AS_PATH属性のOrigin AS
        と同じのAS RRとマッチするノードがあれば、経路は"Authenticated"にマ
        ークされます。

      - if there is a matching node with an AS RR where the value of the
      AS field is 65535, the route is marked as "Authentication Failed."

      - もし、ASフィールドの値が65535のAS RRとマッチするノードであれば、経
        路は、"Authentication Failed"にマークされます。

      - if there is a matching node with an AS RR where the value of the
      AS field is is zero (0), the route is left as as
      "Unauthenticated."

      - もし、ASフィールドの値が０のAS RRとマッチするノードであれば、経路は
        残りの"Unauthenticated"になります。

      - if there is a matching node with an AS RR where the value of the
      AS field is neither 0, 65535, nor the origin AS of the received
      prefix, the route is marked as "Authentication Failed."

      - もし、ASフィールドの値が０でも65535でも、受信したPrefixのOrigin AS
        でもないAS RRとマッチするノードであれば、経路は"Authentication 
        Failed"にマークされます。

      - in all other cases the marking of the route is not modified,
      i.e. it remains "Unauthenticated."

      - 経路のマークが全て他のケースであれば、変更されません。たとえば、
        "Unauthenticated"が残ります。

   The authentication status of a route has a time limit, maintained in
   the authentication status timer.  If the origin of a route is



                                                                [Page 7]





Internet Draft  draft-bates-bgp4-nlri-orig-verif-00.txt     January 1998


   Authenticated, then the timer is set to the Time To Live (TTL) of the
   matching AS RR.  The timer for a route marked as "Unauthenticated" is
   set to RouteAuthenticationRetryTimer value (by default 24 hours).
   Note that the authentication status timer is not propagated in BGP
   Update messages.

   経路の認証状態は、認証状態タイマで管理される制限時間を持ちます。もし、
   経路のOriginが認証されていれば、タイマはAS RRにマッチするTime-to-Live
   (TTL)にセットされます。経路に対するタイマは"UnAuthenticated"が(デフォ
   ルト２４時間である)RouteAuthenticationRetryTimerの値をセットするように
   マークされます。認証状態タイマはBGP Update Messageに伝達されません。

   When the timer expires, the route is marked as "Unauthenticated", and
   the BGP speaker performs the above procedures.

   タイマが切れた時、経路は"Unauthenticated"にマークされ、そして、BGP
   Speakerは前述の処理を実行します。

   A BGP speaker MAY use and advertise to other BGP speakers a route
   that is marked as either Unauthenticated or Authenticated.  As a
   matter of local policy the BGP speaker in its route selection policy
   MAY give preference to routes marked as Authenticated.

   BGP Speakerは「おそらく」UnauthenticatedかAuthenticatedのどちらかにマ
   ークされている経路を他のBGP Speakerに広告し、利用するでしょう。経路選
   択ポリシとしてのローカルなBGP Speakerのポリシの要因は、「おそらく」
   Authenticatedにマークされている経路のPreferenceを与える事です。

   A BGP speaker MUST NOT use and/or advertise to other BGP speakers a
   route that is marked as "Authentication Failed".

   BGP Speakerは、"Authentication Failed"のようにマークされた経路を他の
   BGP Speakerに広告したり、利用したりすることを決して行ってはなりません。

   Since a BGP speaker may perform the above procedures asynchronously
   with route installation and advertisement, a speaker may advertise a
   route marked as "Unauthenticated", but then might later mark the
   route as "Authentication Failed".  In this case the speaker MUST
   withdraw the route, and stop using it.

   BGP Speakerは、おそらく前述した経路のインストールと広告に同期しない手順
   を実行するので、Speakerは"Unauthenticated"にマークされた経路を広告するで
   しょう、しかしながら、後で"Authentication Failed"に経路をマークするでし
   ょう。この様な場合、Speakerは経路をwithdraw(消す)しなくてはなりませんし、
   そして、その利用を停止しなくてはなりません。

   As a local matter a BGP speaker MAY "preload" as much of the DNS
   information as it wants.  Doing this would allow the speaker to
   accelerate the marking of a newly received routes.

   ローカルな要因として、BGP Speakerは、必要とされる多くのDNS情報を先に蓄え
   ておくでしょう。これを実行するには、新しく受信した経路のマークを早急に行
   う個とをSpeakerは許すでしょう。

   A BGP speaker, MAY (under control of its local configuration) exempt
   certain routes from the above verification procedures.

   BGP Speakerは、「おそらく」、先に実証した手順から確実な経路を(ローカルな
   設定の管理下で)除去します。

   In addition to address allocations, the bgp.in-addr.arpa domain can
   be used to encode aggregated prefixes.  As with other prefixes, the
   AS RR is used to indicate the origin of the aggregate.  Insertion of
   information about the aggregate requires the cooperation of the
   entity controlling the appropriate point in the namespace.

   アドレス配置の追加において、bgo.in-addr.arpaドメインは、エンコードした
   Prefixの集合を利用することができます。他のPrefixと共に、AS RRは、Origin
   の集合を示すように利用されます。集合に関する情報の挿入は、名前空間の特定
   のポイントを管理する要素の関係を要求します。














                                                                [Page 8]





Internet Draft  draft-bates-bgp4-nlri-orig-verif-00.txt     January 1998


10. Use of TXT RRs

10. TXT RRの利用

   Instead of introducing a new RR type, the AS RR, the scheme described
   in this document might use a TXT RR, where the information encoded in
   the TXT RR would be the same as in the AS RR (although the encoding
   will be different). One of the problems with using the TXT RRs is
   that it redefines the semantics of the TXT RR, which at least will be
   somewhat confusing.  Further, if a TXT RR is used for initial
   deployment, there is a likelihood that no transition would ever be
   made to the AS RR.

   新しいRRタイプであるAS RRの紹介の代わりに、この文章に書かれる案は、
   情報が(たとえ、エンコードが違ったとしても)AS RRと同じようなTXT RRでエ
   ンコードされるTXT RRを利用します。TXT RRを利用する問題の一つは、少なく
   とも多少混乱するであろうTXT RRの意味を再定義する個とです。それ以上に、
   もし、TXT RRが最初の展開に利用されるのであれば、過渡期にAS RRが作り続け
   られることがないと言うことがあり得ます。

11. Security Considerations

11. セキュリティの考慮

   This entire document is about security considerations.

   この全体のドキュメントは、セキュリティの考慮に関してです。

   DNSSEC should be used in conjunction with the procedures described in
   this document to provide authentication for the DNS information.

   DNSSECは、DNS情報に対して認証を提供するために、この文章で書かれる手順
   を結合して利用されるでしょう。
   


12. Acknowledgments

12. 謝辞

   The authors would like to acknowledge the contributions of the DNSSEC
   working group and the authors of draft-ietf-dnsind-classless-inaddr-
   04.txt for their contributions without which, this work would have
   been impossible.  Additionally, the authors would like to thank Jerry
   Scharf for commenting on the work as it progressed.

   著者は、この仕事にこの上なく貢献して頂いたdraft-ietf-dnsind-classless-
   inaddr-04.txtの著者、そして、DNSSECワーキンググループの貢献に大変感謝
   します。さらに、著者は、この仕事の進行にコメントを下さったJerry Scharf氏
   に大変感謝致します。

13. References

   [BGP-4]

   [DNS]

   [DNSSEC]















                                                                [Page 9]





Internet Draft  draft-bates-bgp4-nlri-orig-verif-00.txt     January 1998


14. Author Information


   Tony Bates
   cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134
   Email:  tbates@cisco.com

   Randy Bush
   RGnet, Inc.
   5147 Crystal Springs
   Bainbridge Island, WA 98110
   E-mail: randy@psg.com

   Tony Li
   Juniper Networks, Inc.
   385 Ravendale Dr.
   Mountain View, CA 94043
   E-mail: tli@juniper.com

   Yakov Rekhter
   cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134
   Email:  yakov@cisco.com

























                                                               [Page 10]


70 W. Tasman Dr.
   San Jose, CA 95134
   Email:  tbates@cisco.com

   Randy Bush
   RGnet, Inc.
   5147 Crystal Springs
   Bainbridge Island, WA 98110
   E-mail: randy@psg.com

   Tony Li
   Juniper Networks, Inc.
   385 Ravendale Dr.
   Mountain View, CA 94043
   E-mail: tli@juniper.com

   Yakov Rekhter
   cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134
   Email:  yakov@cisco.com

























                                                               [Page 10]