RFC3831 日本語訳
3831 Transmission of IPv6 Packets over Fibre Channel. C. DeSanti. July 2004. (Format: TXT=53328 bytes) (Obsoleted by RFC4338) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. DeSanti Request for Comments: 3831 Cisco Systems Category: Standards Track July 2004
DeSantiがコメントのために要求するワーキンググループC.をネットワークでつないでください: 3831年のシスコシステムズカテゴリ: 標準化過程2004年7月
Transmission of IPv6 Packets over Fibre Channel
繊維チャンネルの上のIPv6パケットのトランスミッション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks.
このドキュメントはFibre Channelの上でパケットをIPv6にカプセルに入れる方法を指定します、そして、IPv6のリンクローカルのアドレスと状態がなさが自動構成した形成のメソッドはFibre Channelでネットワークに演説します。
Table Of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Fibre Channel . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Identifiers and Login. . . . . . . . . . . . . . . . . . 3
2.3. FC Levels and Frame Format . . . . . . . . . . . . . . . 4
2.4. Sequences and Exchanges . . . . . . . . . . . . . . . . 5
3. IPv6 Capable Nx_Ports. . . . . . . . . . . . . . . . . . . . . 6
4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FC Sequence Format . . . . . . . . . . . . . . . . . . . 6
4.2. FC Classes of Service. . . . . . . . . . . . . . . . . . 8
4.3. FC Header Code Points. . . . . . . . . . . . . . . . . . 8
4.4. FC Network_Header. . . . . . . . . . . . . . . . . . . . 9
4.5. LLC/SNAP Header. . . . . . . . . . . . . . . . . . . . . 9
4.6. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 9
5. Maximum Transfer Unit. . . . . . . . . . . . . . . . . . . . . 10
6. Stateless Address Autoconfiguration. . . . . . . . . . . . . . 10
6.1. IPv6 Interface Identifier and Address Prefix . . . . . . 10
6.2. Generating an Interface ID from a Format 1
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Generating an Interface ID from a Format 2
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 繊維チャンネル. . . . . . . . . . . . . . . . . . . 3 2.1の概要。 概要. . . . . . . . . . . . . . . . . . . . . . . . 3 2.2。 識別子とログイン。 . . . . . . . . . . . . . . . . . 3 2.3. FCレベルとフレーム形式. . . . . . . . . . . . . . . 4 2.4。 系列と交換. . . . . . . . . . . . . . . . 5 3。 IPv6のできるNx_ポート。 . . . . . . . . . . . . . . . . . . . . 6 4. IPv6カプセル化. . . . . . . . . . . . . . . . . . . . . . 6 4.1。 FC系列形式. . . . . . . . . . . . . . . . . . . 6 4.2。 サービスのFCのクラス。 . . . . . . . . . . . . . . . . . 8 4.3. FCヘッダーコードは指します。 . . . . . . . . . . . . . . . . . 8 4.4. FCは_ヘッダーをネットワークでつなぎます。 . . . . . . . . . . . . . . . . . . . 9 4.5. LLC/スナップヘッダー。 . . . . . . . . . . . . . . . . . . . . 9 4.6. ビットとバイト順。 . . . . . . . . . . . . . . . . . 9 5. 最大の移動単位数。 . . . . . . . . . . . . . . . . . . . . 10 6. 状態がないアドレス自動構成。 . . . . . . . . . . . . . 10 6.1. IPv6は識別子とアドレス接頭語. . . . . . 10 6.2を連結します。 形式1N_ポート_名からインタフェースIDを生成します。 . . . . . . . . . . . . . . . . . . . . . . 11 6.3. 形式2N_ポート_名からインタフェースIDを生成します。 . . . . . . . . . . . . . . . . . . . . . . 12
DeSanti Standards Track [Page 1] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[1ページ]。
6.4. Generating an Interface ID from a Format 5
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 13
6.5. Generating an Interface ID from an EUI-64
mapped N_Port_Name . . . . . . . . . . . . . . . . . . . 14
7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . . 15
8. Address Mapping for Unicast. . . . . . . . . . . . . . . . . . 15
9. Address Mapping for Multicast. . . . . . . . . . . . . . . . . 16
10. Sequence Management. . . . . . . . . . . . . . . . . . . . . . 17
11. Exchange Management. . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References. . . . . . . . . . . . . . . . . . 18
14.2. Informative References. . . . . . . . . . . . . . . . . 19
A. Transmission of a Broadcast FC Sequence over FC Topologies . . 20
B. Validation of the <N_Port_Name, N_Port_ID> mapping . . . . . . 21
C. Fibre Channel Bit and Byte Numbering Guidance. . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 24
6.4. 形式5N_ポート_名からインタフェースIDを生成します。 . . . . . . . . . . . . . . . . . . . . . . 13 6.5. EUI-64からInterface IDを生成すると、N_Port_Name. . . . . . . . . . . . . . . . . . . 14 7は写像されました。 リンクローカルのアドレス. . . . . . . . . . . . . . . . . . . . . 15 8。 ユニキャストのためにマッピングを扱ってください。 . . . . . . . . . . . . . . . . . 15 9. マルチキャストのためにマッピングを扱ってください。 . . . . . . . . . . . . . . . . 16 10. 系列管理。 . . . . . . . . . . . . . . . . . . . . . 17 11. 管理を交換してください。 . . . . . . . . . . . . . . . . . . . . . 17 12. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 18 13. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 18 14. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 18 14.1。 引用規格。 . . . . . . . . . . . . . . . . . 18 14.2. 有益な参照。 . . . . . . . . . . . . . . . . 19 <N_Port_NameのFC Topologies. . 20B.Validationの上のBroadcast FC Sequence、N_Port_ID>マッピング. . . . . . 21C.Fibre Channel Bit、およびByte Numbering GuidanceのA.トランスミッション。 . . . . . . . . 22作者のアドレスの.23の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
1. 序論
Fibre Channel (FC) is a high speed serial interface technology that supports several Upper Layer Protocols including Small Computer System Interface (SCSI) and IPv4 as specified in [IPFC].
繊維Channel(FC)は[IPFC]の指定されるとしてのSmallコンピュータSystem Interface(SCSI)とIPv4を含むいくつかのUpper Layerプロトコルをサポートする高速シリアルインタフェース技術です。
The purpose of this document is to specify a way of encapsulating IP version 6 [IPv6] over Fibre Channel and to describe a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured addresses on Fibre Channel networks. This document also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on a Fibre Channel network.
このドキュメントの目的は、Fibre Channelの上でIPバージョン6が[IPv6]であるとカプセル化する方法を指定して、IPv6のリンクローカルのアドレス[AARCH]と状態がない自動構成されたアドレスをFibre Channelネットワークに形成するメソッドを説明することです。 また、メッセージがFibre Channelネットワークで送られるとき、このドキュメントはオプションがNeighborディスカバリー[DISC]で使用したSource/目標Address Link-層の内容について説明します。
Warning to readers familiar with Fibre Channel: both Fibre Channel and IETF standards use the same byte transmission order. However, the bit numbering is different. See Appendix C for guidance.
Fibre Channelに詳しい読者への警告: Fibre ChannelとIETF規格の両方が同じバイトトランスミッション命令を使用します。 しかしながら、噛み付いている付番は異なっています。 指導に関してAppendix Cを見てください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?
DeSanti Standards Track [Page 2] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[2ページ]。
2. Summary of Fibre Channel
2. 繊維チャンネルの概要
2.1. Overview
2.1. 概要
Fibre Channel (FC) is a gigabit speed network technology primarily used for Storage Networking. Fibre Channel is standardized in the T11 Technical Committee of the InterNational Committee for Information Technology Standards (INCITS), an American National Standard Institute (ANSI) accredited standards committee.
繊維Channel(FC)はStorage Networkingに主として使用されるギガビット速度ネットワーク技術です。 繊維Channelは情報Technology Standards(INCITS)(米国標準規格のInstituteの(ANSI)公認の規格委員会)のためにInterNational CommitteeのT11 Technical Committeeで標準化されます。
Fibre Channel devices are called Nodes. Each Node has one or more Ports that connect to Ports of other devices. Fibre Channel may be implemented using any combination of the following three topologies:
繊維ChannelデバイスはNodesと呼ばれます。 各Nodeには、対向機器のPortsに接続する1Portsがあります。 繊維Channelは以下の3topologiesのどんな組み合わせも使用することで実装されるかもしれません:
- a point-to-point link between two Ports;
- a set of Ports interconnected by a switching network called a
Fabric, as defined in [FC-FS];
- a set of Ports interconnected with a loop topology, as defined in
[FC-AL-2].
- 2Portsの間のポイントツーポイント接続。 - Portsの1セットは[FC-FS]で定義されるようにFabricと呼ばれる切り換えネットワークによって内部連絡されました。 - Portsの1セットは[FC AL2]で定義されるように輪のトポロジーで内部連絡されました。
A Node Port is more precisely called an N_Port. A Node Port that is capable of operating in a loop topology using the loop specific protocols is designated as an NL_Port. The term Nx_Port is used to generically indicate these two kinds of Node Port.
Node Portは、より正確にN_Portと呼ばれます。 輪のトポロジーで輪の特定のプロトコルを使用することで作動できるNode PortはNL_Portとして指定されます。 Nx_Portという用語は、一般的にこれらの2種類のNode Portを示すのに使用されます。
A Fabric Port is more precisely called an F_Port. A Fabric Port that is capable of operating in a loop topology using the loop specific protocols is designated as an FL_Port. The term Fx_Port is used to generically indicate these two kinds of Fabric Port.
Fabric Portは、より正確にF_Portと呼ばれます。 輪のトポロジーで輪の特定のプロトコルを使用することで作動できるFabric Portはフロリダ_Portとして指定されます。 Fx_Portという用語は、一般的にこれらの2種類のFabric Portを示すのに使用されます。
From an IPv6 point of view, a Fibre Channel network, built with any combination of the FC topologies described above, is an IPv6 Link [IPv6]. IPv6-capable Nx_Ports are what [IPv6] calls Interfaces.
IPv6観点から、FC topologiesのどんな組み合わせも上で説明されている状態で造られたFibre ChannelネットワークはIPv6 Link[IPv6]です。 IPv6できるNx_Portsは[IPv6]がInterfacesと呼ぶものです。
2.2. Identifiers and Login
2.2. 識別子とログイン
Fibre Channel entities are identified by permanent 64 bit long Name_Identifiers. [FC-FS] defines several formats of Name_Identifiers. The value of the first four bits defines the format of a Name_Identifier. These names are referred to in a more precise manner as follows:
繊維Channel実体は永久的な長さ64ビットのName_Identifiersによって特定されます。 [FC-FS]はName_Identifiersのいくつかの書式を定義します。 最初の4ビットの価値はName_Identifierの書式を定義します。 これらの名前は以下のより正確な方法で示されます:
- an Nx_Port's Name_Identifier is called N_Port_Name; - an Fx_Port's Name_Identifier is called F_Port_Name; - a Node's Name_Identifier is called Node_Name; - a Fabric's Name_Identifier is called Fabric_Name.
- Nx_PortのName_IdentifierはN_Port_Nameと呼ばれます。 - Fx_PortのName_Identifierは_F Port_Nameと呼ばれます。 - NodeのName_IdentifierはNode_Nameと呼ばれます。 - FabricのName_IdentifierはFabric_Nameと呼ばれます。
DeSanti Standards Track [Page 3] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[3ページ]。
An Nx_Port connected to a Fibre Channel network is associated with two identifiers, its permanent N_Port_Name and a volatile 24 bit address called N_Port_ID. The N_Port_Name is used to identify the Nx_Port, while the N_Port_ID is used for communications among Nx_Ports.
Fibre Channelネットワークに接続されたNx_Portが2つの識別子に関連している、Port_Nameと揮発性の24ビットが扱う永久的なN_はN_をPort_IDと呼びました。 N_Port_NameはNx_Portを特定するのに使用されますが、N_Port_IDはNx_Portsの中のコミュニケーションに使用されます。
Each Nx_Port acquires an N_Port_ID from the Fabric by performing a process called Fabric Login or FLOGI. The FLOGI process is used also to negotiate several communications parameters between the Nx_Port and the Fabric, such as the receive data field size, which determines the maximum size of the Fibre Channel frames that may be transferred between the Nx_Port and the Fabric.
各Nx_Portは、FabricからFabric LoginかFLOGIと呼ばれるプロセスを実行することによって、N_Port_IDを取得します。 FLOGIプロセスはまた、Nx_PortとFabricの間のいくつかのコミュニケーションパラメタを交渉するのに使用されます、受信データ分野サイズなどのように。(それは、Nx_PortとFabricの間に移されるかもしれないFibre Channelフレームの最大サイズを測定します)。
Before effective communication may take place between two Nx_Ports, they must complete a process called Port Login or PLOGI. The PLOGI process provides each Nx_Port with the other Nx_Port's N_Port_Name, and negotiates several communication parameters, such as the receive data field size, which determines the maximum size of the Fibre Channel frames that may be transferred between the two Nx_Ports.
有効なコミュニケーションが2Nx_Portsの間の場所を取るかもしれない前に、彼らはPort LoginかPLOGIと呼ばれる過程を完了しなければなりません。 PLOGIプロセスは、もう片方のNx_Port Nの_Port_Nameを各Nx_Portに提供して、いくつかのコミュニケーションパラメタを交渉します、受信データ分野サイズなどのように。(それは、2Nx_Portsの間に移されるかもしれないFibre Channelフレームの最大サイズを測定します)。
Both Fabric Login and Port Login may be explicit, i.e., performed using specific FC control messages (called Extended Link Services or ELS), or implicit, in which the parameters are specified by configuration or other methods.
Fabric LoginとPort Loginの両方が明白であるかもしれない、すなわち、実行された使用特定のFC(パラメタは構成か他のメソッドで指定される)はメッセージ(Extended Link ServicesかELSと呼ばれる)、または暗黙で制御します。
2.3. FC Levels and Frame Format
2.3. FCレベルとフレーム形式
[FC-FS] describes the Fibre Channel protocol using 5 different levels. The FC-2 and FC-4 levels are relevant for this specification. The FC-2 level defines the FC frame format, the transport services, and control functions necessary for information transfer. The FC-4 level supports Upper Level Protocols, such as IPv4, IPv6 or SCSI. The Fibre Channel frame format is depicted in figure 1.
[FC-FS]は、5つの異なったレベルを使用することでFibre Channelプロトコルについて説明します。 この仕様において、FC-2とFC-4レベルは関連しています。 FC-2レベルはFCフレーム形式、輸送サービス、および情報転送に必要なコントロール機能を定義します。 FC-4レベルはIPv4、IPv6またはSCSIなどのプロトコルをUpper Levelにサポートします。 フレーム形式が表現されるFibre Channelは1について計算します。
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
+-----+-----------+-----------+--------//-------+-----+-----+ | | | データ・フィールド| | | | SOF| FCヘッダー| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| CRC| EOF| | | | 任意| フレーム| | | | | | ヘッダー| 有効搭載量| | | +-----+-----------+-----------+--------//-------+-----+-----+
Fig. 1: Fibre Channel Frame Format
図1: 繊維チャンネルフレーム形式
The Start of Frame (SOF) and End of Frame (EOF) are special FC transmission words that act as frame delimiters. The CRC is 4 octets long and uses the same 32-bit polynomial used in FDDI.
FrameのStart(SOF)とFrameのEnd(EOF)はフレームデリミタとして機能する特別なFCトランスミッション単語です。 CRCは長い間の4つの八重奏であり、FDDIで使用される同じ32ビットの多項式を使用します。
DeSanti Standards Track [Page 4] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[4ページ]。
The FC Header is 24 octets long and contains several fields associated with the identification and control of the Data Field.
FC Headerは長い間の24の八重奏であり、Data Fieldの識別とコントロールに関連しているいくつかの分野を含んでいます。
The Data Field is of variable size, ranging from 0 to 2112 octets, and includes the user data in the Frame Payload field, and Optional Headers. The currently defined Optional Headers are:
Data Fieldは0〜2112の八重奏まで及んで、可変サイズがあって、Frame有効搭載量分野、およびOptional Headersに利用者データを含んでいます。 現在定義されたOptional Headersは以下の通りです。
- ESP_Header; - Network_Header; - Association_Header; - Device_Header.
- 超能力_ヘッダー。 - _ヘッダーをネットワークでつないでください。 - 協会_ヘッダー。 - デバイス_ヘッダー。
The value of the SOF field determines the FC Class of service associated with the frame. Five Classes of service are specified in [FC-FS]. They are distinguished primarily by the method of flow control between the communicating Nx_Ports and by the level of data integrity provided. A given Fabric or Nx_Port may support one or more of the following Classes of service:
SOF分野の値はフレームに関連しているサービスのFC Classを決定します。 サービスの5Classesが[FC-FS]で指定されます。 それらを主として交信しているNx_Portsの間のフロー制御のメソッドが区別して、データ保全のレベルで提供します。 与えられたFabricかNx_Portが以下のサービスのClassesの1つ以上をサポートするかもしれません:
- Class 1: Dedicated physical connection with delivery confirmation; - Class 2: Frame multiplexed service with delivery confirmation; - Class 3: Datagram service; - Class 4: Fractional bandwidth; - Class 6: Reliable multicast via dedicated connections.
- クラス1: 配送確認とのひたむきな物理接続。 - クラス2: フレームは配送確認と共にサービスを多重送信しました。 - クラス3: データグラムサービス。 - クラス4: 断片的な帯域幅。 - クラス6: ひたむきな接続を通した信頼できるマルチキャスト。
2.4. Sequences and Exchanges
2.4. 系列と交換
An application level payload such as IPv6 is called Information Unit at the FC-4 level of Fibre Channel. Each FC-4 Information Unit is mapped to an FC Sequence by the FC-2 level. An FC Sequence consists of one or more FC frames related by the value of the Sequence_ID (SEQ_ID) field of the FC Header.
IPv6などのアプリケーションレベルペイロードはFibre ChannelのFC-4レベルで情報Unitと呼ばれます。 それぞれのFC-4情報UnitはFC-2レベルによってFC Sequenceに写像されます。 FC SequenceはFC HeaderのSequence_ID(SEQ_ID)分野の値によって関係づけられた1個以上のFCフレームから成ります。
The maximum data that may be carried by an FC frame is 2112 octets. The maximum usable frame size depends on the Fabric and Nx_Port implementations and is negotiated during the Login process. Whenever an Information Unit to be transmitted exceeds this value, the FC-2 level segments it into multiple FC frames, sent as a single Sequence. The receiving Nx_Port reassembles the Sequence of frames and delivers a reassembled Information Unit to the FC-4 level. The Sequence Count (SEQ_CNT) field of the FC Header may be used to ensure frame ordering.
FCフレームによって運ばれるかもしれない最大のデータは2112の八重奏です。 最大の使用可能なフレーム・サイズは、FabricとNx_Port実装によって、Loginプロセスの間、交渉されます。 伝えられるべき情報Unitがこの値を超えているときはいつも、FC-2レベルはそれを独身のSequenceとして送られた複数のFCフレームに区分します。 受信Nx_PortはフレームのSequenceを組み立て直して、組み立て直された情報UnitをFC-4レベルに提供します。 FC HeaderのSequence Count(SEQ_CNT)分野は、フレーム注文を確実にするのに使用されるかもしれません。
Multiple Sequences may be related together as belonging to the same FC Exchange. The Exchange is a mechanism used by two Nx_Ports to identify and manage an operation between them. The Exchange is opened when the operation is started between the two Nx_Ports, and closed when the operation ends. FC frames belonging to the same
複数のSequencesが同じFC Exchangeに属すとして一緒に関係づけられるかもしれません。 Exchangeは彼らの間の操作を特定して、管理するのに2Nx_Portsによって使用されたメカニズムです。 操作が終わるとき、Exchangeは操業が2Nx_Portsで開始されるとき、開かれて、閉じられます。 同じくらいに属すFCフレーム
DeSanti Standards Track [Page 5] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[5ページ]。
Exchange are related by the value of the Exchange_ID fields in the FC Header. An Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID) uniquely identify the Exchange.
交換はFC HeaderのExchange_ID分野の値によって関係づけられます。 Originator Exchange_ID(OX_ID)とResponder Exchange_ID(RX_ID)は唯一Exchangeを特定します。
3. IPv6 Capable Nx_Ports
3. IPv6のできるNx_ポート
This specification requires an IPv6 capable Nx_Port to have the following properties:
この仕様は、IPv6のできるNx_Portには以下の特性があるのを必要とします:
- The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
0xD, 0xE, 0xF (see section 6.1). IPv6 support for other
Name_Identifier formats is outside the scope of this
specification;
- It MUST support Class 3;
- It MUST support continuously increasing SEQ_CNT [FC-FS];
- It MUST be able to transmit and receive an FC-4 Information Unit
at least 1304 octets long;
- It SHOULD support a receive data field size for Device_Data FC
frames of at least 1024 octets.
- N_Port_Nameの形式は0×1の1つ、0×2、0×5、0xC、0xD、0xE、0xFであるに違いありません(セクション6.1を見てください)。 この仕様の範囲の外に他のName_Identifier形式のIPv6サポートがあります。 - それはClass3をサポートしなければなりません。 - それは、増加するSEQ_がCNT[FC-FS]であると絶え間なくサポートしなければなりません。 - それは長い間、FC-4情報Unit少なくとも1304八重奏を送受信できなければなりません。 - それ、SHOULDは、受信データ分野がサイズであると少なくとも1024の八重奏のDevice_Data FCフレームにサポートします。
4. IPv6 Encapsulation
4. IPv6カプセル化
4.1. FC Sequence Format
4.1. FC系列形式
An IPv6 packet is mapped to an Information Unit at the FC-4 level of Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2 level. An FC Information Unit containing an IPv6 packet MUST carry the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], resulting in the FC Information Unit format depicted in figure 2.
IPv6パケットはFibre ChannelのFC-4レベルで情報Unitに写像されます。(Fibre ChannelはFC-2レベルによって順番にFC Sequenceに写像されます)。 IPv6パケットを含むFC情報Unitは_図に表現されたFC情報Unit書式をもたらすHeader[FC-FS]とLLC/SNAPヘッダー[IEEE-LLC]のFC Network2を運ばなければなりません。
DeSanti Standards Track [Page 6] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[6ページ]。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ | | +- -+ | ネットワーク_ヘッダー| +(16の八重奏) -+| | +- -+ | | +---------------+---------------+---------------+---------------+ | LLC/SNAPヘッダー| +(8つの八重奏) -+| | +---------------+---------------+---------------+---------------+ | | +-+/IPv6パケット///+ -+| | +---------------+---------------+---------------+---------------+
Fig. 2: FC Information Unit Mapping an IPv6 Packet
図2: IPv6パケットを写像するFC情報ユニット
The FC ESP_Header [FC-FS] MAY be used to secure the FC frames composing the FC Sequence. [AH] or [ESP] may be used to provide security at the IPv6 layer. Other types of FC Optional Header MUST NOT be used in an IPv6 FC Sequence.
FC ESP_Header[FC-FS]は、FC Sequenceを構成するFCフレームを固定するのに使用されるかもしれません。 [AH]か[超能力]が、IPv6層でセキュリティを提供するのに使用されるかもしれません。 IPv6 FC SequenceでFC Optional Headerの他のタイプを使用してはいけません。
Typically, a Sequence consists of more than one frame. Only the first frame of the Sequence MUST include the FC Network_Header and the LLC/SNAP header. The other frames MUST NOT include them, as depicted in figure 3.
通常、Sequenceは1個以上のフレームから成ります。 Sequenceの最初のフレームだけがFC Network_HeaderとLLC/SNAPヘッダーを含まなければなりません。 他のフレームはそれらを含んではいけなくて、3は表現されるように中で計算します。
First Frame of an IPv6 FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IPv6 Packet |
+-----------+-------------------+-----------------+-------//--------+
IPv6 FC系列+の最初のフレーム-----------+-------------------+-----------------+-------//--------+ | FCヘッダー| FCネットワーク_ヘッダー| LLC/SNAPヘッダー| 最初の塊| | | | | IPv6パケット| +-----------+-------------------+-----------------+-------//--------+
Subsequent Frames of an IPv6 FC Sequence
+-----------+-----------------//------------------+
| FC Header | Additional chunk of the IPv6 Packet |
+-----------+----------------//-------------------+
IPv6 FC系列+のその後のフレーム-----------+-----------------//------------------+ | FCヘッダー| IPv6 Packetの追加塊| +-----------+----------------//-------------------+
Fig. 3: Optional Headers in an IPv6 FC Sequence
図3: IPv6 FC系列の任意のヘッダー
DeSanti Standards Track [Page 7] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[7ページ]。
4.2. FC Classes of Service
4.2. サービスのFCのクラス
This specification uses FC Class 3. IPv6 packets carrying Neighbor Discovery [DISC] messages MUST be encapsulated in Class 3 FC frames. Other IPv6 packets SHOULD use Class 3 as well. The use of other Classes of service is outside the scope of this specification.
この仕様はFC Class3を使用します。 Class3FCフレームでNeighborディスカバリー[DISC]メッセージを伝えるIPv6パケットをカプセルに入れらなければなりません。 他のIPv6パケットSHOULDはまた、Class3を使用します。 この仕様の範囲の外に他のサービスのClassesの使用があります。
4.3. FC Header Code Points
4.3. FCヘッダーコード・ポイント
The fields of the Fibre Channel Header are depicted in figure 4. The D_ID and S_ID fields contain respectively the destination N_Port_ID and the source N_Port_ID. To encapsulate IPv6 over Fibre Channel the following code points MUST be used:
Fibre Channel Headerの分野は表現されて、4が中で計算するということです。 D_IDとS_ID分野はそれぞれ目的地N_Port_IDとソースN_Port_IDを含んでいます。 Fibre Channelの上のIPv6に以下のコード・ポイントをカプセル化するのは使用されているに違いありません:
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [FC-FS])
- TYPE: 0x05 (IP over Fibre Channel)
- CS_CTL/Prio: 0x0
- DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6
Sequence, 0x00 for the following FC frames. If the FC ESP_Header
is used, then 0x60 for the first FC frame of an IPv6 Sequence,
0x40 for the following FC frames.
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID, Parameter: see section 10,
section 11, and [FC-FS] for additional requirements.
- _R CTL: 0×04 (デバイス_DataはUnsolicited Dataと共に情報Category[FC-FS]を縁どっています)--TYPE、: 0×05 (繊維チャンネルの上のIP)--_Cs CTL/Prio: 0×0--DF_CTL: 0×20 IPv6 Sequenceの最初のFCフレーム、以下のFCフレームへの0×00のための(ネットワーク_Header。) FC ESP_Headerが使用されているなら、次に、IPv6 Sequenceの最初のFCフレームへの0×60、以下のFCフレームに0×40です。 - F_CTL、SEQ_CNT、雄牛_ID SEQ_ID(ID)RX_パラメタ: 追加要件に関してセクション10、セクション11、および[FC-FS]を見てください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R_CTL | D_ID |
+---------------+---------------+---------------+---------------+
| CS_CTL/Prio | S_ID |
+---------------+---------------+---------------+---------------+
| TYPE | F_CTL |
+---------------+---------------+---------------+---------------+
| SEQ_ID | DF_CTL | SEQ_CNT |
+---------------+---------------+---------------+---------------+
| OX_ID | RX_ID |
+---------------+---------------+---------------+---------------+
| Parameter |
+---------------+---------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R_CTL| D_ID| +---------------+---------------+---------------+---------------+ | Cs_CTL/Prio| S_ID| +---------------+---------------+---------------+---------------+ | タイプ| F_CTL| +---------------+---------------+---------------+---------------+ | SEQ_ID| DF_CTL| SEQ_CNT| +---------------+---------------+---------------+---------------+ | 雄牛_ID| RX_ID| +---------------+---------------+---------------+---------------+ | パラメタ| +---------------+---------------+---------------+---------------+
Fig. 4: FC Header Format
図4: FCヘッダー形式
DeSanti Standards Track [Page 8] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[8ページ]。
4.4. FC Network_Header
4.4. FCネットワーク_ヘッダー
The fields of the FC Network_Header are depicted in figure 5. For use with IPv6 the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is outside the scope of this specification.
_Headerが表現されるFC Networkの分野は5について計算します。 IPv6との使用のために、N_Port_Names形式が0×1の1つ、0×2、0×5、0xC、0xD、0xE、0xFでなければなりません。 この仕様の範囲の外に他のName_Identifier形式の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | _+目的地Nポート_名前-+| | +---------------------------------------------------------------+ | | + ソースN_は_名前-+を移植します。| | +---------------------------------------------------------------+
Fig. 5: FC Network_Header Format
図5: FCネットワーク_ヘッダー形式
4.5. LLC/SNAP Header
4.5. LLC/スナップヘッダー
The fields of the LLC/SNAP Header [IEEE-LLC] are depicted in figure 6. To encapsulate IPv6 over Fibre Channel the following code points MUST be used:
[IEEE-LLC]が表現されるLLC/SNAP Headerの分野は6について計算します。 Fibre Channelの上のIPv6に以下のコード・ポイントをカプセル化するのは使用されているに違いありません:
- DSAP: 0xAA - SSAP: 0xAA - CTRL: 0x03 - OUI: 0x00-00-00 - PID: 0x86-DD
- DSAP: 0xAA--、SSAP: 0xAA--、CTRL: 0×03 --OUI、: 0×00 00-00 --PID、: 0×86DD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSAP| SSAP| CTRL| OUI| +---------------+---------------+---------------+---------------+ | OUI| PID| +---------------+---------------+---------------+---------------+
Fig. 6: LLC/SNAP Header Format
図6: LLC/スナップヘッダー形式
4.6. Bit and Byte Ordering
4.6. ビットとバイト順
IPv6 packets are mapped to the FC-4 level using the big-endian byte ordering that corresponds to the standard network byte order or canonical form.
IPv6パケットは、標準のネットワークバイトオーダーか標準形に対応するビッグエンディアンバイト順を使用することでFC-4レベルに写像されます。
DeSanti Standards Track [Page 9] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[9ページ]。
5. Maximum Transfer Unit
5. 最大の移動単位数
The default MTU size for IPv6 [IPv6] packets over Fibre Channel is 65280 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option that specifies a smaller MTU, or by manual configuration of each Nx_Port. However, as required by [IPv6], the MTU MUST NOT be lower than 1280 octets. If a Router Advertisement received on an Nx_Port has an MTU option specifying an MTU larger than 65280, or larger than a manually configured value, that MTU option MAY be logged to system management but MUST be otherwise ignored.
Fibre Channelの上のIPv6[IPv6]パケットのためのデフォルトMTUサイズは65280の八重奏です。 このサイズは、より小さいMTUを指定するMTUオプションを含むRouter Advertisement[DISC]、またはそれぞれのNx_Portの手動の構成によって減少させられるかもしれません。 しかしながら必要に応じて、[IPv6]、MTU MUST NOT、1280の八重奏より低くいてください。 PortがRouter AdvertisementがNx_で受信したならMTUを指定するMTUオプションを65280より大きくするか、手動で構成された値より大きくて、そのMTUオプションをシステム管理に登録されるかもしれませんが、別の方法で無視しなければなりません。
As the default MTU size far exceeds the message sizes typically used in the Internet, an IPv6 over FC implementation SHOULD implement Path MTU Discovery [PMTUD], or at least maintain different MTU values for on-link and off-link destinations.
デフォルトMTUサイズ、遠くに、インターネット(SHOULDがPath MTUディスカバリー[PMTUD]であると実装するか、または異なったMTU値であることをオンリンクとオフリンクの目的地に少なくとも支持するFC実装の上のIPv6)で通常使用されるメッセージサイズを超えています。
For correct operation in a routed environment, it is critically important to configure an appropriate MTU option in Router Advertisements.
発送された環境における正しい操作には、Router Advertisementsの適切なMTUオプションを構成するのは批判的に重要です。
For correct operation when mixed media (e.g., Ethernet and Fibre Channel) are bridged together, the smallest MTU of all the media must be advertised by routers in an MTU option. If there are no routers present, this MTU must be manually configured in each node which is connected to a medium with a default MTU larger than the smallest MTU.
混合媒体(例えば、イーサネットとFibre Channel)が一緒にブリッジされるときの正しい操作において、MTUオプションにおけるルータはすべてのメディアの最も小さいMTUの広告を出さなければなりません。 どんな存在しているルータもなければ、デフォルトMTUが最も小さいMTUより大きい状態で媒体に接続される各ノードで手動でこのMTUを構成しなければなりません。
6. Stateless Address Autoconfiguration
6. 状態がないアドレス自動構成
6.1. IPv6 Interface Identifier and Address Prefix
6.1. IPv6インタフェース識別子とアドレス接頭語
The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6 Interface Identifier is obtained by complementing the Universal/Local bit of the OUI field of the derived EUI-64 address.
Nx_PortがEUI-64アドレス[EUI64]に基づいているので、IPv6 Interface ID[AARCH]はNx_PortのNから_Port_Nameを引き出しました。 派生しているEUI-64アドレスのOUI分野のUniversal/地方のビットの補足となることによって、IPv6 Interface Identifierを入手します。
[FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers in EUI-64 addresses. This allows the usage of these Name_Identifiers to support IPv6. [FC-FS] also defines EUI-64 mapped FC Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived from an EUI-64 address. It is possible to reverse this address mapping to obtain the original EUI-64 address in order to support IPv6.
[FC-FS]は形式0x1(IEEE48ビット・アドレス)、または0×2(IEEE Extended)を写像するメソッド、またはEUI-64のIdentifiersが扱う0×5(IEEE Registered)FC Name_を指定します。 これで、これらのName_Identifiersの使用法はIPv6をサポートすることができます。 また、[FC-FS]はFC Name_Identifiers(形式の0xC、0xD、0xE、および0xF)であって、EUI-64アドレスからそんなに派生していた状態で写像されたEUI-64を定義します。 IPv6をサポートするためにオリジナルのEUI-64アドレスを得るためにこのアドレス・マッピングを逆にするのは可能です。
DeSanti Standards Track [Page 10] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[10ページ]。
Stateless address autoconfiguration MUST be performed as specified in [ACONF]. An IPv6 Address Prefix used for stateless address autoconfiguration of an Nx_Port MUST have a length of 64 bits.
状態がないアドレス自動構成として、[ACONF]で指定されていた状態で実行しなければなりません。 Nx_Portの状態がないアドレス自動構成に使用されるIPv6 Address Prefixは64ビットの長さを持たなければなりません。
6.2. Generating an Interface ID from a Format 1 N_Port_Name
6.2. 形式1N_ポート_名からインタフェースIDを生成します。
The Name_Identifier format 0x1 is depicted in figure 7.
書式0x1が表現されるName_Identifierは7について計算します。
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 0 0 1| 0x000 | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
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 0 0 1| 0×000| OUI| +-------+-------+---------------+---------------+---------------+ | OUI| VSID| +---------------+---------------+---------------+---------------+
Fig. 7: Format 0x1 Name_Identifier
図7: 形式0x1名前_識別子
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 8 [FC-FS].
このName_Identifierから得られたEUI-64アドレスで、エイト環[FC-FS]に書式を表現します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 補足となっているU/LビットがあるOUI|0 0 0 1| VSID| +---------------+---------------+-------+-------+-------+-------+ | VSID| 0×000| +---------------+---------------+-------+-------+---------------+
Fig. 8: EUI-64 Address from a Format 0x1 Name_Identifier
図8: 形式0x1名前_識別子からのEUI-64アドレス
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 9.
このEUI-64アドレスからOUI分野でU/Lビットの補足となることによって、IPv6 Interface Identifierを入手します。 それで、IPv6 Interface IDのOUIはまさにFC Name_Identifierのようにそうです。 結果として起こるIPv6 Interface Identifierは図9に地方の範囲[AARCH]と書式を表現させます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI|0 0 0 1| VSID| +---------------+---------------+-------+-------+-------+-------+ | VSID| 0×000| +---------------+---------------+-------+-------+---------------+
Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifier
図9: 形式0x1名前_識別子からのIPv6インタフェースID
DeSanti Standards Track [Page 11] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[11ページ]。
As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:461A:BCDE:F000.
例として、FC Name_Identifier0×10 00-34-63-46AB CD EFはIPv6 Interface Identifier3463:461A: BCDE:F000を発生させます。
6.3. Generating an Interface ID from a Format 2 N_Port_Name
6.3. 形式2N_ポート_名からインタフェースIDを発生させます。
The Name_Identifier format 0x2 is depicted in figure 10.
書式0x2が表現されるName_Identifierは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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0| Vendor Specific | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
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 0 1 0| 業者特有です。| OUI| +-------+-------+---------------+---------------+---------------+ | OUI| VSID| +---------------+---------------+---------------+---------------+
Fig. 10: Format 0x2 Name_Identifier
図10: 形式0x2名前_識別子
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 11 [FC-FS].
このName_Identifierから得られたEUI-64アドレスで、11[FC-FS]の図に書式を表現します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 補足となっているU/LビットがあるOUI|0 0 1 0| VSID| +---------------+-----------------------+-------+-------+-------+ | VSID| 業者特有です。| +---------------+-----------------------+-------+---------------+
Fig. 11: EUI-64 Address from a Format 0x2 Name_Identifier
図11: 形式0x2名前_識別子からのEUI-64アドレス
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 12.
このEUI-64アドレスからOUI分野でU/Lビットの補足となることによって、IPv6 Interface Identifierを入手します。 それで、IPv6 Interface IDのOUIはまさにFC Name_Identifierのようにそうです。 結果として起こるIPv6 Interface Identifierは図12に地方の範囲[AARCH]と書式を表現させます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI|0 0 1 0| VSID| +---------------+-----------------------+-------+-------+-------+ | VSID| 業者特有です。| +---------------+-----------------------+-------+---------------+
Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifier
図12: 形式0x2名前_識別子からのIPv6インタフェースID
As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:462A:BCDE:F789.
例として、FC Name_Identifier0×27 89-34-63-46AB CD EFはIPv6 Interface Identifier3463:462A: BCDE:F789を発生させます。
DeSanti Standards Track [Page 12] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[12ページ]。
6.4. Generating an Interface ID from a Format 5 N_Port_Name
6.4. 形式5N_ポート_名からインタフェースIDを発生させます。
The Name_Identifier format 0x5 is depicted in figure 13.
書式0x5が表現されるName_Identifierは13について計算します。
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 1 0 1| OUI | VSID |
+-------+-------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
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 1 0 1| OUI| VSID| +-------+-------+---------------+---------------+-------+-------+ | VSID| +---------------+---------------+---------------+---------------+
Fig. 13: Format 0x5 Name_Identifier
図13: 形式0x5名前_識別子
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 14 [FC-FS].
このName_Identifierから得られたEUI-64アドレスで、14[FC-FS]の図に書式を表現します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 補足となっているU/LビットがあるOUI|0 1 0 1| VSID| +---------------+---------------+---------------+-------+-------+ | VSID| +---------------+---------------+---------------+---------------+
Fig. 14: EUI-64 Address from a Format 0x5 Name_Identifier
図14: 形式0x5名前_識別子からのEUI-64アドレス
The IPv6 Interface Identifier is obtained from this EUI-64 address complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 15.
OUI分野でU/Lビットの補足となるこのEUI-64アドレスからIPv6 Interface Identifierを入手します。 それで、IPv6 Interface IDのOUIはまさにFC Name_Identifierのようにそうです。 結果として起こるIPv6 Interface Identifierは図15に地方の範囲[AARCH]と書式を表現させます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI|0 1 0 1| VSID| +---------------+---------------+---------------+-------+-------+ | VSID| +---------------+---------------+---------------+---------------+
Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifier
図15: 形式0x5名前_識別子からのIPv6インタフェースID
As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789.
例、FC Name_Identifier、0×53 46-34-6A紀元前DE F7-89、IPv6 Interface Identifier3463:465A: BCDE:F789を発生させます。
DeSanti Standards Track [Page 13] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[13ページ]。
6.5. Generating an Interface ID from an EUI-64 mapped N_Port_Name
6.5. EUI-64からInterface IDを発生させると、N_Port_Nameは写像されました。
The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF) are derived from an EUI-64 address by compressing the OUI field of such addresses. The compression is performed by removing from the OUI the Universal/Local and Individual/Group bits, and by putting bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and bits 8 to 23 of the OUI in the second and third octet of the Name_Identifier, as shown in figure 16.
EUI-64アドレスからそのようなアドレスのOUI分野を圧縮することによって、写像しているName_Identifiersがフォーマットする(0xFを通して0xCをフォーマットします)EUI-64を得ます。 圧縮はOUIからName_Identifierの最初の八重奏、2番目のOUIのビット8〜23、およびName_Identifierの3番目の八重奏でビットを置くのによるUniversal/地方とIndividual/グループビット、および5 0〜OUIを取り除くことによって、実行されます、16が中で計算するのが示されるように。
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| OUI[0..5] | OUI[8..23] | VSID |
+---+-----------+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
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| OUI[0 .5]| OUI[8 .23]| VSID| +---+-----------+---------------+---------------+---------------+ | VSID| +---------------+---------------+---------------+---------------+
Fig. 16: EUI-64 Mapped Name_Identifiers Format
図16: EUI-64は名前_識別子形式を写像しました。
The EUI-64 address used to generate the Name_Identifier shown in figure 16 has the format depicted in figure 17.
16が中で計算するのが示されたName_Identifierを発生させるのに使用されるEUI-64アドレスで、図17に書式を表現します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI[0 .5]|0 0| OUI[8 .23]| VSID| +-----------+---+---------------+---------------+---------------+ | VSID| +---------------+---------------+---------------+---------------+
Fig. 17: EUI-64 Address from an EUI-64 Mapped Name_Identifier
図17: EUI-64からのEUI-64アドレスは名前_識別子を写像しました。
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. The resulting IPv6 Interface Identifier has global scope [AARCH] and the format depicted in figure 18.
このEUI-64アドレスからOUI分野でU/Lビットの補足となることによって、IPv6 Interface Identifierを入手します。 結果として起こるIPv6 Interface Identifierは図18にグローバルな範囲[AARCH]と書式を表現させます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |1 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI[0 .5]|1 0| OUI[8 .23]| VSID| +-----------+---+---------------+---------------+---------------+ | VSID| +---------------+---------------+---------------+---------------+
Fig. 18: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier
図18: EUI-64からのIPv6インタフェースIDは名前_識別子を写像しました。
DeSanti Standards Track [Page 14] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[14ページ]。
As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A generates the IPv6 Interface Identifier 3663:46AB:0125:789A.
例、FC Name_Identifier 0xCD-63-46-AB01-25-78-9AがIPv6 Interface Identifier3663: 46AB:0125:789Aを発生させるので。
7. Link-Local Addresses
7. リンクローカルのアドレス
The IPv6 link-local address [AARCH] for an Nx_Port is formed by appending the Interface Identifier, as defined in section 6, to the prefix FE80::/64. The resulting address is depicted in figure 19.
Nx_PortのためのIPv6リンクローカルアドレス[AARCH]はInterface Identifierを追加することによって、形成されます、セクション6で定義されるように、接頭語FE80に:、:/64. 結果として起こるアドレスは表現されて、19が中で計算するということです。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
10ビット54ビット64ビット+----------+-----------------------+----------------------------+ |1111111010| (ゼロ) | インタフェース識別子| +----------+-----------------------+----------------------------+
Fig. 19: IPv6 link-local Address Format
図19: IPv6のリンク地方のAddress Format
8. Address Mapping for Unicast
8. ユニキャストのためのアドレス・マッピング
An Nx_Port has two kinds of Fibre Channel addresses:
Nx_Portには、2種類のFibre Channelアドレスがあります:
- a non-volatile 64-bit address, called N_Port_Name; - a volatile 24-bit address, called N_Port_ID.
- N_Port_Nameと呼ばれる非揮発性の64ビットのアドレス。 - N_Port_IDと呼ばれる揮発性の24ビットのアドレス。
The N_Port_Name is used to uniquely identify the Nx_Port, while the N_Port_ID is used to route frames to the Nx_Port. Both FC addresses are required to resolve an IPv6 unicast address. The fact that the N_Port_ID is volatile implies that an Nx_Port MUST validate the mapping between its N_Port_Name and N_Port_ID when certain Fibre Channel events occur (see Appendix B).
N_Port_Nameは唯一Nx_Portを特定するのに使用されますが、N_Port_IDは、Nx_Portにフレームを発送するのに使用されます。 両方のFCアドレスが、IPv6ユニキャストアドレスを決議するのに必要です。 N_Port_IDが不安定であるという事実は、あるFibre Channel出来事が起こると(Appendix Bを見てください)Nx_Portが_N_Port_NameとN Port_IDの間のマッピングを有効にしなければならないのを含意します。
The procedure for mapping IPv6 unicast addresses into Fibre Channel link-layer addresses uses the Neighbor Discovery Protocol [DISC]. The Source/Target Link-layer Address option has the format depicted in figure 20 when the link layer is Fibre Channel.
IPv6ユニキャストアドレスをFibre Channelリンクレイヤアドレスに写像するための手順はNeighborディスカバリープロトコル[DISC]を使用します。 リンクレイヤがFibre Channelであるときに、Source/目標Link-層のAddressオプションで、20図に書式を表現します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Reserved |
+---------------+---------------+---------------+---------------+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ=2| 予約されます。| +---------------+---------------+---------------+---------------+ | | +N __名前-+を移植してください。| | +---------------+---------------+---------------+---------------+ | 予約されます。| N_ポート_ID| +---------------+---------------+---------------+---------------+
Fig. 20: Source/Target Link-layer Address option for Fibre Channel
図20: Fibre Channelのためのソース/目標Link-層のAddressオプション
DeSanti Standards Track [Page 15] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[15ページ]。
Type: 1 for Source Link-layer address.
2 for Target Link-layer address.
以下をタイプしてください。 1 Source Link-層のアドレスのために。 2 Target Link-層のアドレスのために。
Length: 2 (in units of 8 octets).
長さ: 2 (8つの八重奏のユニットの。)
N_Port_Name: This field contains the Nx_Port's N_Port_Name. N_Port_ID: This field contains the Nx_Port's N_Port_ID.
ポート_が命名するN_: この分野はNx_Port Nの_Port_Nameを含んでいます。 N_ポート_ID: この分野はNx_Port Nの_Port_IDを含んでいます。
Reserved fields MUST be zero when transmitting, and MUST be ignored when receiving.
予約された分野を伝わるときのゼロでなければならなく、受信するとき、無視しなければなりません。
9. Address Mapping for Multicast
9. マルチキャストのためのアドレス・マッピング
By default, all best-effort IPv6 multicast packets MUST be mapped to FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In particular, datagrams addressed to all-nodes multicast address, all-routers multicast address, and solicited-node multicast addresses [AARCH] MUST be sent as Class 3 FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In this case, the Destination N_Port_Name field of the FC Network_Header MUST be set to the value 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A specifies how to transmit a Class 3 broadcast FC Sequence over various Fibre Channel topologies.
デフォルトで、_放送N Port_ID0xFF-FF-FFに記述されたFC Sequencesにすべてのベストエフォート型IPv6マルチキャストパケットを写像しなければなりません。 特に、_放送N Port_ID0xFF-FF-FFに記述されたClass3FC Sequencesとしてオールノードマルチキャストアドレス、オールルータマルチキャストアドレス、および請求されたノードマルチキャストアドレス[AARCH]に記述されたデータグラムを送らなければなりません。 この場合、FC Network_HeaderのDestination N_Port_Name分野を0×10値の00-FF-FF-FF-FF-FF-FFに設定しなければなりません。 付録AはClass3放送FC Sequenceを様々なFibre Channel topologiesの上に伝える方法を指定します。
An Nx_Port supporting IPv6 MUST be able to map a received broadcast Class 3 Device_Data FC frame to an implicit Port Login context in order to handle IPv6 multicast packets. The receive data field size of this implicit Port Login MUST be the same across all the Nx_Ports connected to the same Fabric, otherwise FC broadcast transmission does not work. In order to reduce the need for FC Sequence segmentation, the receive data field size of this implicit Port Login SHOULD be 1024 octets. This receive data field size requirement applies to broadcast Device_Data FC frames, not to ELSs.
IPv6を支持するNx_Portは、IPv6マルチキャストパケットを扱うために容認された放送Class3Device_Data FCフレームを暗黙のPort Login文脈に写像できなければなりません。 この内在しているPort Loginの受信データ分野サイズがすべてのNx_Portsの向こう側の同じくらいが同じFabricに接続したということであるに違いない、さもなければ、FC放送送信は働いていません。 減少するために、FC Sequence分割の必要性、受信データは1024が八重奏であったならこの内在しているPort Login SHOULDのサイズをさばきます。 この受信データ分野サイズ要件はELSsではなく、放送Device_Data FCフレームに適用されます。
Receiving an FC Sequence carrying an IPv6 multicast packet MAY trigger some additional processing by the Nx_Port if that IPv6 packet requires a unicast reply. In this case, if a valid Port Login to the Nx_Port that sent the IPv6 multicast packet does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast IPv6 reply. In the case of Neighbor Discovery messages [DISC], the N_Port_ID to which the Port Login is directed is taken from the N_Port_ID field of the Source/Target Link-layer Address option.
IPv6マルチキャストパケットを運びながらFC Sequenceを受けると、そのIPv6パケットがユニキャスト回答を必要とするなら、Nx_Portによる何らかの追加処理が引き金となるかもしれません。 この場合、IPv6マルチキャストパケットを送ったNx_Portへの有効なPort Loginが存在していないなら、Nx_PortはそのようなPort Loginを実行して、次に、ユニキャストIPv6回答にそれを使用しなければなりません。 Neighborディスカバリーメッセージ[DISC]の場合では、Source/目標Link-層のAddressオプションのN_Port_ID分野からPort Loginが向けられるN_Port_IDを取ります。
As an example, an Nx_Port processes a received broadcast FC Sequence carrying an IPv6 multicast unsolicited router advertisement [DISC] simply by passing the carried IPv6 packet to the IPv6 layer. Instead, if a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] requiring a unicast reply, and
例として、Nx_Portは単に運ばれたIPv6パケットをIPv6層に通過することによってIPv6のマルチキャストの求められていないルータ通知[DISC]を運ぶ容認された放送FC Sequenceを処理します。 そして代わりに、FC Sequenceが容認された放送であるならユニキャスト回答を必要としながらIPv6マルチキャスト懇願メッセージ[DISC]を伝える。
DeSanti Standards Track [Page 16] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[16ページ]。
no valid Port Login exists with the Nx_Port sender of the multicast packet, then a Port Login MUST be performed in order to send the unicast reply message. If a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] requiring a multicast reply, the reply is sent to the broadcast N_Port_ID 0xFF-FF-FF.
どんな有効なPort LoginもマルチキャストパケットのNx_Port送付者と共に存在していなくて、次に、ユニキャスト応答メッセージを送るためにPort Loginを実行しなければなりません。 容認された放送FC Sequenceがマルチキャスト回答を必要としながらIPv6マルチキャスト懇願メッセージ[DISC]を伝えるなら、_放送N Port_ID0xFF-FF-FFに回答を送ります。
Best-effort IPv6 multicast for other multicast group addresses MAY use Fibre Channel Multicast Groups [FC-FS], if supported by the particular FC topology and implementation.
他のマルチキャストグループアドレスのためのベストエフォート型IPv6マルチキャストはFibre Channel Multicast Groups[FC-FS]を使用するかもしれません、特定のFCトポロジーと実現で支持されるなら。
10. Sequence Management
10. 系列管理
FC Sequences are REQUIRED to be non-streamed. In order to avoid missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting IPv6 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST start with SEQ_CNT = 0 in the first frame, and every frame transmitted after that MUST increment the previous SEQ_CNT by one. Any frames received from the other N_Port in the Exchange shall have no effect on the transmitted SEQ_CNT.
FC Sequencesは非流されるべきREQUIREDです。 Sequence_ID再利用でFCフレームエイリアシングを逃すのを避けて、IPv6を支持するNx_PortはSEQ_CNT[FC-FS]を増加させながら連用するREQUIREDです。 それが前のSEQ_CNTを1つ増加しなければならなかった後に各Exchangeは最初のフレームのSEQ_CNT=0と伝えられるあらゆるフレームから始まらなければなりません。 Exchangeのもう片方のN_Portから受け取られたどんなフレームも伝えられたSEQ_CNTで効き目がないものとします。
11. Exchange Management
11. 交換管理
To transfer IPv6 packets, each Nx_Port MUST have a dedicated Exchange for sending data to each Nx_Port in the network and a dedicated Exchange for receiving data from each Nx_Port.
IPv6パケットを移すために、各Nx_Portにはネットワークにおける各Nx_Portにデータを送るための専用Exchangeと各Nx_Portからデータを受け取るための専用Exchangeがなければなりません。
An Exchange Responder is not required to assign RX_IDs. If an RX_ID of 0xFFFF is assigned, the Exchange Responder is identifying Exchanges based on S_ID / D_ID / OX_ID only.
Exchange Responderは、RX_IDを割り当てるのに必要ではありません。 0xFFFFのRX_IDが割り当てられるなら、Exchange ResponderはS_ID/D_ID/OX_IDだけに基づくExchangesを特定しています。
When an Exchange is created between two Nx_Ports for unicast IPv6 packets, it remains active while the Nx_Ports are logged in with each other. Each FC broadcast and ELS [FC-FS] SHOULD use a separate short lived Exchange.
ExchangeがユニキャストIPv6パケットのために2Nx_Portsの間で作成されるとき、Nx_Portsは互いと共にログインされますが、それはアクティブなままです。 それぞれのFC放送とELS[FC-FS]SHOULDは別々の短い送られたExchangeを使用します。
For IPv6, Exchanges MUST NOT transfer Sequence Initiative, because they are used in a unidirectional mode. The Sequence Initiative bit in the F_CTL field of the FC Header [FC-FS] MUST be set to 0.
IPv6に関しては、彼らが単方向のモードで使用されるので、ExchangesはSequence Initiativeを移してはいけません。 FC Header[FC-FS]のF_CTL分野のSequence Initiativeビットを0に設定しなければなりません。
The mechanism for aging or expiring exchanges based on activity, timeout, or other methods is outside the scope of this document.
このドキュメントの範囲の外に活動、タイムアウト、または他の方法に基づく交換を年をとるか、または吐き出すためのメカニズムがあります。
The Exchange Originator MAY terminate Exchanges by setting the F_CTL LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange Originator or Exchange Responder by using the ABTS (Abort Sequence) protocol [FC-FS]. IPv6 Exchanges SHOULD NOT be terminated by Logout, since this may terminate active Exchanges on other FC-4s [FC-FS].
Exchange Originatorは、F_CTL LSビット[FC-FS]を設定することによって、Exchangesを終えるかもしれません。 交換は、ABTS(Sequenceを中止する)プロトコル[FC-FS]を使用することによって、Exchange OriginatorかExchange Responderによって取りこわされるかもしれません。 これが終えるかもしれないので、IPv6 Exchanges SHOULDがLogoutによって終えられないで、他のFC-4[FC-FS]でアクティブなExchangesを終えてください。
DeSanti Standards Track [Page 17] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[17ページ]。
12. Security Considerations
12. セキュリティ問題
IPv6 does not introduce any additional security concerns beyond those that already exist within the Fibre Channel protocols. Zoning techniques based on FC Name Server masking (soft zoning) do not work with IPv6, because IPv6 over Fibre Channel does not use the FC Name Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames composing FC Sequences carrying IPv6 packets. All the techniques defined to secure IPv6 traffic at the IPv6 layer may be used in a Fibre Channel environment.
IPv6はFibre Channelプロトコルの中に既に存在するものを超えて少しの追加担保関心も導入しません。 (柔らかい帯状になること)にマスクをかけるFC Name Serverに基づく帯状になることのテクニックはIPv6と共に利きません、Fibre Channelの上のIPv6がFC Name Serverを使用しないので。FC ESP_Header[FC-FS]は、IPv6パケットを運ぶFC Sequencesを構成するFCフレームを固定するのに使用されるかもしれません。 IPv6層でIPv6交通を保証するために定義されたすべてのテクニックがFibre Channel環境で使用されるかもしれません。
13. Acknowledgments
13. 承認
The author would like to acknowledge the authors of [IPFC], [ETHER], and [IPv6-1394], since some part of this document has been derived from them, as well as the ANSI INCITS T11.3 Task Group members who reviewed this document.
作者は[IPFC]、[ETHER]、および[IPv6-1394]の作者を承認したがっています、彼らからこのドキュメントの何らかの部分を得たので、このドキュメントを再検討したANSI INCITS T11.3 Task Groupメンバーと同様に。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and
Signaling (FC-FS)".
[FC-FS]ANSI INCITS373-2003、「縁どっていて合図(FC-FS)である繊維チャンネル。」
[FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2
(FC-AL-2)".
[FC AL2] ANSI INCITS332-1999、「繊維チャンネル--輪-2(FC AL2)を仲裁します」。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[AARCH]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[ACONF] トムソンとS.とT.Narten、「IPv6の国がないアドレス自動構成」、RFC2462、1998年12月。
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[ディスク]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[PMTUD] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[PMTUD] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture".
[IEEE-LLC]IEEE Std802-2001、「地方とメトロポリタンエリアネットワークのIEEE規格:」 「概観と構造。」
DeSanti Standards Track [Page 18] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[18ページ]。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
14.2. Informative References
14.2. 有益な参照
[IPFC] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP
over Fibre Channel", RFC 2625, June 1999.
[IPFC] RajagopalとM.とBhagwat、R.とW.リカード、「繊維の上のIPとARPは精神を集中する」RFC2625、1999年6月。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
http://standards.ieee.org/db/oui/tutorials/EUI64.html
[EUI64] 「64ビットのグローバルな識別子(EUI-64)のためのガイドライン」、 http://standards.ieee.org/db/oui/tutorials/EUI64.html
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[エーテル] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
over IEEE 1394 Networks", RFC 3146, October 2001.
[IPv6-1394] 藤沢とK.とA.尾上、「IEEE1394ネットワークの上のIPv6パケットのトランスミッション」、RFC3146、2001年10月。
DeSanti Standards Track [Page 19] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[19ページ]。
A. Transmission of a Broadcast FC Sequence over FC Topologies
A。 FC Topologiesの上の放送FC系列の送信
A.1. Point-to-Point Topology
A.1。 二地点間トポロジー
No particular mechanisms are required for this case. The Nx_Port connected at the other side of the cable receives the broadcast FC Sequence having D_ID 0xFFFFFF.
どんな特定のメカニズムもこのような場合必要ではありません。 ケーブルの反対側で接続されたNx_PortはD_ID0xFFFFFFを持っている放送FC Sequenceを受けます。
A.2. Private Loop Topology
A.2。 個人的な輪のトポロジー
An NL_Port attached to a private loop MUST transmit a Class 3 broadcast FC Sequence by using the OPN(fr) primitive signal [FC-AL-2].
個人的な輪に取り付けられたNL_Portは、OPN(fr)の原始の信号[FC AL2]を使用することによって、Class3放送FC Sequenceを伝えなければなりません。
a) The source NL_Port first sends an Open Broadcast Replicate
(OPN(fr)) primitive signal, forcing all the NL_Ports in the loop
(except itself) to replicate the frames that they receive while
examining the FC Header's D_ID field.
b) The source NL_Port then removes the OPN(fr) signal when it returns
to it.
c) The source NL_Port then sends the Class 3 broadcast FC Sequence
having D_ID 0xFFFFFF.
a) ソースNL_Portは最初に、オープンBroadcast Replicateを送ります(OPN(fr)の原始の信号、輪(それ自体を除いた)のすべてのNL_Portsに模写させて、彼らがFC HeaderのD_IDを調べている間に受けるフレームは. bをさばきます)。 . c)をそれに返すとき、そしてソースNL_PortはOPN(fr)信号を取り除きます。 そして、ソースNL_PortはClass3放送FC SequenceにD_ID0xFFFFFFを持たせます。
A.3. Public Loop Topology
A.3。 公共の輪のトポロジー
An NL_Port attached to a public loop MUST NOT use the OPN(fr) primitive signal. Rather, it MUST send the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00 [FC-AL-2].
公共の輪に取り付けられたNL_PortはOPN(fr)の原始の信号を使用してはいけません。 むしろ、それで、Class3放送FC SequenceはAL_PA=0x00[FC AL2]にD_ID0xFFFFFFをフロリダ_Portに持たなければなりません。
The Fabric propagates the broadcast to all other FC_Ports [FC-FS], including the FL_Port which the broadcast arrives on. This includes all F_Ports, and other FL_Ports.
Fabricは放送が到着するフロリダ_Portを含む他のすべてのFC_Ports[FC-FS]に放送を伝播します。 これは_すべてのF Ports、および_他のフロリダPortsを含んでいます。
Each FL_Port propagates the broadcast by using the primitive signal OPN(fr), in order to prepare the loop to receive the broadcast sequence.
各フロリダ_Portは原始の信号OPN(fr)を使用することによって、放送を伝播します、放送系列を受け取るために輪を準備するために。
A.4. Fabric Topology
A.4。 織物トポロジー
An N_Port connected to an F_Port MUST transmit the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric propagates the broadcast to all other FC_Ports [FC-FS].
F_Portに接続されたN_PortはD_ID0xFFFFFFをF_Portに持っているClass3放送FC Sequenceを伝えなければなりません。 Fabricは他のすべてのFC_Ports[FC-FS]に放送を伝播します。
DeSanti Standards Track [Page 20] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[20ページ]。
B. Validation of the <N_Port_Name, N_Port_ID> mapping
B。 <N_Port_Nameの合法化、N_Port_ID>マッピング
B.1. Overview
B.1。 概観
At all times, the <N_Port_Name, N_Port_ID> mapping must be valid before use.
いつも、<N_Port_Name、N_Port_ID>マッピングは使用の前に有効であるに違いありません。
After an FC link interruption occurs, the N_Port_ID of an Nx_Port may change, as well as the N_Port_IDs of all other Nx_Ports that have previously performed Port Login with this Nx_Port. Because of this, address validation is required after a LIP in a loop topology [FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS].
FCリンク中断が発生した後に、Nx_PortのN_Port_IDは変化するかもしれません、以前にこのNx_Portと共にPort Loginを実行した他のすべてのNx_PortsのN_Port_IDと同様に。 これのために、アドレス合法化が輪のトポロジーのLIP[FC AL2]の後か二地点間トポロジーのNOS/OLS[FC-FS]の後に必要です。
N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS], thus address validation is not required in this case.
N_ポート_IDはLink Reset(LR)[FC-FS]の結果、変化しません、その結果、アドレス合法化がこの場合必要ではありません。
B.2. FC Layer Address Validation in a Point-to-Point Topology
B.2。 二地点間トポロジーでのFC層のアドレス合法化
No validation is required after LR. In a point-to-point topology, NOS/OLS causes implicit Logout of each N_Port and after a NOS/OLS each N_Port must again perform a Port Login [FC-FS].
合法化は全くLRの後に必要ではありません。 二地点間トポロジーでは、NOS/OLSがそれぞれのN_Portの内在しているLogoutを引き起こします、そして、NOS/OLSの後に、各N_Portが再び、Port Login[FC-FS]を実行しなければなりません。
B.3. FC Layer Address Validation in a Private Loop Topology
B.3。 個人的な輪のトポロジーでのFC層のアドレス合法化
After a LIP [FC-AL-2], an NL_Port must not transmit any data to another NL_Port until the address of the other port has been validated. The validation consists of completing either ADISC or PDISC [FC-FS].
LIP[FC AL2]の後に、もう片方のポートのアドレスが有効にされるまで、NL_Portは別のNL_Portに少しのデータも送ってはいけません。 合法化はADISCかPDISC[FC-FS]のどちらかを完成するのから成ります。
For a requester, this specification prohibits PDISC and requires ADISC. As a responder, an implementation may need to respond to both ADISC and PDISC for compatibility with other FC specifications.
リクエスタに関しては、この仕様は、PDISCを禁止して、ADISCを必要とします。 応答者として、実現は、他のFC仕様との互換性のためのADISCとPDISCの両方に応じる必要があるかもしれません。
If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a logged remote NL_Port exactly match the values prior to the LIP, then any active Exchange with that NL_Port may continue.
登録されたリモートNL_Portの3つのFCアドレス(N_Port_ID、N_Port_Name、Node_Name)がまさにLIPの前で値に合っているなら、そのNL_PortとどんなアクティブなExchangeも続くかもしれません。
If any of the three FC addresses has changed, then the remote NL_Port must be logged out.
3つのFCアドレスのどれかが変化したなら、リモートNL_Portをログアウトしなければなりません。
If an NL_Port's N_Port_ID changes after a LIP, then all active logged in NL_Ports must be logged out.
NL_Port Nの_Port_IDがLIPの後に変化するなら、すべてのアクティブなログインされたNL_Portsをログアウトしなければなりません。
DeSanti Standards Track [Page 21] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[21ページ]。
B.4. FC Layer Address Validation in a Public Loop Topology
B.4。 公共の輪のトポロジーでのFC層のアドレス合法化
A FAN ELS may be sent by the Fabric to all known previously logged in NL_Ports following an initialization event. Therefore, after a LIP [FC-AL-2], NL_Ports may wait for this notification to arrive, or they may perform an FLOGI.
FAN ELSはFabricによって初期化出来事に続いて、以前にNL_Portsに登録されていた状態で知られているすべてに送られるかもしれません。 したがって、LIP[FC AL2]の後に、NL_Portsが、この通知が到着するのを待つかもしれませんか、または彼らはFLOGIを実行するかもしれません。
If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI response exactly match the values before the LIP and if the AL_PA [FC-AL-2] obtained by the NL_Port is the same as the one before the LIP, then the port may resume all Exchanges. If not, then FLOGI must be performed with the Fabric and all logged in Nx_Ports must be logged out.
Port_NameとFabric_NameがFAN ELSかFLOGI応答に含んだF_がまさにLIPの前で値に合って、NL_Portによって得られたAL_PA[FC AL2]がLIPの前でものと同じであるなら、ポートはすべてのExchangesを再開するかもしれません。 そうでなければ、次に、Fabricと共にFLOGIを実行しなければなりません、そして、Nx_Portsに登録されたすべてをログアウトしなければなりません。
A public loop NL_Port must perform the private loop validation as specified in section B.3 to any NL_Port on the local loop that has an N_Port_ID of the form 0x00-00-XX.
公共の輪のNL_Portは0×00フォーム00-XXのN_Port_IDを持っている回線折返しのどんなNL_PortにもセクションB.3での指定されるとしての個人的な輪の合法化を実行しなければなりません。
B.5. FC Layer Address Validation in a Fabric Topology
B.5。 織物トポロジーでのFC層のアドレス合法化
No validation is required after LR (link reset).
合法化は全くLRの後に必要ではありません(リセットをリンクしてください)。
After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same as before the NOS/OLS, then the N_Port may resume all Exchanges. If not, all logged in Nx_Ports must be logged out [FC-FS].
NOS/OLSの後に、N_PortはFLOGIを実行しなければなりません。 F_のN_Port Nの_Port_ID、Port_Name、およびFabric_NameがFLOGIの後にNOS/OLSの前と同じであるなら、N_PortはすべてのExchangesを再開するかもしれません。 そうでなければ、Nx_Portsに登録されたすべてをログアウトしなければなりません[FC-FS]。
C. Fibre Channel Bit and Byte Numbering Guidance
C。 繊維チャンネルビットとバイト付番指導
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit numbering is different.
Fibre ChannelとIETF規格の両方が同じバイトトランスミッション命令を使用します。 しかしながら、噛み付いている付番は異なっています。
Fibre Channel bit numbering can be observed if the data structure heading shown in figure 21 is cut and pasted at the top of the figures present in this document.
21が中で計算するのが示されたデータ構造見出しがこのドキュメントに出席している数字の先端で切られて、貼られるなら、繊維Channelビット付番を観測できます。
3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 2 1 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 21: Fibre Channel Bit Numbering
図21: 繊維チャンネルビット付番
DeSanti Standards Track [Page 22] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[22ページ]。
Author's Address
作者のアドレス
Claudio DeSanti Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
クラウディオDeSantiシスコシステムズInc.170W.タスマンサンノゼ博士、カリフォルニア95134米国
Phone: +1 408 853-9172 EMail: cds@cisco.com
以下に電話をしてください。 +1 408 853-9172 メールしてください: cds@cisco.com
DeSanti Standards Track [Page 23] RFC 3831 IPv6 over Fibre Channel July 2004
DeSanti規格は繊維チャンネル2004年7月の間、RFC3831IPv6を追跡します[23ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
DeSanti Standards Track [Page 24]
DeSanti標準化過程[24ページ]
一覧
スポンサーリンク
