RFC1888 日本語訳
1888 OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J.Houldsworth, A. Lloyd. August 1996. (Format: TXT=36469 bytes) (Obsoleted by RFC4048) (Updated by RFC4548) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Bound
Request for Comments: 1888 Digital Equipment Corporation
Category: Experimental B. Carpenter
CERN
D. Harrington
Digital Equipment Corporation
J. Houldsworth
ICL Network Systems
A. Lloyd
Datacraft Technologies
August 1996
ネットワークワーキンググループJ.はコメントを求める要求を縛りました: 1888年のDECカテゴリ: 実験的なB.のネットワーク・システムA.ロイドDatacraft技術大工CERN D.ハリントンディジタルイクイップメント社J.Houldsworth ICL1996年8月
OSI NSAPs and IPv6
OSI NSAPsとIPv6
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required.
このドキュメントは、OSI NSAPアドレシングプランと、だれが展開したがっているか、そして、IPv6への変遷を計画しているか、または配布したネットワーク作成者が彼らの需要を満たす固有のIPv6アドレシング計画を再設計するべきであることを勧めます。 しかしながら、また、それはIPv6ネットワークにおける、OSI NSAPアドレシングのサポートのために1セットのメカニズムを定義します。 これらのメカニズムはそのようなサポートが必要であるなら使用しなければならないものです。 また、これが必要であるなら、このドキュメントはOSIアドレス形式の中でIPv6アドレスに関するマッピングを定義します。
Table of Contents
目次
1. General recommendation on NSAP addressing plans..............2
2. Summary of defined mechanisms................................4
3. Restricted NSAPA in a 16-byte IPv6 address for ICD and DCC...4
3.1 Routing restricted NSAPAs...................................5
4. Truncated NSAPA used as an IPv6 address......................6
4.1 Routing truncated NSAPAs....................................8
5. Carriage of full NSAPAs in IPv6 destination option...........9
6. IPv6 addresses inside an NSAPA..............................10
7. Security Considerations.....................................11
Acknowledgements...............................................11
References.....................................................12
Annex A: Summary of NSAP Allocations...........................13
Annex B: Additional Rationale..................................14
Authors' Addresses.............................................16
1. NSAPアドレシングにおける一般推薦状は計画されています…2 2. 定義されたメカニズムの概要…4 3. ICDとDCCのための16バイトのIPv6アドレスでNSAPAを制限します…4 3.1 ルート設定はNSAPAsを制限しました…5 4. IPv6アドレスとして使用されるNSAPAに先端を切らせます…6 4.1 ルート設定はNSAPAsに先端を切らせました…8 5. IPv6目的地オプションにおける完全なNSAPAsのキャリッジ…9 6. NSAPAの中のIPv6アドレス…10 7. セキュリティ問題…11の承認…11の参照箇所…12 別館A: NSAP配分の概要…13 別館B: 追加原理…14人の作者のアドレス…16
Bound, et. al. Experimental [Page 1] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[1ページ]RFC1888OSI NSAPsとIPv6 August 1996
1. General recommendation on NSAP addressing plans
1. プランを扱うNSAPにおける一般推薦
This recommendation is addressed to network implementors who have already planned or deployed an OSI NSAP addressing plan for the usage of OSI CLNP [IS8473] according to the OSI network layer addressing plan [IS8348] using ES-IS and IS-IS routing [IS9542, IS10589]. It recommends how they should adapt their addressing plan for use with IPv6 [RFC1883].
そして、この推薦が既に計画したネットワーク作成者に扱われるか、またはプラン[IS8348]使用を扱うOSIネットワーク層に従ったOSI CLNP[IS8473]の使用法のためのOSI NSAPアドレシングプランであると配布される、ある、ES-、ルーティング[IS9542、IS10589]。 それは彼らがどうIPv6[RFC1883]との使用のための自分達のアドレシングプランを適合させるべきであるかを推薦します。
The majority of known CLNP addressing plans use either the Digital Country Code (DCC) or the International Code Designator (ICD) formats defined in [IS8348]. A particular example of this is the US Government OSI Profile Version 2 (GOSIP) addressing plan [RFC1629]. The basic NSAP addressing scheme and current implementations are summarised in Annex A.
プランを扱う知られているCLNPの大部分が形式が[IS8348]で定義したDigital Country Code(DCC)か国際旗信号Designator(ICD)のどちらかを使用します。 この特定の例はプラン[RFC1629]を扱う米国政府OSI Profileバージョン2です(GOSIP)。 Annex Aで基本的なNSAPアドレシング体系と現在の実装について略言します。
[IS8348] specifies a maximum NSAPA (NSAP address) size of 20 bytes and some network implementors have designed address allocation schemes which make use of this 20 byte address space.
ネットワーク作成者の中には[IS8348]が20バイトの最大のNSAPA(NSAPアドレス)サイズを指定して、この20バイトのアドレス空間を利用するアドレス配分体系を設計した人もいました。
Other NSAP addressing plans have been specified by the ITU-T for public data services, such as X.25 and ISDN, and these can also have addresses up to 20 bytes in length.
プランを扱う他のNSAPがITU-Tによって公衆データサービスに指定されました、X.25やISDNのように、そして、また、これらはアドレスを長さ20バイトまで持つことができます。
The general recommendation is that implementors SHOULD design native IPv6 addressing plans according to [RFC1884], but doing so as a natural re-mapping of their CLNP addressing plans. While it is impossible to give a general recipe for this, CLNP addresses in DCC or ICD format can normally be split into two parts: the high order part relating to the network service provider and the low order part relating to the user network topology and host computers.
一般的な推薦は作成者SHOULDが[RFC1884]に従ってプランを扱いますが、それらのCLNPアドレシングの自然な再マッピングが計画されているのでそうするネイティブのIPv6を設計するということです。 これのための一般的なレシピを与えるのが不可能である間、通常、DCCのCLNPアドレスかICD形式を2つの部品に分けることができます: ネットワークサービスプロバイダーに関連する高位部分と安値はユーザネットワーク形態とホストコンピュータに関連する部分を注文します。
For example, in some applications of US GOSIP the high order part is the AFI, ICD, DFI, AA and RD fields, together occupying 9 bytes. The low order part is the Area and ID fields, together occupying 8 bytes. (The selector byte and the two reserved bytes are not part of the addressing plan.) Thus, in such a case, the high-order part could be replaced by the provider part of an IPv6 provider-based addressing plan. An 8-byte prefix is recommended for this case and [RFC1884] MUST be followed in planning such a replacement. The low order part would then be mapped directly in the low-order half of the IPv6 address space, and user site address plans are unchanged. A 6-byte ID field, exactly as used in US GOSIP and other CLNP addressing plans, will be acceptable as the token for IPv6 autoconfiguration [RFC1971].
例えば、US GOSIPのいくつかのアプリケーションでは、高位部分は、一緒に9バイトを占領することでのAFIと、ICDと、DFIと、AAとRD分野です。 下位の一部は、AreaとID分野と、一緒にいることです8バイトを占領する。 (セレクタバイトと予約された2バイトはアドレシングプランの一部ではありません。) このようにして、このような場合には、高位部分をIPv6のプロバイダーベースのアドレシングプランのプロバイダー部分に取り替えることができました。 8バイトの接頭語はこのような場合お勧めです、そして、そのような交換を計画する際に[RFC1884]に続かなければなりません。 次に、下位の一部が直接IPv6アドレス空間の下位の半分で写像されるでしょう、そして、ユーザの現場アドレスプランは変わりがありません。 プランを扱いながらUS GOSIPと他のCLNPでちょうど使用される6バイトのID分野はIPv6自動構成[RFC1971]のためのトークンとして許容できるでしょう。
Analogous rules would be applied for other CLNP addressing plans similar to US GOSIP, which is used only as a well known example.
類似の規則はよく知られている例だけとして使用されるUS GOSIPと同様のプランを扱う他のCLNPのために適用されるでしょう。
Bound, et. al. Experimental [Page 2] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[2ページ]RFC1888OSI NSAPsとIPv6 August 1996
Three warnings must be carefully considered in every case:
慎重にあらゆる場合に3つの警告を考えなければなりません:
1. The ES-IS/IS-IS model employs a routing hierarchy down to the Area level, but not all end systems in an Area need to be in the same physical subnet (on the same "wire" or "link"). IS routers on different links within a given Area exchange information about the end systems they can each reach directly. In contrast, the IPv6 routing model extends down to the subnet level and all hosts in the same subnet are assumed to be on the same link. In mapping a CLNP addressing plan into IPv6 format, without changing the physical topology, it may be necessary to add an extra level of hierarchy to cope with this mismatch. In other words, the Area number cannot blindly be mapped as a subnet number, unless the physical network topology corresponds to this mapping.
1. ES存在、/、-、モデルは同じ物理的なサブネット(同じ「ワイヤ」か「リンク」の)にはあるArea必要でルーティング階層構造をすべてのエンドシステムではなく、Areaレベルまで使います。 それらがそれぞれ直接達することができるエンドシステムの与えられたArea交換情報の中の異なったリンクの上のルータはそうですか? 対照的に、IPv6ルーティングモデルはサブネットレベルまで広がっています、そして、同じサブネットにおけるすべてのホストが同じリンクの上にいると思われます。 物理的なトポロジーを変えないでCLNPアドレシングプランをIPv6形式に写像するのにおいて、このミスマッチに対処するために付加的なレベルの階層構造を加えるのが必要であるかもしれません。 言い換えれば、サブネット番号として盲目的にArea番号を写像できません、物理ネットワークトポロジーがこのマッピングに対応していない場合。
2. It is highly desirable that subnet addresses can be aggregated for wide area routing purposes, to minimise the size of routing tables. Thus network implementors should ensure that the address prefix used for all their subnets is the same, regardless of whether a particular subnet is using a pure IPv6 addressing scheme or one derived from a CLNP scheme as above.
2. 広い領域ルーティング目的のためにサブネットアドレスを集めることができるのは、経路指定テーブルのサイズを最小とならせるように非常に望ましいです。 したがって、ネットワーク作成者は、彼らのすべてのサブネットに使用されるアドレス接頭語が同じであることを保証するべきです、特定のサブネットが純粋なIPv6アドレシング体系か1つを使用するかどうか同じくらい上でCLNP体系から派生したにかかわらず。
3. Some hosts have more than one physical network interface. In the ES-IS model, an end system may have more than one NSAP address, each of which identifies the host as a whole. Such an end system with more than one physical interface may be referenced by any one of the NSAPs, and reached via any one of the physical connections. In the IPv6 model, a host may have multiple IPv6 addresses per interface, but each of its physical interfaces must have its own unique addresses. This restriction must be applied when mapping an NSAP addressing plan into an IPv6 addressing plan for such hosts.
3. 1つ以上の物理ネットワークインタフェースを持っているホストもいます。 中、ES存在、モデル、エンドシステムには、1つ以上のNSAPアドレスがあるかもしれません。それはそれぞれ全体でホストを特定します。 1つ以上の物理インターフェースがあるそのようなエンドシステムは、NSAPsのどれかによって参照をつけられて、物理接続のどれかを通して達するかもしれません。 IPv6モデルでは、ホストは複数の1インタフェースあたりのIPv6アドレスを持っているかもしれませんが、それぞれの物理インターフェースはそれ自身のユニークな住所を知っていなければなりません。 そのようなホストのためのIPv6アドレシングプランにNSAPアドレシングプランを写像するとき、この制限を適用しなければなりません。
This document does not address the issues associated with migrating the routing protocols used with CLNP (ES-IS or IS-IS) and transition of their network infrastructure.
または、このドキュメントがルーティング・プロトコルがCLNPと共に使用した移行するのに関連している問題を扱わない、(ある、ES-、)、そして、彼らのネットワークインフラの変遷。
Bound, et. al. Experimental [Page 3] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[3ページ]RFC1888OSI NSAPsとIPv6 August 1996
2. Summary of defined mechanisms
2. 定義されたメカニズムの概要
This document defines four distinct mechanisms. All of these are ELECTIVE mechanisms, i.e. they are not mandatory parts of an IPv6 implementation, but if such mechanisms are needed they MUST be implemented as defined in this document.
このドキュメントは4台の異なる機序を定義します。これらのすべてがELECTIVEメカニズムである、すなわち、それらはIPv6実装の義務的な部分にもかかわらず、そのようなメカニズムが定義されるとして必要なそれらを実装しなければならないというこのドキュメントのことであるかどうかということではありません。
1. Restricted NSAPA mapping into 16-byte IPv6 address
2. Truncated NSAPA for routing, full NSAPA in IPv6 option
3. Normal IPv6 address, full NSAPA in IPv6 option
4. IPv6 address carried as OSI address
1. 16バイトのIPv6にアドレス2を写像するNSAPAを制限しました。 ルーティングのための端が欠けているNSAPA、IPv6オプション3における完全なNSAPA。 正常なIPv6アドレス、IPv6オプション4における完全なNSAPA。 OSIアドレスとして運ばれたIPv6アドレス
To clarify the relationship between the first three mechanisms, note that:
最初の3つのメカニズムの間の関係をはっきりさせるために、以下のことに注意してください。
If the first byte of an IPv6 address is hexadecimal 0x02 (binary
00000010), then the remaining 15 bytes SHALL contain a restricted
NSAPA mapped as in Chapter 3 below. The term "restricted" is used
to indicate that this format is currently restricted to a subset
of the ICD and DCC formats.
IPv6アドレスの最初のバイトが16進0x02である(2進の00000010)なら、15バイトの残っているSHALLは以下の第3章のように写像された制限されたNSAPAを含んでいます。 「制限」という用語は、この形式が現在ICDとDCC形式の部分集合に制限されるのを示すのに使用されます。
If the first byte of an IPv6 address is hexadecimal 0x03 (binary
00000011), then the remaining 15 bytes SHALL contain a truncated
NSAPA as described in Chapter 4 below. EITHER a destination option
containing the complete NSAPA of any format, as described in
Chapter 5 below, OR an encapsulated CLNP packet, SHALL be present.
IPv6アドレスの最初のバイトが16進0x03である(2進の00000011)なら、15バイトの残っているSHALLは以下の第4章で説明されるように端が欠けているNSAPAを含んでいます。 EITHER aの目的地は以下の第5章で説明されるようにどんな形式の完全なNSAPAも含有にゆだねて、ORはカプセル化されたCLNPパケットです、SHALL。存在してください。
With any other format of IPv6 address, a destination option
containing a complete NSAPA, as defined in Chapter 5 below, MAY be
present.
IPv6アドレスのいかなる他の形式についても、以下の第5章で定義されるように完全なNSAPAを含む目的地オプションは存在しているかもしれません。
3. Restricted NSAPA in a 16-byte IPv6 address for ICD and DCC
3. ICDとDCCのための16バイトのIPv6アドレスの制限されたNSAPA
Some organizations may decide for various reasons not to follow the above general recommendation to redesign their addressing plan. They may wish to use their existing OSI NSAP addressing plan unchanged for IPv6. It should be noted that such a decision has serious implications for routing, since it means that routing between such organizations and the rest of the Internet is unlikely to be optimised. An organization using both native IPv6 addresses and NSAP addresses for IPv6 would be likely to have inefficient internal routing. Nevertheless, to cover this eventuality, the present document defines a way to map a subset of the NSAP address space into the IPv6 address space. The mapping is algorithmic and reversible within this subset of the NSAP address space.
組織の中にはそれらのアドレシングプランを再設計するという上の一般的な推薦に続かない様々な理由の有利な判決を下すものもあるかもしれません。 彼らは自分達のIPv6に、変わりのない既存のOSI NSAPアドレシングプランを使用したがっているかもしれません。 そのような決定にはルーティングのための重大な意味があることに注意されるべきです、そのような組織とインターネットの残りの間のルーティングが最適化されそうにないことを意味するので。 IPv6に固有のIPv6アドレスとNSAPアドレスの両方を使用する組織は効率の悪い内部のルーティングを持っていそうでしょう。 それにもかかわらず、この不測の事態をカバーするために、現在のドキュメントはNSAPアドレス空間の部分集合をIPv6アドレス空間に写像する方法を定義します。 マッピングは、NSAPアドレス空間のこの部分集合の中でアルゴリズムであってリバーシブルです。
Bound, et. al. Experimental [Page 4] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[4ページ]RFC1888OSI NSAPsとIPv6 August 1996
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 |0 0 0 0 0 0 1 0| AFcode| IDI (last 3 digits) |Prefix(octet 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | Prefix (octets 1 through 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | Area (octets 0 and 1) | ID (octets 0 and 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| ID (octets 2 through 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 |0 0 0 0 0 0 1 0| AFcode| IDI(3ケタを持続します)|(八重奏0)を前に置いてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | (八重奏1〜4)を前に置いてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | 領域(八重奏0と1)| ID(八重奏0と1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| ID(八重奏2〜5)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AFcode nibble is overloaded, and encoded as follows
AFcode少量が、積みすぎられて、以下の通りコード化されます。
0000-1001 Implied AFI value is 47 (ICD)
(0-9 decimal) AFcode is first BCD digit of the ICD
IDI is last three BCD digits of the ICD
47(ICD)(0-9 10進の)AFcodeがICD IDIの最初のBCDケタであるという暗示しているAFIが、評価することである0000-1001はICDの下3BCDケタです。
1010 Implied AFI value is 39 (DCC)
(hex. A) IDI is the three BCD digits of the DCC
1010年の暗示しているAFI価値は39(DCC)です。(魔法をかけます。 A) IDIはDCCの3BCDケタです。
1011-1111 Reserved, not to be used.
(hex. B-F)
使用されないように予約された1011-1111。 (魔法をかけます。 B-F)
The NSEL octet is not included. It is of no use for TCP and UDP traffic. In any case where it is needed, the mechanism described in the next chapter should be used.
NSEL八重奏は含まれていません。 TCPとUDPトラフィックに、それは無駄です。 それが必要であるどんな場合でも、次の章で説明されたメカニズムは使用されるべきです。
The longest CLNP routing prefixes known to be in active use today are 5 octets (subdivided into AA and RD fields in US GOSIP version 2). Thus the semantics of existing 20-octet NSAPAs can be fully mapped. DECnet/OSI (Registered Trade Mark) address semantics are also fully mapped.
今日、能動的使用であるのが知られている中で最も長いCLNPルーティング接頭語は5つの八重奏(US GOSIPバージョン2のAAとRD分野に細分される)です。 したがって、既存の20八重奏のNSAPAsの意味論を完全に写像できます。 また、DECnet/OSI(登録されたTradeマーク)アドレス意味論も完全に写像されています。
It is expected that hosts using restricted NSAPAs could be configured using IPv6 auto-configuration [RFC1971], and that they could use normal IPv6 neighbour discovery mechanisms [RFC1970].
IPv6自動構成[RFC1971]を使用することで制限されたNSAPAsを使用しているホストは構成できて、彼らが正常なIPv6隣人発見メカニズム[RFC1970]を使用するかもしれないと予想されます。
Restricted NSAPAs, assuming that they can be fully routed using IPv6 routing protocols, may be used in IPv6 routing headers.
IPv6ルーティング・プロトコルを使用することで彼らを完全に発送できると仮定する場合、制限されたNSAPAsはIPv6ルーティングヘッダーで使用されるかもしれません。
3.1 Routing restricted NSAPAs
3.1 ルート設定はNSAPAsを制限しました。
As mentioned in Chapter 1, there is a mismatch between the OSI or GOSIP routing model and the IPv6 routing model. Restricted NSAPAs can be routed hierarchically down to the Area level but must be flat- routed within an Area. Normal IPv6 addresses can be routed
第1章で言及されるように、OSIかGOSIPルーティングモデルとIPv6ルーティングモデルの間には、ミスマッチがあります。 制限されたNSAPAsは階層的にAreaレベルまで発送できますが、Areaの中で発送されていた状態で平坦であるに違いありません。 正常なIPv6アドレスを発送できます。
Bound, et. al. Experimental [Page 5] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[5ページ]RFC1888OSI NSAPsとIPv6 August 1996
hierarchically down to physical subnet (link) level and only have to be flat-routed on the physical subnet.
階層的で物理的なサブネット(リンク)レベルに倒して、物理的なサブネットでアパートによって発送されているために持っているだけです。
Thus, packets whose destination address is a restricted NSAPA can be routed using any normal IPv6 routing protocol only as far as the Area. If the Area contains more than one physical subnet reached by more than one router, no IPv6 routing protocol can route the packet to the correct final router. There is no solution to this problem within the existing IPv6 mechanisms. Presumably a flooding algorithm, or a suitably adapted implementation of ES-IS, could solve this problem.
したがって、Areaと同じくらい遠くにだけどんな正常なIPv6ルーティング・プロトコルも使用することで送付先アドレスが制限されたNSAPAであるパケットを発送できます。 Areaが物理的なサブネットが1つ以上のルータで達したより多くのものを含んでいるなら、どんなIPv6ルーティング・プロトコルも正しい最終的なルータにパケットを発送できません。 存在の中のこの問題へのどんな解決もそこでは、IPv6メカニズムおそらく氾濫アルゴリズムでなくて、またまたは適当に適合している実装でもない、ES存在、この問題を解決できました。
In the absence of such a routing protocol, either the Area number must be hierarchically structured to correspond to physical subnets, or each Area must be limited to one physical subnet.
そのようなルーティング・プロトコルがないとき、物理的なサブネットに相当するように階層的でArea番号を構造化しなければなりませんか、または各Areaを1つの物理的なサブネットに制限しなければなりません。
It is necessary in an IPv6 network that routes may be aggregated to minimise the size of routing tables. If a subscriber is using both normal IPv6 addresses [RFC1884] and restricted NSAPAs, these two types of address will certainly not aggregate with each other, since they differ from the second most significant bit onwards. This means that there may be a significant operational penalty for using both types of address with currently known routing technology.
IPv6ネットワークでは、ルートが経路指定テーブルのサイズを最小とならせるように集められるのが必要です。 加入者が正常なIPv6アドレス[RFC1884]と制限されたNSAPAsの両方を使用していると、確かに、これらの2つのタイプのアドレスは互いと共に集められないでしょう、彼らが前方へ2番目の最上位ビットと異なっているので。 これは、現在知られているルーティング技術がある両方のタイプのアドレスを使用するための重要な操作上の刑罰があるかもしれないことを意味します。
4. Truncated NSAPA used as an IPv6 address
4. IPv6アドレスとして使用される端が欠けているNSAPA
An NSAP address contains routing information (e.g. Routing Domain and area/subnet identifiers) in the form of the Area Address (as defined in [IS10589]). The format and length of this routing information are typically compatible with a 16 byte IPv6 address, and may be represented as such using the following format:
NSAPアドレスはArea Addressの形にルーティング情報(例えば、ルート設定Domainと領域/サブネット識別子)を含んでいます([IS10589]で定義されるように)。 このルーティング情報の書式と長さは、16バイトのIPv6アドレスと通常互換性があって、そういうものとして以下の形式を使用することで表されるかもしれません:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 |0 0 0 0 0 0 1 1| High order octets of full NSAP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | NSAP address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | NSAP address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| NSAP address truncated ... zero pads if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 |0 0 0 0 0 0 1 1| 完全なNSAPアドレスの高位八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | NSAPアドレスは続きました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | NSAPアドレスは続きました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| 先端を切られたNSAPアドレス… 必要なら、パッドのゼロを合わせてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If appropriate, when used as a destination IPv6 address, the truncated NSAPA may be interpreted as an IPv6 anycast address. An anycast address may be used to identify either an IPv6 node, or potentially even an OSI End System or Intermediate System. For
適切であるなら、送付先IPv6アドレスとして使用されると、端が欠けているNSAPAはIPv6 anycastアドレスとして解釈されるかもしれません。 anycastアドレスは、潜在的にIPv6ノードかOSI End SystemかIntermediate Systemのどちらかさえ特定するのに使用されるかもしれません。 for
Bound, et. al. Experimental [Page 6] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[6ページ]RFC1888OSI NSAPsとIPv6 August 1996
example, it might be configured to identify the endpoints of a CLNP tunnel, or it might identify a particular OSI capable system in a particular subnet.
例、CLNPトンネルの終点を特定するのが構成されているかもしれないか、またはそれは特定のサブネットで特定のOSIできるシステムを特定するかもしれません。
If a truncated NSAPA is used as a source address, it must be interpreted as a unicast address and must therefore be uniquely assigned within the IPv6 address space.
端が欠けているNSAPAがソースアドレスとして使用されるなら、それをユニキャストアドレスとして解釈しなければならなくて、したがって、IPv6アドレス空間の中で唯一割り当てなければなりません。
If a truncated NSAPA is used as either the source or destination IPv6 address (or both), EITHER an NSAPA destination option OR an encapsulated CLNP packet MUST be present. It is the responsibility of the destination system to take the appropriate action for each IPv6 packet received (e.g. forward, decapsulate, discard) and, if necessary, return to the originating host an appropriate ICMP error message.
端が欠けているNSAPAが使用されているなら、ソースか送付先IPv6アドレス(ともに)、NSAPAの目的地がORにゆだねるEITHERのどちらかとして、カプセル化されたCLNPパケットは存在していなければなりません。 IPv6パケットが受けた(decapsulate、例えば、前方に、捨ててください)それぞれに適切な行動を取って、必要なら、適切なICMPエラーメッセージを送信元ホストに返すのは、目的地システムの責任です。
If the truncated NSAPA is used to identify a router, and an NSAPA destination option is present, then it is the responsibility of that router to forward the complete IPv6 packet to the appropriate host based upon the Destination NSAP field in the NSAPA option. This forwarding process may be based upon static routing information (i.e. a manual mapping of NSAPs to IPv6 unicast addresses), or it may be gathered in an automated fashion analogous to the ES-IS mechanism, perhaps using extensions to the Neighbor Discovery protocol [RFC1970]. The details of such a mechanism are beyond the scope of this document.
端が欠けているNSAPAがルータを特定するのに使用されて、NSAPA目的地オプションが存在しているなら、NSAPAオプションにおけるDestination NSAP分野に基づく適切なホストに完全なIPv6パケットを送るのは、そのルータの責任です。 この推進プロセスが静的ルーティング情報(すなわち、IPv6ユニキャストアドレスへのNSAPsの手動のマッピング)に基づくかもしれないか、またはそれが自動化されたファッションで類似していた状態で集められるかもしれない、ES存在、メカニズム、恐らく、Neighborディスカバリープロトコル[RFC1970]に拡張子を使用します。 そのようなメカニズムの細部はこのドキュメントの範囲を超えています。
This document does not restrict the formats of NSAP address that may be used in truncated NSAPAs, but it is apparent that binary ICD or DCC formats will be much easier to accomodate in an IPv6 routing infrastructure than the other formats defined in [IS8348].
このドキュメントは端が欠けているNSAPAsで使用されるかもしれないNSAPアドレスの形式を制限しませんが、2進のICDかDCC形式が[IS8348]で定義された他の書式よりIPv6ルーティングインフラストラクチャでaccomodateにはるかに簡単になるのは、明らかです。
It is not expected that IPv6 autoconfiguration [RFC1971] and discovery [RFC1970] will work unchanged for truncated NSAPAs.
IPv6自動構成[RFC1971]と発見[RFC1970]が端が欠けているNSAPAsに変わりがない状態で働かないと予想されます。
Truncated NSAPAs are not meaningful within IPv6 routing headers, and there is no way to include full NSAPAs in routing headers.
端が欠けているNSAPAsはIPv6ルーティングヘッダーの中に重要ではありません、そして、ルーティングヘッダーに完全なNSAPAsを含む方法が全くありません。
If a packet whose source address is a truncated NSAPA causes an ICMP message to be returned for whatever reason, this ICMP message may be discarded rather than being returned to the true source of the packet.
ソースアドレスが端が欠けているNSAPAであるパケットがいかなる理由でも返されるべきICMPメッセージを引き起こすなら、このICMPメッセージはパケットの正しい源に返すよりむしろ捨てられるかもしれません。
Bound, et. al. Experimental [Page 7] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[7ページ]RFC1888OSI NSAPsとIPv6 August 1996
4.1 Routing truncated NSAPAs
4.1 ルート設定はNSAPAsに先端を切らせました。
This is a grey area. If the truncated NSAPA retains a hierarchical structure, it can be routed like a restricted NSAPA, subject to the same problem concerning the mismatch between Areas and subnets. If possible, in the case of a GOSIP-like NSAPA, it should be truncated immediately after the Area number. In this case the routing considerations will be similar to those for restricted NSAPAs, except that final delivery of the packet will depend on the last IPv6 router being able to interpret the NSAPA destination option (or an encapsulated CLNP packet).
これは灰色の領域です。 端が欠けているNSAPAが階層構造を保有するなら、制限されたNSAPAのようにミスマッチに関する同じ問題を条件としてAreasとサブネットの間にそれを発送できます。 できれば、GOSIPのようなNSAPAの場合では、それはArea番号直後先端を切られるべきです。 この場合、ルーティング問題は制限されたNSAPAsにそれらと同様になるでしょう、パケットの最終的な配送がNSAPA目的地オプション(または、カプセル化されたCLNPパケット)を解釈できる最後のIPv6ルータによるのを除いて。
In the general case, nothing can be said since the NSAPA could have almost any format and might have very little hierarchical content after truncation. There may be many cases in which truncated NSAPAs cannot be routed across large regions of the IPv6 network.
一般的な場合では、何も、NSAPAがほとんどどんな形式も持つことができたので言うことができて、トランケーションの後に非常に少ない階層的な内容を持っていないかもしれません。 IPv6ネットワークの広大な地域の向こう側に端が欠けているNSAPAsを発送できない多くの場合があるかもしれません。
The situation for route aggregation is similar to that described in Section 3.1 as long as the truncated NSAPAs have ICD or DCC format. However, if arbitrary NSAPAs are used nothing can be predicted about route aggregation and we must assume that it will be poor.
ルート集合のための状況は端が欠けているNSAPAsにICDかDCC形式がある限り、セクション3.1で説明されたそれと同様です。 しかしながら、任意のNSAPAsが使用されているなら、ルート集合に関して何も予測できません、そして、私たちはそれが貧しくなると思わなければなりません。
Bound, et. al. Experimental [Page 8] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[8ページ]RFC1888OSI NSAPsとIPv6 August 1996
5. Carriage of full NSAPAs in IPv6 destination option
5. IPv6目的地オプションにおける完全なNSAPAsのキャリッジ
In the case of a truncated NSAPA used as an IPv6 address other than for a CLNP tunnel, the full NSAPA must be carried in a destination option. Any format defined in [IS8348] is allowed.
CLNPトンネル以外のIPv6アドレスとして使用される端が欠けているNSAPAの場合では、目的地オプションで完全なNSAPAを運ばなければなりません。 [IS8348]で定義されたどんな書式も許容されています。
The NSAPA destination option is illustrated below. It has no alignment requirement.
NSAPA目的地オプションは以下で例証されます。 それには、整列要求が全くありません。
The option type code is 11-0-00011 = 195 decimal.
オプションタイプコードは11-0-00011 = 195 10進です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0 0 1 1| Opt Data Len |Source NSAP Len| Dest. NSAP Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source NSAP +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination NSAP +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0 0 1 1| Dataレンを選んでください。|ソースNSAPレン| Dest。 NSAPレン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + ソースNSAP+| | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 目的地NSAP+| | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length fields are each one octet long and are expressed in octets. The destination node should check the consistency of the length fields (Option Data Length = Source NSAP Length + Dest. NSAP Length +2). In case of inconsistency the destination node shall discard the packet and send an ICMP Parameter Problem, Code 2, message to the packet's source address, pointing to the Option Data Length field.
長さの分野は、長い間のそれぞれ八重奏であり、八重奏で表現されます。 目的地ノードは長さの分野の一貫性をチェックするはずです。(オプションデータの長さはソースNSAP長さ+Destと等しいです。 NSAPの長さ+2). 矛盾の場合には、目的地ノードは、パケットを捨てて、ICMP Parameter Problemを送るものとします、Code2、パケットのソースアドレスへのメッセージ、Option Data Length野原を示して。
The boundary between the source NSAP and the destination NSAP is simply aligned on an octet boundary. With standard 20 octet NSAPs the total option length is 44 bytes and the Option Data Length is 42.
ソースNSAPと目的地NSAPの間の境界は八重奏境界で単に並べられます。 標準の20八重奏NSAPsと共に、総オプションの長さは44バイトです、そして、Option Data Lengthは42歳です。
Bound, et. al. Experimental [Page 9] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[9ページ]RFC1888OSI NSAPsとIPv6 August 1996
The NSAP encodings follow [IS8348] exactly.
NSAP encodingsはまさに[IS8348]に続きます。
If this option is used, both end systems concerned SHOULD use NSAP addresses. In the exceptional case that only one of the end systems uses NSAP addresses, the NSAP Length field of the other SHALL be set to zero in the NSAP destination option.
このオプションが使用されているなら、両方のエンドシステムはNSAPが扱うSHOULD使用に関係がありました。 NSAPが扱う終わりのシステム用途の1つだけ、もう片方のSHALLのNSAP Length分野がある例外的な場合では、NSAP目的地オプションでゼロにセットしてください。
This destination option is used in two cases. Firstly, an IPv6 source node using normal IPv6 addresses (unicast address or anycast address) MAY supply an NSAP destination option header for interpretation by the IPv6 destination node. Secondly, an IPv6 node MAY use a truncated NSAP address in place of a normal IPv6 address.
この目的地オプションは2つの場合に使用されます。 まず第一に、正常なIPv6アドレス(ユニキャストアドレスかanycastアドレス)を使用するIPv6ソースノードはNSAP目的地オプションヘッダーのIPv6目的地ノードを解釈に供給するかもしれません。 第二に、IPv6ノードは正常なIPv6アドレスに代わって端が欠けているNSAPアドレスを使用するかもしれません。
IPv6 nodes are not required to implement this option, except for nodes using truncated NSAPAs other than for CLNP tunnels.
IPv6ノードは以外のこのオプションを実装する必要はありません。
6. IPv6 addresses inside an NSAPA
6. NSAPAの中のIPv6アドレス
If it is required, for whatever reason, to embed an IPv6 address inside a 20-octet NSAP address, then the following format MUST be used.
それがいかなる理由でも20八重奏のNSAPアドレスでIPv6アドレスを埋め込むのに必要であるなら、以下の形式を使用しなければなりません。
A specific possible use of this embedding is to express an IP address within the ATM Forum address format. Another possible use would be to allow CLNP packets that encapsulate IPv6 packets to be routed in a CLNP network using the IPv6 address architecture. Several leading bytes of the IPv6 address could be used as a CLNP routing prefix.
この埋め込みの特定の活用可能性はATM Forumアドレス形式の中にIPアドレスを表すことです。 別の活用可能性はパケットをIPv6にカプセルに入れるCLNPパケットがCLNPネットワークで発送されるのをIPv6アドレス体系を使用することで許容するだろうことです。 CLNPルーティング接頭語としてIPv6アドレスの主な数バイトを使用できました。
The first three octets are an IDP in binary format, using the AFI code in the process of being allocated to the IANA. The AFI value provisionally allocated is 35, but this requires a formal modification to [IS8348]. The encoding format is as for AFI value 47 [IS8348]. The third octet of the IDP is known as the ICP (Internet Code Point) and its value must be zero. All other values are reserved for allocation by the IANA.
最初の3つの八重奏がバイナリフォーマットのIDPです、IANAに割り当てることの途中にAFIコードを使用して。 臨時に割り当てられたAFI値は35ですが、これは[IS8348]への正式な変更を必要とします。 コード化形式はAFI値47[IS8348]に似ています。 IDPの3番目の八重奏はICP(インターネットCode Point)として知られています、そして、値はゼロでなければなりません。 他のすべての値が配分のためにIANAによって予約されます。
Thus an AFI value of 35 with an ICP value of zero means that "this NSAPA embeds a 16 byte IPv6 address".
したがって、ゼロのICP値がある35のAFI値は、「このNSAPAは16バイトのIPv6アドレスを埋め込みます。」と意味します。
The last octet is a selector. To maintain compatibility with both NSAP format and IPv6 addressing, this octet must be present, but it has no significance for IPv6. Its default value is zero.
最後の八重奏はセレクタです。 NSAP形式とIPv6の両方との互換性がアドレシング、この八重奏であることを支持するのは存在していなければなりませんが、それには、IPv6のための意味が全くありません。 デフォルト値はゼロです。
Bound, et. al. Experimental [Page 10] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[10ページ]RFC1888OSI NSAPsとIPv6 August 1996
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 | AFI = 35 | ICP = 0000 | IPv6 (byte 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv6 (bytes 1-4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | IPv6 (bytes 5-8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| IPv6 (bytes 9-12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| IPv6 (bytes 13-15) |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 | AFI=35| ICP=0000| IPv6(バイト0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | IPv6(バイト1-4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | IPv6(バイト5-8)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| IPv6(バイト9-12)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16-19| IPv6(バイト13-15)|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Theoretically this format would allow recursive address embedding.
理論的に、この形式は再帰的なアドレスの埋め込みを許すでしょう。
However, this is considered dangerous since it might lead to routing table anomalies or to loops (compare [RFC1326]). Thus embedded IPv6 address MUST NOT have the prefixes 0x02 or 0x03, and an NSAPA with the IANA AFI code MUST NOT be embedded in an IPv6 header.
しかしながら、これは、経路指定テーブル例外、または、輪に導くかもしれないので([RFC1326]を比較してください)、危険であると考えられます。 このようにして埋め込まれたIPv6アドレスには、接頭語0×02か0x03があってはいけません、そして、IANA AFIコードがあるNSAPAがIPv6ヘッダーに埋め込まれてはいけません。
An NSAPA with the IANA AFI code and ICP set to zero is converted to an IPv6 address by stripping off the first three and the twentieth octets. All other formats of NSAPA are handled according to the previous Chapters of this document.
コードとICPがゼロに設定するIANA AFIとNSAPAは、最初の3と20番目の八重奏を全部はぎ取ることによって、IPv6アドレスに変換されます。 このドキュメントの前の章に従って、NSAPAの他のすべての形式が扱われます。
7. Security Considerations
7. セキュリティ問題
Security issues are not specifically addressed in this document, but it is compatible with the IPv6 security mechanisms [RFC1825].
安全保障問題は明確に本書では記述されませんが、それはIPv6セキュリティー対策[RFC1825]と互換性があります。
Acknowledgements
承認
The authors are pleased to acknowledge the suggestions and comments of Ross Callon, Richard Collella, Steve Deering, Dirk Fieldhouse, Joel Halpern, Denise Heagerty, Cyndi Jung, Yakov Rekhter, and members of the former TUBA and current IPNG working groups of the IETF. The support of Scott Bradner and Allison Mankin of the IESG was essential.
作者は、提案、ロスCallon、リチャードCollella、スティーブ・デアリングDirk Fieldhouse、ジョエル・アルペルン、デニーズHeagerty、シンディ・ユング、ヤコフRekhterのコメント、元TUBAのメンバー、およびIETFの現在のIPNGワーキンググループを承諾して、嬉しいです。 IESGのスコット・ブラドナーとアリソン・マンキンのサポートは不可欠でした。
Herb Bertine, Alan Chambers, Dave Marlow, and Jack Wheeler were all active in arranging the AFI allocation by ISO/IEC JTC1/SC6.
ハーブBertine、アラン・チェンバース、デーヴ・マーロウ、およびジャック・ウィーラーはISO/IEC JTC1/SC6によるAFI配分をアレンジするのにおいてすべて活発でした。
Bound, et. al. Experimental [Page 11] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[11ページ]RFC1888OSI NSAPsとIPv6 August 1996
References
参照
[IS8473] Data communications protocol for providing the connectionless-mode network service, ISO/IEC 8473, 1988.
[IS8473]データ通信は、コネクションレスなモードネットワーク・サービス、ISO/IEC8473、1988を提供するために議定書を作ります。
[IS8348] Annex A, Network Layer Addressing, and Annex B, Rationale for the material in Annex A, of ISO/IEC 8348, 1993 (identical to CCITT Recommendation X.213, 1992).
[IS8348] ISO/IEC8348、1993年のAnnex A(CCITT Recommendation X.213、1992と同じ)の材料のための別館A、Network Layer AddressingとAnnex B、Rationale。
[IS10589] Intermediate system to intermediate system intra-domain- routeing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473), ISO 10589, 1992.
中間システムイントラドメインrouteing通常の情報交換への[IS10589]中間システムは使用のためにコネクションレスなモードNetwork Serviceを提供するためのプロトコルに関連して議定書を作ります。(ISO8473)、ISO10589、1992。
[IS9542] End system to Intermediate system routeing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service (ISO 8473), ISO 9542, 1988.
Intermediateシステムrouteing交換への[IS9542]エンドシステムは使用のためにコネクションレスなモードネットワーク・サービスを提供するためのプロトコルに関連して議定書を作ります。(ISO8473)、ISO9542、1988。
[RFC1629] Colella, R., Callon, R., Gardner, E., and Y. Rekhter, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, May 1994.
[RFC1629]Colella(R.、Callon、R.、ガードナー、E.、およびY.Rekhter、「インターネットのオウシNSAP Allocationのためのガイドライン」、RFC1629)は1994がそうするかもしれません。
[RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC 1326, May 1992.
[RFC1326]Tsuchiya(P.、「危険であると考えられた互いのカプセル化」、RFC1326)は1992がそうするかもしれません。
[RFC1883] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[RFC1883]のデアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC1883、12月1995日
[RFC1884] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995.
[RFC1884] Hinden、R.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC1884、1995年12月。
[RFC1971] Thompson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC1971, August 1996.
[RFC1971] トンプソン、S.とT.Narten、「IPv6の国がないアドレス自動構成」、RFC1971、1996年8月。
[RFC1970] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC1970, August 1996.
[RFC1970]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC1970、1996年8月。
[RFC1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[RFC1825] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、1995年8月。
Bound, et. al. Experimental [Page 12] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[12ページ]RFC1888OSI NSAPsとIPv6 August 1996
Annex A: Summary of NSAP Allocations
別館A: NSAP配分の概要
-----IDP------
-----------------------------------------------------
| AFI | IDI | DOMAIN SPECIFIC PART |
-----------------------------------------------------
--------------------20 bytes max---------------------
-----IDP------ ----------------------------------------------------- | AFI| イディ| ドメインの特定の部分| ----------------------------------------------------- --------------------20バイトの最大---------------------
The Initial Domain Part (IDP) is split into Authority and Format Identifier (AFI) followed by the Initial Domain Identifier (IDI). This combination is followed by the Domain Specific Part and allocation within that part is domain specific.
Initial Domain Part(IDP)はInitial Domain Identifier(IDI)によって続かれたAuthorityとFormat Identifier(AFI)に分割されます。 この組み合わせはDomain Specific Partによって続かれています、そして、その部分の中の配分はドメイン特有です。
The following is a summary of current allocations:
↓これは現在の配分の概要です:
ISO DCC Scheme
ISO DCC計画
AFI = decimal 38 or binary 39 = ISO Data Country Code Scheme. IDI = 3 decimal or binary digits specifying the country. ISO allocate the country codes. The DSP is administered by the standards authority for each country. In the UK, the British Standards Institution have delegated administration to the Federation of Electronics Industries - FEI
AFIは10進38か2進の39=ISO Data Country Code Schemeと等しいです。 IDIは国を指定する3小数かバイナリー・ディジットと等しいです。 ISOは国名略号を割り当てます。 DSPは規格権威によって各国に管理されます。 中では、イギリス、英国規格協会はElectronics IndustriesのFederationへ管理を代表として派遣しました--、FEI
The UK DSP is split into a single digit UK Format Indicator (UKFI) which indicates large, medium or small organisation rather like IP addressing and a UK Domain Identifier (UKDI). Using binary coded decimal examples only (there are binary equivalents):
UK DSPはIPアドレシングとイギリスのDomain Identifier(UKDI)のように大きいか、中型の、または、小さい機構を示す一桁のイギリスのFormat Indicator(UKFI)に分割されます。 バイナリーを使用すると、10進例だけがコード化されました(2進の同等物があります):
UKFI = 0 is reserved UKFI = 1, UKDI = nnn, UK Domain Specific Part = 31 digits. UKFI = 2, UKDI = nnnnn, UKDSP = 29 digits max. UKFI = 3, UKDI = nnnnnnnn, UKDSP = 26 digits max.
UKFI=0が予約されたUKFI=1である、UKDIはnnnと等しく、イギリスのDomain Specific Partは31ケタと等しいです。 UKFIは2、UKDI=nnnnn、UKDSP=29ケタ最大と等しいです。 UKFIは3、UKDI=nnnnnnnn、UKDSP=26ケタ最大と等しいです。
UKFI = 4 to 9 reserved
4〜9が予約したUKFI=
The UK Government have been allocated a UKDI in the UKFI = 1 (large organisation) format and have specified the breakdown of the Government Domain Specific Part with sub domain addresses followed by a station ID (which could be a MAC address) and a selector (which could be a TSAP selection).
イギリスの政府は、1つ(大きな組織)のUKFI=形式でUKDIを割り当てて、ステーションID(MACアドレスであるかもしれない)とセレクタが潜水艦ドメインアドレスを支えていて、政府Domain Specific Partの故障を指定しました(TSAP選択であるかもしれません)。
ITU-T X.121
ITU-T X.121
AFI = decimal 36 or 52, binary 37 or 53 indicates that the IDI is a 14 digit max X.121 International Numbering Plan address (prefix, 3 digit Data Country Code, dial up data network number). The full X.121 address indicates who controls the formatting of the DSP.
36か52の小数、2進の37またはAFI=53が、IDIがX.121の国際Numbering Planが記述する14ケタ最大(接頭語、3ケタData Country Code、ダイヤルアップデータ網番号)であることを示します。 完全なX.121アドレスは、だれがDSPの形式を制御するかを示します。
Bound, et. al. Experimental [Page 13] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[13ページ]RFC1888OSI NSAPsとIPv6 August 1996
ITU-T F.69
ITU-T F.69
AFI = 40,54 or binary 41,55 indicates that the IDI is a telex number up to 8 digits long.
AFI=40、54か2進の41、55は、IDIが長い間8ケタまでテレックス番号であることを示します。
ITU-T E.163
ITU-T E.163
AFI = 42,56 or binary 43,57 indicates that the IDI is a normal telephone number up to 12 digits long.
AFI=42、56か2進の43、57は、IDIが長い間12ケタまで正常な電話番号であることを示します。
ITU-T E.164
ITU-T E.164
AFI = 44,58 or binary 45,59 indicates that the IDI is an ISDN number up to 15 digits long.
AFI=44、58か2進の45、59は、IDIが長い間15ケタまでISDN番号であることを示します。
ISO 6523-ICD
ISO 6523-ICD
AFI = 46 or binary 47 indicates that the IDI is an International Code Designator allocated according to ISO 6523. You have to be a global organisation to get one of these. The Organisation to which the ISO 6523 designator is issued specifies the DSP allocation.
46か2進のAFI=47が、IDIがISO6523に応じて割り当てられた国際旗信号Designatorであることを示します。 あなたは、これらの1つを得るためにはグローバル組織でなければなりません。 ISO6523指示子が発行されるOrganisationはDSP配分を指定します。
Annex B: Additional Rationale
別館B: 追加原理
This annex is intended to give additional rationale, motivation and justification for the support of NSAPAs in an IPv6 network.
この別館がIPv6ネットワークにおける、NSAPAsのサポートのための追加原理、動機、および正当化を与えることを意図します。
There are several models for OSI-IPv6 convergence, of which address mapping is only one. The other models can be identified as
数個のモデルがOSI-IPv6集合を支持しています。そこでは、アドレス・マッピングが1であるだけです。 モデルを特定できるもう片方
1. Dual stack coexistence, in which a CLNP network and an IPv6
network exist side by side indefinitely using multiprotocol
routers.
1. デュアルスタック共存。(そこでは、CLNPネットワークとIPv6ネットワークが、並んで「マルチ-プロトコル」ルータを無期限に使用することで存在します)。
2. CLNP tunnels over IPv6.
2. CLNPはIPv6の上でトンネルを堀ります。
3. OSI transport over IPv6.
3. IPv6の上のOSI輸送。
4. OSI transport over UDP.
4. UDPの上のOSI輸送。
5. OSI transport over TCP (compare RFC 1006)
5. TCPの上のOSI輸送(RFC1006を比較します)
The present model is more fundamental, as it attempts to unify and reconcile the OSI and IPv6 addressing and routing schemes, and replace CLNP by IPv6 at the network level. The rationale for this choice is to preserve investment in NSAPA allocation schemes, and to open the door for peer-to-peer routing models between IPv6 and bearer services (such as ATM) using NSAPA addressing. It should be noted
現在のモデルは、より基本的です、OSI、IPv6アドレシング、およびルーティング計画を統一して、和解させて、CLNPをネットワークレベルにおけるIPv6に取り替えるのを試みるとき。 この選択のための原理がNSAPA配分体系への投資を保持することであり、ピアツーピアルーティングのためにドアを開けるのは、IPv6と運搬人サービス(ATMなどの)の間でNSAPAアドレシングを使用することでモデル化されます。 それは注意されるべきです。
Bound, et. al. Experimental [Page 14] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[14ページ]RFC1888OSI NSAPsとIPv6 August 1996
that such peer-to-peer models are contentious at the time of writing, but in any case a consistent address mapping is preferable to multiple mappings.
そのようなピアツーピアモデルがこれを書いている時点で議論好きですが、どのような場合でも、一貫したアドレス・マッピングは複数のマッピングより望ましいです。
In addition to their use to retain an existing addressing plan,
certain other uses of restricted NSAPAs could be envisaged. They
could be used as an intermediate addressing plan for a network making
a transition from CLNP to IPv6. They could be used in a header
translation scheme for dynamic translation between IPv6 and CLNP.
They could be used to allow CLNP and IPv6 traffic to share the same
routing architecture within an organization ("Ships in the Day").
既存のアドレシングプランを保有する彼らの使用に加えて、制限されたNSAPAsの他のある用途を考えることができました。 CLNPからIPv6までの変遷をするネットワークに中間的アドレシングプランとしてそれらを使用できました。 IPv6とCLNPの間のダイナミックな翻訳にヘッダー翻訳計画にそれらを使用できました。 CLNPとIPv6交通が組織(「1日の船」)の中で同じルーティング構造を共有するのを許容するのにそれらを使用できました。
It should be noted that the use of full NSAPA addresses in end systems impacts many things. The most obvious are the API and DNS. If applications are to work normally, everything that has to be modified to cope with IPv6 addresses has to be further modified for full NSAPAs. The mechanisms defined in the present document are only a small part of the whole.
完全なNSAPAの使用が終わりのシステム衝撃で多くのものを記述することに注意されるべきです。 最も明白であるのは、APIとDNSです。 アプリケーションが通常、働くことであるなら、IPv6アドレスに対処するように変更されなければならないすべてが完全なNSAPAsのためにさらに変更されなければなりません。 現在のドキュメントで定義されたメカニズムは全体の小さい部分にすぎません。
A destination option was chosen to carry full NSAPAs, in preference to a dedicated extension header. In the case of an extension header, all IPv6 nodes would have needed to understand its syntax merely in order to ignore it. In contrast, intermediate nodes can ignore the destination option without any knowledge of its syntax. Thus only nodes interested in NSAPAs need to know anything about them.
オプションが選ばれた目的地はひたむきな拡張ヘッダーに優先して完全なNSAPAsを運びます。 拡張ヘッダーのケースでは、すべてのIPv6ノードが、それを無視するのに単に構文を理解する必要があったでしょう。 対照的に、中間的ノードは構文に関する少しも知識なしで目的地オプションを無視できます。 したがって、NSAPAsに興味を持っているノードだけが、彼らに関して何でも知る必要があります。
Thus we end up with two classes of IPv6 nodes:
したがって、私たちは2つのクラスのIPv6ノードで終わります:
1. Nodes knowing only about 16 byte addresses (including restricted NSAPAs, which behave largely like any other IPv6 addresses).
1. およそ16のバイト・アドレス(包含は主にいかなる他のIPv6アドレスのようにも振る舞うNSAPAsを制限した)だけを知っているノード。
2. Nodes also knowing about 20 byte NSAPAs, either as an extension of the IPv6 address space or as the CLNP address space. In either case, regions of the network containing such nodes are connected to each other by unicast or anycast tunnels through the 16 byte address space. Routing, system configuration, and neighbour discovery in the NSAPA regions are outside the scope of the normal IPv6 mechanisms.
2. IPv6アドレス空間の拡大とした、または、CLNPアドレス空間としたノードのおよそ20バイトのまた、知っているNSAPAs。 どちらの場合ではも、そのようなノードを含むネットワークの領域は16バイトのアドレス空間を通してユニキャストかanycastトンネルによって互いにつなげられます。 正常なIPv6メカニズムの範囲の外にNSAPA領域でのルート設定、システム構成、および隣人発見があります。
Bound, et. al. Experimental [Page 15] RFC 1888 OSI NSAPs and IPv6 August 1996
etバウンド、アル。 実験的な[15ページ]RFC1888OSI NSAPsとIPv6 August 1996
Authors' Addresses
作者のアドレス
Jim Bound Member Technical Staff Phone: (603) 881-0400 Network Operating Systems Fax: (603) 881-0120 Digital Equipment Corporation Email: bound@zk3.dec.com 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062
ジムはメンバー技術スタッフ電話を縛りました: (603) 881-0400 ネットワークOS Fax: (603) 881-0120 DECメール: bound@zk3.dec.com 110Spitbrook道路、ZKO3-3/U14ナッシュア、ニューハンプシャー 03062
Brian E. Carpenter Group Leader, Communications Systems Phone: +41 22 767-4967 Computing and Networks Division Fax: +41 22 767-7155 CERN Telex: 419000 cer ch European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 1211 Geneva 23, Switzerland
ブライアンE.大工のグループのリーダー、システムが電話をするコミュニケーション: +41 22 767-4967コンピューティングとネットワーク区画Fax: +41 22 767-7155CERNはテレックスで送信します: 419000 cer ch欧州原子核共同研究機構メール: brian@dxcoms.cern.ch 1211ジュネーブ23(スイス)
Dan Harrington Phone: (508) 486-7643 Digital Equipment Corp. 550 King Street (LKG2-2/Q9) Email: dan@netrix.lkg.dec.com Littleton, MA 01460
ダンハリントンPhone: (508) 486-7643 ディジタル・イクイップメント社550キング・ストリート(LKG2-2/Q9)はメールされます: dan@netrix.lkg.dec.com リトルトン、MA 01460
Jack Houldsworth Phone- ICL: +44 438 786112 ICL Network Systems Home: +44 438 352997 Cavendish Road Fax: +44 438 786150 Stevenage Email: j.houldsworth@ste0906.wins.icl.co.uk Herts UK SG1 4BQ
ジャックHouldsworthはICLに電話をします: +44 438 786112 ICLネットワーク・システムは家へ帰ります: +44 438 352997キャベンディッシュ道路Fax: +44 438 786150 スティーブニッジメール: j.houldsworth@ste0906.wins.icl.co.uk ハーツイギリスのSG1 4BQ
Alan Lloyd Phone: +61 3 727 9222 Datacraft Technologies Fax: +61 3 727 1557 252 Maroondah Highway Email: alan.lloyd@datacraft.com.au Mooroolbark 3138 Victoria Australia
アランロイドPhone: +61 3つの727 9222Datacraft技術Fax: +61 3 727 1557 252 Maroondahハイウェイメール: alan.lloyd@datacraft.com.au Mooroolbark3138ビクトリア・オーストラリア
X.400- G=alan;S=lloyd;O=dcthq;P=datacraft;A=telememo;C=au
X.400G=alan; S=lloyd; O=dcthq; P=datacraft; A=telememo; CはAuと等しいです。
Bound, et. al. Experimental [Page 16]
etバウンド、アル。 実験的[16ページ]
一覧
スポンサーリンク
