この文書はRFC2921の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group B. Fink Request for Comments: 2921 ESnet Category: Informational September 2000 6BONE pTLA and pNLA Formats (pTLA) 6boneのpTLAとpNLA形式(pTLA) 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 (2000). All Rights Reserved. Abstract 概要 This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation", [6BONE-TLA], to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). このメモは、6boneでRFC 2471「IPv6テストアドレス割り当て」 [6BONE-TLA]で割り当てられた3FFE::/16のIPv6アドレスプレフィッ クスを使うか、疑似最上位集約識別子(pTLA)と疑似次上位集約識別子 (pNLA)を作るかを定義します。 Acknowledgements 謝辞 The address formats here are contributions of various early participants of the 6bone testbed project, and of the IPng and NGtrans IETF working groups. アドレスフォーマットは6boneテストベッドプロジェクトの初期の関係 者と、IPngとNGtrans IETFワーキンググループの関係者の貢献です。 Table of Contents (目次) 1. Introduction (はじめに) 2. 6BONE pTLA and pNLA Formats (6boneのpTLAとpNLAフォーマット) 3. Security Considerations (セキュリティの考慮) References (参照) Author's Address (著者のアドレス) Full Copyright Statement (著作権表示全文) 1. Introduction 1. はじめに This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471 [6BONE-TLA], to create pseudo Top-Level Aggregation Identifiers (pTLA) and pseudo Next-Level Aggregation Identifiers (pNLA). このメモは、6boneでRFC 2471[6BONE-TLA]で割り当てられた3FFE::/16の IPv6アドレスプレフィックスを使うか、疑似最上位集約識別子(pTLA) と疑似次上位集約識別子(pNLA)を作るかを定義します。 The guiding specifications for IPv6 addressing relating to the 6bone prefix, and the pTLA and pNLA formats, are "IP Version 6 Addressing Architecture" [ADDRARCH], and "An IPv6 Aggregatable Global Unicast Address Format" [AGGR]. 6boneプレフィックスのアドレスの割当てと、pTLAとpNLAのフォー マットは「IPバージョン6アドレス構造」[ADDRARCH]とと「IPv6集約グ ローバルなユニキャストアドレスフォーマット」[AGGR]で指定されます。 The purpose of creating pseudo TLA and NLA formats for the 6bone is to provide a prototype of the actual TLA and NLA formats as they might be used in production IPv6 networks. To do this economically, using only a minimum of real production IPv6 address space, a single TLA, 3FFE::/16, was reserved by the IANA (Internet Assigned Numbers Authority) for testing on the 6bone. Thus it was necessary to define a pretend-to-be, or pseudo, TLA and NLA structure to use under the 3FFE::/16 prefix. 6boneの疑似TLAとNLAフォーマットを作る目的は、商用IPv6ネット ワークで使われるかもしれないような実際のTLAとNLAフォーマットのプロト タイプの供給です。経済的にこれを行うため、実際の商用IPv6アドレス の1つの最小部分3ffe::/16がIANA(インターネット番号割当権威)によって 6boneに割当てられました。それで3ffe::/16下でTLAとNLAの構造定義を 真似る、あるいは擬似することの定義が必要でした。 Given the 48-bit length of the IPv6 Aggregatable Global Unicast Address external routing prefix (that contains the TLA and NLA identifiers), there is enough room to extend the TLA ID to contain a pTLA and shorten the NLA ID to become a pNLA. This document specifies this. (TLAとNLA識別子を含む)IPv6集約グローバルユニキャストアドレスの外 部ルーティングプレフィックスが48ビット長という条件のもとで、 pTLAを 含むTLA IDを拡張し、NLA IDを短くしてpNLAするのに十分な場所があり ます。この文書はこれを指定します。 In early 1999, it was decided to change the 6bone's pTLA format to allow greater expansion of the testbed network, thus accommodating more than the original 256 pTLA-s. Thus there are now two 6bone pTLA and pNLA formats. This document specifies this. 1999年の早い時期に、それまでの256個のpTLAからより多きく受 け入れて、テストベッドネットワークのより大きい拡大を許すために6bo neのpTLAフォーマットを変えることが決められました。それで今2つ の6boneのpTLAとpNLAフォーマットがあります。この文書はこ れを指定します。 2. 6BONE pTLA and pNLA Formats 2. 6boneのpTLAとpNLAフォーマット 2.1 Original 8-bit pTLA and 24-bit pNLA Format 2.1 元の8ビットpTLAと24ビットpNLAフォーマット The original pTLA and pNLA format was intended to accommodate 256 pTLA-s, i.e., backbone networks carrying IPv6 transit traffic. 元のpTLAとpNLAフォーマットは、256のpTLA、つまりバック ボーンネットワークがIPv6輸送トラフィックを運ぶのを可能にするよう に意図されました。 The original TLA and NLA ID-s as specified in [AGGR] are as follows: [AGGR]で指定された元のTLAとNLA識別子は次の通りです: | 3 | 13 | 32 | 16 | 64 bits | +---+-----+---------------------+--------+-----------------+ |001| TLA | NLA ID | SLA ID | Interface ID | +---+-----+---------------------+--------+-----------------+ The TLA value 1FFE was assigned to the 6bone, which when viewed with the 3-bit format prefix in prefix notation form is 3FFE::/16. TLA値1FFEは6boneに割り当てられ、3ビットのフォーマットプレ フィックスと共にあるとプレフィックス表記形式で3FFE::/16です。 The first 8-bits of the NLA ID space are assigned as the pTLA that defines the top level of aggregation (backbone) for the 6bone. This provides for 256 6bone backbone networks, or pTLA-s, and leaves a 24-bit pNLA ID for each pTLA to assign as needed. NLA識別子空間の最初の8ビットは6boneの最上位レベル集約 (バックボーン)を定義するpTLAとして割り当てられます。これは 256の6boneバックボーンネットワーク、あるいはpTLAを供給 して、それぞれのpTLAに必要に応じて割り当てるべき24ビットのp NLA識別子を委ねます。 | 16 | 8 | 24 | 16 | 64 bits | +-+---------+-----+-------------+--------+-----------------+ | 0x3FFE |pTLA | pNLA | SLA ID | Interface ID | +-+---------+-----+-------------+--------+-----------------+ In prefix notation form the pTLA is 3FFE:nn00::/24, where nn is the pTLA assignment. nnをpTLAの割当とすると、プレフィックス表記形式でpTLAは 3FFE:nn00::/24です。 The remaining NLA ID space can be used by each pTLA for their downward aggregated delegation: 残っているNLA識別子空間はpTLAから下方への集約委任のために各 pTLAによって使うことができます:。 | n | 24-n bits | 16 | 64 bits | +-----+--------------------+--------+-----------------+ |pNLA1| Site | SLA ID | Interface ID | +-----+--------------------+--------+-----------------+ | m | 24-n-m | 16 | 64 bits | +-----+--------------+--------+-----------------+ |pNLA2| Site | SLA ID | Interface ID | +-----+--------------+--------+-----------------+ | o |24-n-m-o| 16 | 64 bits | +-----+--------+--------+-----------------+ |pNLA3| Site | SLA ID | Interface ID | +-----+--------+--------+-----------------+ The pNLA delegation works in the same manner as specified in [AGGR]. pTLA's are required to assume registry duties for the pNLA's below them, pNLA1's for those below them, etc. pNLA委任は[AGGR]で指定されのと同じ方法で働きます。pTLAのが、 下のpNLAのための仮登記所任務をするように要求され、pNLA1が それらの下のためです。 2.2 New 12-bit pTLA and 20-bit pNLA Format 2.2 新しい12ビットpTLAと20ビットpNLAフォーマット After it became clear that the 6bone would become a useful testbed for transition, in addition to its early role as a testbed for specifications and implementations, the 6bone community decided to expand the size of the pTLA ID. 6boneが移行の有用なテストベッドであることは明確になった後、6 bone共同体はその初期の役割のほかに仕様と実装のテストベッドとし てpTLA識別子の大きさを拡大することに決めました。 Several important decisions regarding this expansion of the pTLA field are: このpTLAフィールドの拡大に関係しているいくつかの重要な決定は 以下です: 1. to leave the currently allocated 8-bit pTLA-s in use until the space was needed, thus relying on a range value check to indicate the new pTLA format, 1. 新しいpTLAフォーマットか確認する方法を範囲値確認に頼り、アドレ ス空間が必要になるまで現在使用中の割り当てられた8ビットのpTLA をそのままにする。 2. to use a modulo 4-bit sized pTLA ID to make reverse path entry into the DNS easier, 2. より容易にDNSの逆引きを作れるように4ビットで割り切れる大きさの pTLAIDを使うはずです。 3. given 2. above, to keep the pTLA ID size as small as possible to not restrict pNLA ID size. 3. 上記2つに加えて、pNLA識別子の大きさを限定しないようにpTLA 識別子の大きさを可能な限り小さくしておきます。 Therefore, the first 12-bits of the NLA ID space are assigned as the pTLA that defines the top level of aggegation (backbone) for the 6bone. This would eventually provide for 4096 6bone backbone networks, or pTLA-s, and leaves a 20-bit pNLA ID for each pTLA to assign as needed. それ故に、NLA識別子空間の最初の12ビットを6boneの最上位集約 レベル(バックボーン)と定義しpTLAとして割り当てられます。これは 結局は4096の6boneバックボーンネットワーク、あるいはpTLA を提供するでしょう、そして各pTLAが必要に応じて割り当てるべき20 ビットのpNLA識別子を残します。 | 16 | 12 | 20 | 16 | 64 bits | +-+---------+-------+-----------+--------+-----------------+ | 0x3FFE | pTLA | pNLA | SLA ID | Interface ID | +-+---------+-------+-----------+--------+-----------------+ In prefix notation form the pTLA is 3FFE:nnn0::/28, where nnn is the pTLA assignment. However, as the existing 8-bit pTLA's are being left in use for the present, the nnn value starts at 0x800 for now, thus yielding only 2048 pTLA's in this new format. nnnをpTLA割当てとするとプレフィックス表記形式でpTLAは 3FFE:nnn0::/28である。既存の8ビットのpTLAのが当分使用中で残されて いるから、 nnnの値がしばらくは0x800で始まるとし、2048のpTLA がこの新しいフォーマットで可能です。 The remaining NLA ID space can be used by each pTLA for their downward aggregated delegation: 残っているNLA識別子空間は下方への集約委任のために各pTLAによって 使うことができます: | n | 20-n bits | 16 | 64 bits | +-----+--------------------+--------+-----------------+ |pNLA1| Site | SLA ID | Interface ID | +-----+--------------------+--------+-----------------+ | m | 20-n-m | 16 | 64 bits | +-----+--------------+--------+-----------------+ |pNLA2| Site | SLA ID | Interface ID | +-----+--------------+--------+-----------------+ | o |20-n-m-o| 16 | 64 bits | +-----+--------+--------+-----------------+ |pNLA3| Site | SLA ID | Interface ID | +-----+--------+--------+-----------------+ As with the original pTLA format, the pNLA delegation works in the same manner as specified in [AGGR]. pTLA's are required to assume registry duties for the pNLA's below them, pNLA1's for those below them, etc. 元のpTLAフォーマットと同じように、pNLA委任は[AGGR]で指定さ れるのと同じ方法で働きます。pTLAが下のpNLAのために仮登記所 任務をするように要求され、pNLA1がそれの下のためです。 2.3 Example Format For pNLA's 2.3 pNLAのフォーマット例 An example usage of the pNLA space is given to demonstrate what is reasonable and possible. It should not be assumed that this implies the pNLA space must be used this way. As the new pTLA and pNLA format is now the default, the example here assumes the 20-bit pNLA format. pNLA空間の合理的で実施可能な使用例を示します。pNLA空間がこの ように使われると想定すべきではありません。新しいpTLAとpNLA フォーマットが現在のデフォルトなので、この例では20ビットのpNLA フォーマットを想定します。 The following example provides for up to 255 intermediate transit ISP's (called pNLA1 below). The pNLA1 value of zero is meant to indicate that there is no intermediate transit ISP between the backbone pTLA network and the end user site. 次の例は最高255の中間ISP(以下pNLA1と呼ぶ)に備えます。pNLA1値 がゼロはバックボーンpTLAネットワークとエンドユーザーサイトの間に 中間ISPがないことを示します。 |<-----20-bit pNLA ID----->| | | | 8 | 12 bits | 16 | 64 bits | +-----+--------------------+--------+-----------------+ |pNLA1| Site ID | SLA ID | Interface ID | +-----+--------------------+--------+-----------------+ Intermediate transit networks (pNLA1's) would assign uniques Site ID's for eachend user site served. 中間ネットワーク(pNLA1)がエンドユーザサイトにユニークなサイト識 別子を割り当てるでしょう。 As an example of this, assuming a backbone pTLA of 0x800, no intermediate transit ISP (thus a pNLA1 of 0x00) and a sequential site ID (with start at the right edge numbering) of 0x0001, the routing prefix for the first site would look like: 0x800のバックボーンpTLAで、中間ISPがない(つまりpNLA1が0x00) で、連続に0x0001から識別子(番号に右側から割り当てる)を割り当て る例で、最初のサイトのプレフィックスは次の通りです: 3FFE:8000:0001/48 6bone _|||| |||| ||||___site |||| | b/b site____|||| | | | transit________|_| Another example of this usage, assuming the same backbone pTLA1 of 0x800 and an intermediate transit ISP under it (numbering from the left edge) with an NLA1 of 0x80, and a sequential site ID of 0x0001, the routing prefix for the first site connected would look like: 他の例として、0x800のpTLA1で、0x80の中間ISP(左から番号を 振る)の下にあり、サイト識別子が0x0001から連番の場合、最初の 接続するサイトのプレフィックスは以下でしょう: 3FFE:0180:0001/48 6bone _|||| |||| ||||___site |||| b/b site____|||| || transit_______|| Note 1: the two sites numbered 0x001 in the above examples are really two different sites as their pNLA1 authority above them is different (i.e., in the first case no transit exists thus the site is directly connected to the pTLA backbone ISP, and in the second case the site is directly connected to intermediate transit ISP 0x80). 注1:上記例の0x001の2つのサイトはpNLA1が違うので異なるサイト です(すなわち、最初の場合サイトは直接バックボーンISPであるpTLAと接 続し、2番目の場合はサイトは直接中間ISPの0x80と接続しています)。 Note 2: there would be nothing to prevent an pNLA1 transit site from further allocating pNLA's below, but that becomes the policy of the pTLA and pNLA's above them to work out. 注2:pNLA1がさらに下にpNLAを割り当てるのを禁止する理由はあにで しょう、しかしこれはpTLAとpNLAが運用する際のポリシーの問題です。 Note 3: The 6bone registry, which is a RIPE-style database for documenting IPv6 sites connected to the 6bone, has an "inet6num" object to allow documentation of all IPv6 addresses allocated. 注3:6boneに接続したIPv6サイトを文書化するRIPEスタイルデー タベースである6bone登記所は、すべての割り当てられたIPv6アド レスの文書化するために「inet6num」オブジェクトを持っています。 3. Security Considerations 3. セキュリティの考慮 IPv6 addressing documents do not have any direct impact on Internet infrastructure security. IPv6アドレス文書がインターネット基礎構造セキュリティに直接の影響 を持っていません。 References 参考文献 [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. [HARDEN] Rockell, R. and R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6BONE-TLA] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 2471, December 1998. Author's Address 著者のアドレス Bob Fink, ESnet Lawrence Berkeley National Lab MS 50A-3111 1 Cyclotron Road Berkeley, CA 94720 USA Phone: +1 510 486 5692 Fax: +1 510 486 4790 EMail: fink@es.net Full Copyright Statement 著作権表示全文 Copyright (C) The Internet Society (2000). All Rights Reserved. 著作権(C)インターネット学会(2000)。すべての権利は保留される。 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、 この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装 を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出 版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ ンターネット標準を開発する目的で必要な場合以外は、インターネット学会 や他のインターネット組織は著作権表示や参照を削除されるような変更がで きません、インターネット標準を開発する場合はインターネット標準化プロ セスで定義された著作権の手順に従われます。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 上に与えられた限定された許可は永久で、インターネット学会やその後継者 や譲渡者によって無効にされません。 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. この文書とここに含む情報は無保証で供給され、そしてインターネット学会 とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情 報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で ある事の保障を含め、すべての保証を拒否します。 Acknowledgement 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. RFCエディタ機能のための資金供給が現在インターネット学会によって 供給されます。