Network Working Group B. Fink
Request for Comments: 2921 ESnet
Category: Informational September 2000
6BONE pTLA and pNLA Formats (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.
著作権（C）インターネット協会（2000）。全著作権所有。
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の擬似トップレベル集約識別子（pTLAの）と擬似を作成するには、「IPv6のテストアドレス割り当て」、[6boneの-TLA] RFC 2471に割り当てられた3FFE :: / 16のIPv6アドレスのプレフィックスを、どのように使用するかを定義して次へ - レベル集約識別子（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................................................. 1
2. 6BONE pTLA/pNLA Format....................................... 2
3. Security Considerations...................................... 6
References....................................................... 6
Author's Address................................................. 6
Full Copyright Statement......................................... 7
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の擬似トップレベル集約識別子（pTLA）と擬似次レベル集約識別子（pNLA）を作成するために、RFC 2471に割り当てられ3FFE :: / 16のIPv6アドレスプレフィックス、[6boneの-TLA]を使用する方法を定義します。
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の接頭辞に関連するIPv6アドレスのためのガイド仕様、および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アドレス空間の最低限を使用して、経済的にこれを行うには、単一TLA、3FFE :: / 16は、6boneの上のテストのためにIANA（Internet Assigned Numbers Authority）によって予約されました。したがって、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.
IPv6の集約可能グローバルユニキャストアドレス外部ルーティングプレフィックス（つまり、TLAとNLA識別子が含まれている）の48ビットの長さを考えると、pTLAを含むようにTLA IDを拡張し、pNLAになるためにNLA IDを短縮するのに十分な余地があります。この文書では、これを指定します。
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-S以上を収容し、テストベッドネットワークの大きな拡大を可能にするための6boneのpTLAフォーマットを変更することを決めました。したがって、2つの6bone pTLAとpNLAフォーマットが存在することになります。この文書では、これを指定します。
The original pTLA and pNLA format was intended to accommodate 256 pTLA-s, i.e., backbone networks carrying IPv6 transit traffic.
オリジナルpTLAとpNLAフォーマット、すなわち、バックボーンネットワークは、IPv6トランジットトラフィックを運ぶ、256 pTLA-Sを収容するように意図されていました。
The original TLA and NLA ID-s as specified in [AGGR] are as follows:
次のように[AGGR]で指定されるように、元のTLAとNLA ID-Sは、次のとおりです。
| 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は、プレフィックス表記形式で3ビットフォーマットプレフィックスで見6boneのに割り当てられた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 ID空間の最初の8ビットは、6boneのための集約（バックボーン）の最上位レベルを定義pTLAとして割り当てられています。これは、256個の6boneバックボーンネットワークを提供する、またはpTLA-S、および必要に応じて割り当てる各pTLAため24ビットpNLA IDを残します。
| 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.
接頭表記でpTLAを形成3FFEある：nn00 :: / 24、nnはpTLA割り当てです。
The remaining NLA ID space can be used by each pTLA for their downward aggregated delegation:
残りNLA ID空間は、その下方に集約委任に対して各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年代を必要としています
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のは、移行のための便利なテストベッドになることが明らかになった後は、仕様と実装のためのテストベッドとしての初期の役割に加えて、6boneのコミュニティはpTLA IDのサイズを拡大することを決めました。
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,
スペースが必要とされるまで、このように新しいpTLAフォーマットを示すために、レンジ値のチェックに依存する、現在使用中の割り当てられた8ビットのpTLA-Sを残す1
2. to use a modulo 4-bit sized pTLA ID to make reverse path entry into the DNS easier,
簡単DNSに逆経路エントリを作成するモジュロ4ビットサイズpTLA IDを使用する2.
3. given 2. above, to keep the pTLA ID size as small as possible to not restrict pNLA ID size.
3. pNLA IDのサイズを制限しないようにできるだけ小さいpTLA IDのサイズを維持する上記2に、与えられました。
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 ID空間の最初の12ビットは、6boneのためaggegation（バックボーン）の最上位レベルを定義pTLAとして割り当てられています。これは最終的に4096個の6boneバックボーンネットワークを提供する、またはpTLA-S、および必要に応じて割り当てる各pTLA 20ビットpNLA IDを残すであろう。
| 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.
接頭表記でpTLAを形成3FFEある：nnnはpTLA割り当てであるnnn0 :: / 28、。既存の8ビットpTLAとしての存在のために使用中に放置されているただし、NNN値は、従って、この新しいフォーマットでのみ2048 pTLAのを得、今のところは0x800から始まります。
The remaining NLA ID space can be used by each pTLA for their downward aggregated delegation:
残りNLA ID空間は、その下方に集約委任に対して各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年代を必要としています
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.
次の例は、（以下pNLA1と呼ばれる）、最大255の中間トランジットISPのために用意されています。ゼロの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さん）が務めたユニークサイトIDのeachendためのユーザサイトを割り当てます。
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（0x00からのこのようpNLA1）とは0x0001の（右端の番号で開始で）シーケンシャルサイトIDの一例として、第一のサイトのルーティングプレフィックスが見えます好む：
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のNLA1と（左端から番号付け）その下の中間中継ISP、およびシーケンシャルサイトは0x0001のID、接続された第一のサイトのルーティングプレフィックスを仮定すると、この使用の別の例は、希望のように見える：
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：その上彼らのpNLA1機関が（すなわち、トランジットはサイトに直接pTLAバックボーンISPに接続されているので、存在しない最初のケースでは、とで異なっているよう上記の例では0x001を、番号2つのサイトは実際には2つの異なるサイトですサイトが直接中間トランジットISPには0x80に接続された第2のケース）。
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.
さらに以下pNLA年代を割り当てるからpNLA1トランジットサイトを阻止するものは何もないので、それは彼らが出て仕事をする上でpTLAとpNLA年代のポリシー次のようになります注2。
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」を目的としています。
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.
[ADDRARCH] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[AGGR] HindenとR.、オデル、M.とS.デアリング、 "IPv6の集約可能グローバルユニキャストアドレス形式"、RFC 2374、1998年7月。
[HARDEN] Rockell, R. and R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[HARDEN]ロッケル、R.とR.フィンク、 "6boneのバックボーンルーティングガイドライン"、RFC 2772、2000年2月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[6BONE-TLA] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 2471, December 1998.
[6boneの-TLA] HindenとR.、フィンク、R.とJ.ポステル、 "IPv6のテストアドレス割り当て"、RFC 2471、1998年12月。
Author's Address
著者のアドレス
Bob Fink, ESnet Lawrence Berkeley National Lab MS 50A-3111 1 Cyclotron Road Berkeley, CA 94720 USA
ボブ・フィンク、ESnetローレンス・バークレー国立研究所MS 50A-3111 1サイクロトロン道路バークレー、CA 94720 USA
Phone: +1 510 486 5692 Fax: +1 510 486 4790 EMail: fink@es.net
電話：+1 510 486 5692ファックス：+1 510 486 4790 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。