[要約] RFC 2921は、6BONE pTLAおよびpNLAフォーマットに関する規格です。この規格の目的は、IPv6ネットワークアドレスの割り当てと管理を効率化することです。
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.
Copyright（c）The Internet Society（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がRFC 2471に割り当てられた3FFE ::/16 IPv6アドレスプレフィックスを使用する方法を定義します。「IPv6テストアドレス割り当て」、[6bone-TLA]、擬似トップレベルの集約識別子（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................................................. 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が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プレフィックスに関連する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形式を作成する目的は、実際のTLAおよびNLA形式のプロトタイプを提供することです。これを経済的に行うために、最小限の生産IPv6アドレススペースのみを使用して、単一のTLA、3ffe ::/16を使用して、6boneでテストするためにIANA（インターネット割り当てされた番号当局）によって予約されました。したがって、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の集約可能なグローバルユニキャストアドレスの48ビットの長さが外部ルーティングプレフィックス（TLAおよびNLA識別子を含む）を考えると、TLA IDを拡張してPTLAを含み、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年初頭、6boneのPTLA形式を変更して、テストベッドネットワークのより大きな拡張を可能にすることが決定され、元の256 PTLA-Sを超えることができました。したがって、現在、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形式は、256 PTLA-S、つまりIPv6トランジットトラフィックを運ぶバックボーンネットワークに対応することを目的としていました。
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は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 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,
1. 現在割り当てられている8ビットPTLA-Sを使用してスペースが必要になるまで、範囲値チェックに依存して新しいPTLA形式を示すために、
2. to use a modulo 4-bit sized pTLA ID to make reverse path entry into the DNS easier,
2. Modulo 4ビットサイズのPTLA IDを使用して、DNSへの逆パスエントリを簡単にするには、
3. given 2. above, to keep the pTLA ID size as small as possible to not restrict pNLA ID size.
3. 2.上記の場合、PTLA IDサイズをできるだけ小さくして、PNLA IDサイズを制限しないようにします。
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のアグゲーションの最上位レベル（バックボーン）を定義する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：nnn0 ::/28です。ここで、NNNはPTLA割り当てです。ただし、既存の8ビットPTLAが現在に使用されているため、NNN値は今のところ0x800から始まるため、この新しい形式では2048 PTLAのみが生成されます。
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.
次の例では、最大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）は、提供される各エンドユーザーサイトにユニークサイトIDを割り当てます。
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：上記の例で0x001の番号が付けられた2つのサイトは、上記のPNLA1の権限が異なるため、2つの異なるサイトです（つまり、最初のケースでは輸送が存在しないため、サイトはPTLAバックボーンISPに直接接続されています。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サイトをドキュメントするための熟したスタイルのデータベースである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。and S. Deering、「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.、O'Dell、M。、およびS. Deering、「IPv6 Agregatable Global Unicastアドレス形式」、RFC 2374、1998年7月。
[HARDEN] Rockell, R. and R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[Harden] Rockell、R。およびR. Fink、「6bone Backbone Routing Guidelines」、RFC 2772、2000年2月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Fink、R。、およびJ. Postel、「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
ボブ・フィンク、エスネット・ローレンス・バークレー国立研究所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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。