この文書はRFC2450の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


  • Status of this Memo (この文書の状態 )
  • Copyright Notice (著作権表示)
  • 1.0 Introduction (はじめに)
  • 2.0 Scope (適用範囲)
  • 3.0 IPv6 Aggregatable Global Unicast Address Format (IPv6集約グローバルユニキャストアドレスフォーマット)
  • 4.0 Technical Motivation (技術的な動機)
  • 5.0 Proposed Rules for Assignment of Top-Level Aggregation ID's (最上位集約識別子の割当てのための提案された規則)
  • 5.1 Proposed TLA Allocation Stages (TLA割当て手順の提案)
  • 5.2 Proposed Assignment Requirements (割当て必要条件の提言)
  • 6.0 Proposed Rules Assignment of Next-Level Aggregation ID's (次のレベル集約識別子の割当て規則の提案)
  • 7.0 Acknowledgments (謝辞)
  • 8.0 Security Considerations (セキュリティの考慮)
  • 9.0 References (参考文献)
  • 10.0 Author's Address (著者のアドレス)
  • 11.0 Full Copyright Statement (著作権表示全文)

  • Network Working Group                                      R. Hinden
    Request for Comments: 2450                                     Nokia
    Category: Informational                                December 1998
    
    
                     Proposed TLA and NLA Assignment Rules
                       TLAとNLAの割当て規則の提案
    
    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 (1998).  All Rights Reserved.
    
    1.0 Introduction 
    1.0 はじめに
    
       This document proposes rules for Top-Level Aggregation Identifiers
       (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined
       in [AGGR].  These proposed rules apply to registries allocating TLA
       ID's and to organizations receiving TLA ID's.
       この書類は[AGGR]で定義されるように、最上位集約識別子(TLA識別子)
       と次のレベル集約識別子(NLA識別子)に対して規則を提案します。これ
       らの提案された規則はTLA識別子を割り当てている登記所そしてTLA識
       別子を受け取っている組織に当てはまります。
    
       This proposal is intended as input from the IPng working group to the
       IANA and Registries.  It is not intended for any official IETF
       status.  Its content represents the result of extensive discussion
       between the IPng working group, IANA, and Registries.
       この提案はIPngワークグループからIANAと登記所へのインプットを意図され
       ます。これは公式のIETFステータスを意図しません。この内容はIPngワーク
       グループとIANAと登記所の間の広範囲の論議の結果を表します。
    
       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 [RFC 2119].
       この文書におけるキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と
       "SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"
       とは[RFC 2119]で記述されるように解釈されるはずです。
    
    2.0 Scope 
    2.0 適用範囲
    
       The proposed TLA and NLA assignment rules described in this document
       are intended for the first two years of IPv6 TLA address assignments.
       As routing technology evolves and we gain additional experience with
       allocating IPv6 addresses the procedures proposed in this document
       may change.
       この文書で記述したTLAとNLA割当て規則の提案は、最初の2年間のア
       ドレス割当てを意図します。ルーティング技術が進展し、IPv6アドレス
       の割り当ての経験を得るにつれて、この文書で提案された手順は変わるかも
       しれません。
    
    3.0 IPv6 Aggregatable Global Unicast Address Format 
    3.0 IPv6集約グローバルユニキャストアドレスフォーマット
    
       This document proposes assignment rules for the TLA ID and NLA ID
       fields in the IPv6 Aggregatable Global Unicast Address Format.  This
       address format is designed to support both the current provider-based
       aggregation and a new type of exchange-based aggregation.  The
       combination will allow efficient routing aggregation for sites that
       connect directly to providers and for sites that connect to
       exchanges.  Sites will have the choice to connect to either type of
       aggregation entity.
       この文書はIPv6集約グローバルユニキャストアドレスフォーマットでT
       LA識別子とNLA識別子フィールドの割当て規則を提案します。このアド
       レスフォーマットは現在のプロバイダベースの集合体と新しいタイプの交換
       ベースの集合体の両方をサポートするよう意図されます。組合わせは直接プ
       ロバイダに接続するサイトと交換に接続するサイトに効率的なルーティング
       集約を許すでしょう。サイトがいずれかのタイプの集約に接続する選択権を
       持つでしょう。
    
       While this address format is designed to support exchange-based
       aggregation (in addition to current provider-based aggregation) it is
       not dependent on exchanges for its overall route aggregation
       properties.  It will provide efficient route aggregation with only
       provider-based aggregation.
       このアドレスフォーマットが(現在のプロバイダベースの集約のほかに)交
       換ベースの集約をサポートするよう意図されるが、全体的経路集約特性は交
       換に依存していません。これはプロバイダベース集約だけに効率的な経路集
       約を提供するでしょう。
    
       The aggregatable global unicast address format as defined in [AGGR]
       is as follows:
       [AGGR]で定義された集約グローバルユニキャストアドレスフォーマットは
       次の通りです:
    
          | 3|  13 | 8 |   24   |   16   |          64 bits               |
          +--+-----+---+--------+--------+--------------------------------+
          |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
          |  | ID  |   |  ID    |  ID    |                                |
          +--+-----+---+--------+--------+--------------------------------+
    
          <--Public Topology--->   Site
             公共トポロジ       <-------->
                                 Topology
                                  サイト  <------Interface Identifier----->
                                 トポロジ        インターフェース識別子
    
       Where
    
          FP           Format Prefix (001)
                       フォーマットプレフィックス
          TLA ID       Top-Level Aggregation Identifier
                       最上位集約識別子
          RES          Reserved for future use
                       未来の使用のために確保
          NLA ID       Next-Level Aggregation Identifier
                       次のレベル集約識別子
          SLA ID       Site-Level Aggregation Identifier
                       サイトレベル集約識別子
          INTERFACE ID Interface Identifier
                       インタフェース識別子
    
    4.0 Technical Motivation 
    4.0 技術的な動機
    
       The design choices for the size of the fields in the aggregatable
       address format were based on the need to meet a number of technical
       requirements that are described in [AGGR].  An extract of the
       technical requirements from [AGGR] is as follows:
       集約アドレスフォーマットフィールドの大きさのデザインの選択は[AGGR]
       で記述される多くの技術的条件を満たす必要に基づいていました。[AGGR]
       の技術的条件の抜粋が次の通りです:
    
          The size of the Top-Level Aggregation Identifier is 13 bits.  This
          allows for 8,192 TLA ID's.  This size was chosen to insure that
          the default-free routing table in top level routers in the
          Internet is kept within the limits, with a reasonable margin, of
          the current routing technology.  The margin is important because
          default-free routers will also carry a significant number of
          longer (i.e., more-specific) prefixes for optimizing paths
          internal to a TLA and between TLAs.
          最上位集約識別子の大きさは13ビットです。これは8,192のTLA
          識別子を考慮します。この大きさはインターネットで最上位ルーターのデ
          フォルトルートのないルーティングテーブルの限界内で、合理的な余裕を
          持って、現在のルーティング技術で保持を保証できるように選ばれました。
          デフォルトルートのなしいルーターが、かなりの数のTLA内とTLA間の最適
          化パスの長い(つまりより特定された)プレフィックスを運ぶであろうか
          ら、この余裕は大切です。
    
          The important issue is not only the size of the default-free
          routing table, but the complexity of the topology that determines
          the number of copies of the default-free routes that a router must
          examine while computing a forwarding table.  In current practice
          with IPv4, it is common to see a prefix announced fifteen times
          via different paths.  The complexity of Internet topology is very
          likely to increase in the future.  It is important that IPv6
          default-free routing support additional complexity as well as a
          considerably larger internet.
          重要な問題はデフォルトルートのないルーティングテーブルの大きさだけ
          ではなくルーターが転送テーブルを計算する際に調べなくてはならない経
          路の数が多いというトポロジーの複雑さもです。現在のIPv4の実行で
          プレフィックスが異なるパスによって15回見つかるのは普通です。イン
          ターネットトポロジーの複雑さは将来増加する可能性が非常に高いです。
          IPv6のデフォルトルートのないルーティングが、大きいインターネッ
          トだけでなく、さらなる複雑さをサポートすることは重要です。
    
          It should be noted for comparison that the current IPv4 default-
          free routing table is approximately 50,000 prefixes.  While this
          shows that it is possible to support more routes than 8,192 it is
          matter of debate if the number of prefixes supported today in IPv4
          is already too high for current routing technology.  There are
          serious issues of route stability as well as cases of providers
          not supporting all top level prefixes.  The technical requirement
          was to pick a TLA ID size that was below, with a reasonable
          margin, what was being done with IPv4.
          比較のため現在のIPv4のデフォルトルートなしのルーティングテー
          ブルがおよそ50,000のプレフィックスであることを知るべきです。
          これは8,192より多くの経路のサポートが可能なことを示すので、も
          しIPv4の現在のプレフィックス数が現在のルーティング技術に大き
          すぎでなければ、討論の問題です。すべての最上位プレフィックスをサ
          ポートしていないプロバイダの場合、径路安定性の重大な問題がありま
          す。技術的条件はIPv4でされたより合理的余裕をもって、TLA識
          別子大きさを選ぶことでした。
    
          The choice of 13 bits for the TLA field was an engineering
          compromise.  Fewer bits would have been too small by not
          supporting enough top level organizations.  More bits would have
          exceeded what can be reasonably accommodated, with a reasonable
          margin, with current routing technology in order to deal with the
          issues described in the previous paragraphs.
          TLAフィールドのための13ビットの選択は工学的な妥協でした。こ
          れより少ないビットでは最上位組織のサポートに十分でないでしょう。
          これより多くのビットでは前の段落で記述した問題に合理的な余裕がな
          く、現在のルーティング技術で合理的に扱える限界を超えたでしょう。
    
          If in the future, routing technology improves to support a larger
          number of top level routes in the default-free routing tables
          there are two choices on how to increase the number TLA
          identifiers.  The first is to expand the TLA ID field into the
          reserved field.  This would increase the number of TLA ID's to
          approximately 2 million.  The second approach is to allocate
          another format prefix (FP) for use with this address format.
          Either or a combination of these approaches allows the number of
          TLA ID's to increase significantly.
          もし将来、デフォルト経路なしのルーティングテーブルのルーティング技
          術がより多くの最上位経路をサポートするほど良くなるなら、TLA識別
          子の数を増やす2つの方法があります。1つは予約のフィールドにTLA
          識別子フィールドを拡大する方法です。これはおよそ2百万個のTLA識
          別子になるでしょう。2番目の方法はこのアドレスフォーマットに使用す
          るために他のフォーマットプレフィックス(FP)を割り当てることです。
          いずれかあるいはこれらの方法の組み合わせでTLA識別子の数を増加で
          きます。
    
          The size of the Reserved field is 8 bits.  This size was chosen to
          allow significant growth of either the TLA ID and/or the NLA ID
          fields.
          予約のフィールドの大きさは8ビットです。この大きさはTLA識別子や
          NLA識別子フィールドの増加が可能なように選ばれました。
    
          The size of the Next-Level Aggregation Identifier field is 24
          bits.  This allows for approximately sixteen million NLA ID's if
          used in a flat manner.  Used hierarchically it allows for a
          complexity roughly equivalent to the IPv4 address space (assuming
          an average network size of 254 interfaces).  If in the future
          additional room for complexity is needed in the NLA ID, this may
          be accommodated by extending the NLA ID into the Reserved field.
          次のレベル集約識別子フィールドの大きさは24ビットです。これは、も
          し単純な方法で使われる場合に、およそ1千6百万のNLA識別子が可能
          です。階層的に使われる場合、これはおよそIPv4アドレス空間と同じ
          ぐらいの複雑さが可能です(平均的なネットワークサイズを254インタ
          フェースと想定している)。もし将来複雑さのための追加の余地がNLA
          識別子で必要なら、予約のフィールド内にNLA識別子を拡張できるかも
          しれません。
    
          The size of the Site-Level Aggregation Identifier field is 16
          bits.  This supports 65,535 individual subnets per site.  The
          design goal for the size of this field was to be sufficient for
          all but the largest of organizations.  Organizations which need
          additional subnets can arrange with the organization they are
          obtaining Internet service from to obtain additional site
          identifiers and use this to create additional subnets.
          サイトレベル集約識別子フィールドの大きさは16ビットです。これはサ
          イト毎に65,535の個別のサブネットをサポートします。このフィー
          ルドの大きさのデザイン目標はほとんどの大きな組織に十分なサイズです。
          追加のサブネットを必要とする組織はインターネットサービスを得ている
          組織から追加のサイト識別子を得て、そして追加のサブネットを作るため
          にこれを使うことができます。
    
          The Site-Level Aggregation Identifier field was given a fixed size
          in order to force the length of all prefixes identifying a
          particular site to be the same length (i.e., 48 bits).  This
          facilitates movement of sites in the topology (e.g., changing
          service providers and multi-homing to multiple service providers).
          サイトレベル集約識別子フィールドはすべての特定のサイトを識別するプ
          レフィックスの長さが同じ長さ(すなわち、48ビット)になることを強
          いるために固定した大きさを与えらました。これはネットワーク上でのサ
          イトの動きを容易にします(例えば、サービスプロバイダの変更や多数サー
          ビスプロバイダへのマルチ帰属など)。
    
          The Interface ID Interface Identifier field is 64 bits.  This size
          was chosen to meet the requirement specified in [ARCH] to support
          EUI-64 based Interface Identifiers.
          インタフェース識別子フィールドは64ビットです。この大きさはEUI-64
          ベースのインタフェース識別子をサポートするために[ARCH]で指定された
          必要条件を満たすように選ばれました。
    
       The proposed TLA/NLA assignment rules described in this document are
       consistent with these technical requirements.
       この文書で記述され提案されたTLA/NLA割当て規則は、技術的条件一
       致しています。
    
       The specific technical motivation for the proposed TLA/NLA assignment
       rules described in this document is as follows:
       この文書で記述し提案されたTLA/NLA割当て規則の具体的な技術的動
       機は次の通りです:
    
        - Limit the number of top level prefixes in the Internet to a
          manageable size.  This is important to insure that the default-
          free routing table in the top level routers in the Internet is
          kept within the limits, with a reasonable margin, of current
          routing technology.
        - インターネットの最上位プレフィックスの数を処理しやすい大きさに制限
          してください。これはインターネットの最上位ルーターでのデフォルト経
          路なしのルーティングテーブルの制限内で、合理的な余裕を持って、現在
          のルーティング技術で維持できることを保証するために重要です。
    
        - Only assign top level prefixes to transit providers, not to leaf
          sites even if they are multiply homed.  The aggregation address
          format is designed to have a clear separation between transit
          providers and leaf sites.  Sites which wish to be multihomed to
          multiple transit providers have in IPv6 a number of alternatives
          to having a top level prefix.
        - 末端ではなく中継プロバイダだけに最上位プレフィックスの割当てをして
          ください、サイトがたとえ(マルチホームでも割当てないで下さい。集約
          アドレスフォーマットは中継プロバイダと末端サイト間に明確な区別を持
          つよう意図されます。多数の中継プロバイダにマルチホームすることを望
          むサイトが最上位プレフィックスを持つことに関してIPv6で多くの選
          択肢を持っています。
    
        - Only assign top level prefixes to organizations who are capable
          and intend to provide operational IPv6 transit services within
          three months of assignment.  The goal is to not assign top level
          prefixes to organizations who only want a prefix in case they
          might provide service sometime in the future.  The assignment of
          prefixes is intended to closely match the operational IPv6
          Internet and to be consistent with the current practice of
          registries making assignments when addresses are actually used.
        - ただ最上位プレフィックスを、アドレス割当て後3ヶ月以内にIPv6中継
          サービスの運用を解する能力と意思のある組織にだけ割当ててください。
          将来いつかサービスする場合に備えて最上位プレフィックスを欲しいだけ
          の組織に割り当てないことです。プレフィックスの割当てと利用可能な
          IPv6インターネットをぴったりと一致させ、アドレスが実際に使われ
          る時、レジストリが割当をする課という状態でいるように意図されます。
    
        - Organizations assigned TLA ID's are required to make all the
          assignments publically available.  This is necessary in order for
          the registries to have accurate information on assignments and to
          enable trouble shooting Internet problems.
        - TLA識別子を割り当てられた組織がすべての割当を公に利用可能にする
          ように要求されます。これは登記所が割当てに関する正確な情報を持ち、
          そしてインターネットの故障対応を可能にするために必要です。
    
        - Allocation of prefixes that are consistent with the address format
          in [AGGR].  Specifically the allocation prefixes that are not
          longer than 48 bits as to not infringe into the SLA and Interface
          Identifier fields.  This is to facilitate movement of sites in the
          topology (e.g., changing service providers and multi-homing to
          multiple service providers).
          [AGGR]のアドレスフォーマットと整合の取れたプレフィックスの割り当て。
          特に、SLAとインタフェースの識別子フィールドを侵害しないように、48
          ビットより長くない割り当てプレフィックス。これはネットワーク上での
          サイトの動きを容易にするはずです(例えば、サービスプロバイダの変化
          や多数のサービスプロバイダへのマルチホーム)。
    
    5.0 Proposed Rules for Assignment of Top-Level Aggregation ID's 
    5.0 最上位集約識別子の割当てのための提案された規則
    
       TLA ID's are assigned to organizations providing transit topology.
       They are specifically not assigned to organizations only providing
       leaf topology.  TLA ID assignment does not imply ownership.  It does
       imply stewardship over a valuable Internet resource.
       TLA識別子は中継ネットワークを提供する組織に割り当てられます。特に
       ただ末端ネットワークを提供するだけの組織に割り当てられません。TLA
       識別子の割当てが所有権を暗示しません。それは貴重なインターネットリソー
       スの責務を暗示します。
    
       The IAB and IESG have authorized the Internet Assigned Numbers
       Authority (IANA) as the appropriate entity to have the responsibility
       for the management of the IPv6 address space as defined in [ALLOC].
       IABとIESGは適切な実体としてインターネット番号割当当局(IANA)に[ALLOC]
       で定義されるように、IPv6アドレス空間の管理に対する責任を持つ権限
       を与えました。
    
       The IANA will assign small blocks (e.g., few hundred) of TLA ID's to
       registries.  The registries will assign the TLA ID's to organizations
       meeting the requirements for TLA ID assignment.  When the registries
       have assigned all of their TLA ID's they can request that the IANA
       give them another block.  The blocks do not have to be contiguous.
       The IANA may also assign TLA ID's to organizations directly.  This
       includes the temporary TLA assignment for testing and experimental
       usage for activities such as the 6bone or new approaches like
       exchanges.
       IANAはTLA識別子の小さいブロック(例えば、数百)を登記所に割り当て
       ないでしょう。登記所はTLA識別子割当ての必要条件を満たす組織にTL
       A識別子を割り当てるでしょう。登記所がすべてのTLAに識別子を割り当
       てた時、IANAにもう1つのブロックを要求できます。ブロックは連続的でな
       くてもよいです。IANAはTLA識別子を組織に直接割り当てるかもしれませ
       ん。これは6boneあるいは交換のような新しいアプローチの活動のテス
       トや実験的な利用のための一時的なTLA割当てを含みます。
    
    5.1 Proposed TLA Allocation Stages 
    5.1 TLA割当て手順の提案
    
       TLA allocations will be done in two stages.  The first stage is to
       allocate a Sub-TLA ID.  When the recipient has demonstrated that they
       have assigned more than 90% of the NLA ID for their Sub-TLA ID, they
       will be allocated a TLA ID.  The Sub-TLA ID does not have to be
       returned.
       TLA割当てが2段階でされるでしょう。最初の段階は副TLA識別子を割
       り当てることです。受取人が副TLA識別子のNLA識別子の90%以上を
       割り当てたことを明示した時、彼らはTLAIDを割り当てられるでしょう。
       副TLA識別子は返されなくてもよいです。
    
       Sub-TLA ID's are assigned out of TLA ID 0x0001 as follows.  Note that
       use of the Reserved field to create the Sub-TLA field is specific to
       TLA ID 0x0001.  It does not affect any other TLA.
       副TLA識別子は次のようにTLA識別子0x0001 から割り当てられます。
       副TLAフィールドを作るための予のフィールドがTLA識別子0x0001
       に特有なことに注意してください。これは他のTLAに影響を与えません。
    
          | 3  |    13    |    13   |       19      |
          +----+----------+---------+---------------+
          | FP |   TLA    | Sub-TLA |       NLA     |
          |    |   ID     |         |       ID      |
          +----+----------+---------+---------------+
    
       where:
    
        FP = 001 = Format Prefix
                   フォーマットプレフィックス
    
           This is the Format Prefix used to identify aggregatable global
           unicast addresses.
           これはグローバル集約ユニキャストアドレスを示すフォーマットプレ
           フィックスです。
    
        TLA ID = 0x0001 = Top-Level Aggregation Identifier
                          最上位集約識別子
    
           This is the TLA ID assigned by the IANA for Sub-TLA allocation.
           これは副TLAの割当てのためIANAが割当るTLA識別子です。
    
        Sub-TLA ID = Sub-TLA Aggregation Identifier
                     副TLA集約識別子。
    
           The Sub-TLA ID field is used by the registries for initial
           allocations to organizations meeting the requirements in Section
           5.2 of this document.  The IANA will assign small blocks (e.g.,
           few hundred) of Sub-TLA ID's to registries.  The registries will
           assign the Sub-TLA ID's to organizations meeting the requirements
           specified in Section 5.2.  When the registries have assigned all
           of their Sub-TLA ID's they can request that the IANA give them
           another block.  The blocks do not have to be contiguous.  The
           IANA may also assign Sub-TLA ID's to organizations directly.
           This includes the temporary TLA assignment for testing and
           experimental usage for activities such as the 6bone or new
           approaches like exchanges.
           副TLAの識別子フィールドは、この文書の5.2章の必要条件を満たす
           組織へ、登記所が最初の配布をする際に使われます。IANAは副TLA識
           別子の小さいブロック(例えば、数百)を登記所に割り当てないでしょう。
           登記所は5.2章で指定された副TLAの識別子の必要条件を満たす組織
           に割り当てるでしょう。登記所がすべての副TLA識別子を割り当てた時、
           IANAにもう1つのブロックを要求できます。ブロックは連続的でなくても
           よいです。IANAはTLA識別子を組織に直接割り当てるかもしれません。
           これは6boneあるいは交換のような新しいアプローチの活動のテスト
           や実験的な利用のための一時的なTLA割当てを含みます。
    
        NLA ID = Next-Level Aggregation Identifier
                 次のレベル集約識別子
    
           Next-Level Aggregation ID's are used by organizations assigned a
           TLA ID to create an addressing hierarchy and to identify sites.
           The organization can assign the top part of the NLA ID in a
           manner to create an addressing hierarchy appropriate to its
           network.  See Section 6.0 for more detail.
           次のレベル集約識別子はアドレス階層を作ったり、サイトを識別するた
           めにTLA識別子を割り当てられた組織によって使われます。組織はそ
           のネットワークに適切なアドレス階層を作るためにNLA識別子の一番
           上の部分を割当てることができます。詳細は6.0章を見てください。
    
       Sub-TLA allocations are interim until the organization receiving the
       Sub-TLA can show evidence of IPv6 Internet transit service.  If
       transit service can not be demonstrated by three months from the date
       of allocation the Sub-TLA allocation will be revoked.
       副TLAの配分が、組織が副TLAを受け取ってから、IPv6インターネット
       中継サービスの証拠を示すまで、仮の割当てです。もし割当て日から3ヶ月
       以内に中継サービスが実施されないなら、副TLAの割当は無効にされるで
       しょう。
    
       As part of assigning a TLA ID to an organization, the IANA or
       Registries may initially only assign a fraction of the NLA ID space
       for a particular TLA ID to the organization receiving the TLA ID
       assignment.  When the organization has assigned more than 90% of the
       NLA ID space it may request additional NLA ID space in its TLA ID.
       組織にTLA識別子を割当てることについて、IANAや登記所が初めその組織
       にそのTLA識別子のNLA識別子空間の一部だけ割り当てるかもしれませ
       ん。組織がNLA識別子空間の90%以上を割り当てた時、そのTLA識別
       子で追加のNLA識別子空間を求めるかもしれません。
    
    5.2 Proposed Assignment Requirements 
    5.2 割当て必要条件の提言
    
       The proposed assignment requirements are intended as input from the
       IPng working group to the IANA and Registries.  It is not intended
       for any official IETF status.
       提言された割当て条件は IPngワークグループからIANAと登記所へのインプッ
       トを意図します。そこれはどんな公のIETFステータスを意図しません。
    
       Registries enforce the following requirements for organizations
       assigned Sub-TLA and TLA ID's:
       登記所が副TLAとTLA識別子を割当てる組織に次の条件を強制します:
    
       1) Must have a plan to offer native IPv6 service within 3 months from
          assignment.  The plan must include NLA ID allocation and
          registration procedures.  NLA ID allocation and registration may
          be subcontracted to other organizations such as a registry.
       1) 割当てから3カ月以内にネイティブIPv6サービスをする計画を持たな
          くてはなりません。計画はNLA識別子配布と登録手順を含まなくてはな
          りません。NLA識別子割当てと登録が登記所のような他の組織に下請け
          契約されるかもしれません。
    
          Native IPv6 service is defined as providing IPv6 service as
          defined in the appropriate "IPv6 over <link>" specification such
          as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.,
          for the link at the boundary of the organization.  This should
          include running Neighbor Discovery (as appropriate) and exchanging
          IPv6 routing information.  The method the organization uses to
          carry IPv6 traffic across its network is independent of this
          definition and is a local issue for the organization.
          組織の境界のリンクで、「イーサネットの上のIPv6」[ETHER]、「FDDI
          の上のIPv6」[FDDI]などの「<リンク>上のIPv6」仕様書で定義
          された適切なIPv6サービスを提供する事を、ネイティブIPv6サー
          ビスと定義します。これは近隣探索を動かし、IPv6ルーティング情報
          を交換することを含むべきです。組織が自己のネットワーク内でIPv6
          トラフィックを運ぶ方法はこの定義とは独立で、組織の個別の問題です。
    
       2) Must have a verifiable track record of providing Internet transit
          to other organizations.  Sub-TLA and/or TLA ID's must not be
          assigned to organizations that are only providing leaf service
          even if multihomed.
       2) 他の組織にインターネット中継を供給する証明可能な実績を持たなくては
          なりません。副TLAやTLA識別子は、たとえマルチホームでも、末端
          サービスを供給するだけの組織に割当ててはなりません。
    
          Verification of an organization's track record in providing
          Internet transit service must be verified by techniques such as
          traceroute, BGP advertisements, etc.
          インターネット中継サービスを提供する組織の実績の証明がtraceroute、
          BGP広告などのテクニックで実証されなくてはなりません。
    
       3) Payment of a registration fee to the Internet Assigned Numbers
          Authority (IANA).  Registries may also charge some fee for
          services rendered, generally in relation to the cost of providing
          those services.  All payment of registration and service fees must
          be made prior to the actual Sub-TLA ID and/or TLA ID assignment.
       3) インターネット番号割当当局(IANA)への登録料金の支払い。登記所がサー
          ビスに対する料金、一般的には登録サービスを供給するのにかかるコスト
          を、請求するかもしれません。すべての登録とサービス料金の支払いは実
          際の副TLA識別子やTLA識別子の割当て前に行われなければなりません。
    
       4) Must provide registry services for the NLA ID address space it is
          responsible for under its Sub-TLA ID and/or TLA ID.  This must
          include both sites and next level providers.  The database of NLA
          assignments must be public and made available to the registries.
       4) 副TLA識別子やTLA識別子下でNLA識別子アドレス空間の登録サー
          ビスを提供しなくてはなりません。これはサイトや次のレベルのプロバイ
          ダの両方を含まなくてはなりません。NLA割当てのデータベースは公で
          あり、登記所に入手可能でなくてはなりません。
    
       5) Periodically (interval set by registry) provide to registry
          utilization statistics of the Sub-TLA ID and/or TLA ID it has
          custody of.  The organization must also show evidence of carrying
          TLA routing and transit traffic.  This can be in the form of
          traffic statistics, traceroutes, routing table dumps, or similar
          means.
       5) 定期的に(期間は登記所が定める)、割当てられている副TLA識別子や
          TLD識別子の登記所統計値を供給してください。組織は同じくTLAルー
          ティングと中継トラフィックを運ぶ証拠を示さなくてはなりません。これ
          はトラフィック統計値、 traceroutes 、ルーティングテーブルダンプ、
          あるいは類似の手段のかたちであり得ます。
    
       6) Organizations requesting another Sub-TLA and/or TLA ID must show
          evidence to the registries that they have assigned more than 90%
          of the NLA ID space in their previous allocations.
       6) 追加の副TLAやTLA識別子を要求する組織は、以前に割当てられた中
          から90%以上のアドレス空間を割当てている証拠を示さなくてはなりま
          せん。
    
       Organizations which are given custody of a Sub-TLA ID and/or TLA ID,
       and fail to continue to meet all the above requirements may have the
       Sub-TLA ID and/or TLA ID custody revoked.
       副TLA識別子やTLA識別子を持つ組織が、上記の必要条件を満たし続け
       るのに失敗すると、副TLA識別子やTLA識別子は無効になります。
    
    6.0 Proposed Rules Assignment of Next-Level Aggregation ID's 
    6.0 次のレベル集約識別子の割当て規則の提案
    
       Next-Level Aggregation ID's are used by organizations assigned a
       Sub-TLA ID and/or TLA ID to create an addressing hierarchy and to
       identify sites.  The organization can assign the top part of the NLA
       ID in a manner to create an addressing hierarchy appropriate to its
       network.
       次のレベル集約識別子はアドレス階層を作り、サイト識別するため、副TLA
       識別子とTLA識別子を割り当てられた組織によって使われます。組織はネッ
       トワークに適切なアドレス階層作る方法でNLA識別子の一番上の部分を割り
       当てることができます。
    
       Registries may initially only assign a fraction of the NLA ID space
       for a particular Sub-TLA ID and/or TLA ID to the organization
       receiving the Sub-TLA ID and/or TLA ID assignment.  When the
       organization has assigned more than 90% of the NLA ID space it may
       request additional NLA ID space in its Sub-TLA ID and/or TLA ID.
       登記所が初め特定の副TLA識別子やTLA識別子の空間の一部だけを副T
       LA識別子やTLA識別子を受け取る組織に割り当てるかもしれません。組
       織がNLA識別子空間の90%以上を割り当てた時、副TLA識別子やTL
       A識別子の追加のNLA識別子空間をを求めるかもしれません。
    
       Organizations assigned Sub-TLA ID and/or TLA ID's are required to
       assume (directly or indirectly) registry duties for the NLA ID's they
       assign.  Each organization assigned a NLA ID is required to assume
       registry duties for the next level NLA ID's it assigns and follow
       Registry guidelines.  This responsibility includes passing this
       information back to the registry that assigned the TLA and/or
       Sub-TLA.  The TLA ID and/or Sub-TLA ID holder collects this
       information from the next level, the next level holder collects this
       information from the level below, etc.
       副TLA識別子やTLA識別子を割当てられた組織が、組織の割当てるNL
       A識別子の(直接的か間接的に)仮登記所の役割を要求されます。NLA識
       別子を割当てられた組織が、組織が割り当てる次のレベルのNLA識別子の
       仮登記所の役割を要求されます。この責任はTLAや副TLAを割当てたレ
       ジストリにこの情報を渡すことを含みます。TLA識別子と副TLA識別子
       の保有者は次のレベルの情報と、次のレベルの保有者が下のレベルから集め
       た情報を集めます。
    
       The design of the bit layout of the NLA ID space for a specific
       Sub-TLA ID and/or TLA ID is left to the organization responsible for
       that Sub-TLA ID and/or TLA ID.  Likewise the design of the bit layout
       of the next level NLA ID is the responsibility of the organization
       assigned the previous level NLA ID.  It is recommended that
       organizations assigning NLA address space use "slow start" allocation
       procedures as is currently done with IPv4 CIDR blocks [CIDR].
       特定の副TLA識別子やTLA識別子でのNLA識別子空間のビット配置の
       デザインはその副TLA識別子やTLA識別子に関して責任がある組織に任
       せられます。同じく次のレベルのNLA識別子のビット配置のデザインは前
       のレベルNLA識別子を割り当てられる組織の責任です。NLAアドレス空
       間を割り当てている組織が、現在IPv4 CIDRブロック[CIDR]で行われてい
       るように「ゆっくりスタート」割当てて順を使うことが勧められます。
    
       The design of an NLA ID allocation plan is a tradeoff between routing
       aggregation efficiency and flexibility.  Creating hierarchies allows
       for greater amount of aggregation and results in smaller routing
       tables.  Flat NLA ID assignment provides for easier allocation and
       attachment flexibility, but results in larger routing tables.
       NLA識別子配布計画のデザインはルーティング集約効率と柔軟性の間のト
       レードオフです。階層を作ることで大きい集約が可能になり結果としてより
       小さいルーティングテーブルで済みます。単純なNLA識別子割当てがより
       容易な割当てと取り付け柔軟性を持ちます、しかしより大きいルーティング
       テーブルをもたらします。
    
    7.0 Acknowledgments 
    7.0 謝辞
    
       The author would like to express his thanks to Thomas Narten, Steve
       Deering, Bob Fink, Matt Crawford, Rebecca Nitzan, Allison Mankin, Jim
       Bound, Christian Huitema, Scott Bradner, Brian Carpenter, John
       Stewart, Eric Hoffman, Jon Postel, Daniel Karrenberg, Kim Hubbard,
       Mirjam Kuehne, Paula Caslav, David Conrad, and David Kessens for
       their review and constructive comments.
       彼らの批評と建設的なコメントのため著者Thomas Narten, Steve Deering,
       Bob Fink, Matt Crawford, Rebecca Nitzan, Allison Mankin, Jim Bound,
       Christian Huitema, Scott Bradner, Brian Carpenter, John Stewart,
       Eric Hoffman, Jon Postel, Daniel Karrenberg, Kim Hubbard, Mirjam Kuehne,
       Paula Caslav, David Conrad, David Kessensに感謝をしたいです。
    
    8.0 Security Considerations 
    8.0 セキュリティの考慮
    
       IPv6 addressing documents do not have any direct impact on Internet
       infrastructure security.  Authentication of IPv6 packets is defined
       in [AUTH].  Authentication of the ownership of prefixes to avoid
       "prefix stealing" is a related security issue but is beyond the scope
       of this document.
       IPv6アドレスの文書がインターネット基盤セキュリティに直接の影響を
       持っていません。IPv6パケットの認証が[AUTH]で定義されます。「プレ
       フィックスを盗むこと」を避けるためのプレフィックスの所有権の認証は関
       連したセキュリティ問題です、しかしこの文書の範囲を越えてます。
    
    9.0 References 
    9.0 参考文献
    
       [AGGR]    Hinden, R., Deering, S. and M. O'Dell, "An Aggregatable
                 Global Unicast Address Format", RFC 2374, July 1998.
    
       [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management", RFC
                 1881, December 1995.
    
       [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture", RFC
                 2373, July 1998.
    
       [AUTH]    Atkinson, R. and  S. Kent, "IP Authentication Header", RFC
                 2402, November 1998.
    
       [CIDR]    Fuller, V., Li, T., Varadhan, K. and J. Yu, "Classless
                 Inter-Domain Routing (CIDR): an Address Assignment and
                 Aggregation Strategy", RFC 1519, September 1993.
    
       [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
                 Networks", RFC 2464, December 1998.
    
       [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
                 Networks", RFC 2467, December 1998.
    
       [IPV6]    Deering, S. and R. Hinden, Editors, "Internet Protocol,
                 Version 6 (IPv6) Specification", RFC 2460, December 1998.
    
       [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.
    
    10.0 Author's Address 
    10.0 著者のアドレス
    
       Robert M. Hinden
       Nokia
       232 Java Drive
       Sunnyvale, CA 94089
       USA
    
       Phone: +1 408 990-2004
       EMail: hinden@iprg.nokia.com
    
    11.0  Full Copyright Statement 
    11.0  著作権表示全文
    
       Copyright (C) The Internet Society (1998).  All Rights Reserved.
       著作権(C)インターネット学会(1998)。すべての権利は保留される。
    
       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.
       この文書とここに含む情報は無保証で供給され、そしてインターネット学会
       とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
       報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
       ある事の保障を含め、すべての保証を拒否します。
    

    Japanese translation by Ishida So