RFC4338 日本語訳
4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP)Packets over Fibre Channel. C. DeSanti, C. Carlson, R. Nixon. January 2006. (Format: TXT=75541 bytes) (Obsoletes RFC3831, RFC2625) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. DeSanti
Request for Comments: 4338 Cisco Systems
Obsoletes: 3831, 2625 C. Carlson
Category: Standards Track QLogic Corporation
R. Nixon
Emulex
January 2006
DeSantiがコメントのために要求するワーキンググループC.をネットワークでつないでください: 4338 シスコシステムズは以下を時代遅れにします。 3831、2625C.カールソンカテゴリ: 標準化過程QLogic社のR.ニクソンEmulex2006年1月
Transmission of IPv6, IPv4, and
Address Resolution Protocol (ARP) Packets over Fibre Channel
IPv6、IPv4、および繊維チャンネルの上のアドレス解決プロトコル(ARP)パケットのトランスミッション
Status of This 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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks.
このドキュメントはFibre Channelの上でプロトコル(ARP)パケットをIPv6、IPv4、およびAddress Resolutionにカプセルに入れる方法を指定します。 また、このドキュメントはFibre Channelネットワークの上のIPv4アドレス解決を実行するFibre Channelネットワークに関するIPv6のリンクローカルのアドレスと状態がない自動構成されたIPv6アドレス、およびメカニズムを形成するメソッドを指定します。
This document obsoletes RFC 2625 and RFC 3831.
このドキュメントはRFC2625とRFC3831を時代遅れにします。
DeSanti, et al. Standards Track [Page 1] RFC 4338 IP over Fibre Channel January 2006
DeSanti、他 規格は繊維チャンネル2006年1月の間、RFC4338IPを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Summary of Fibre Channel ........................................4
2.1. Overview ...................................................4
2.2. Identifiers and Login ......................................5
2.3. FC Levels and Frame Format .................................5
2.4. Sequences and Exchanges ....................................6
3. IP-capable Nx_Ports .............................................7
4. IPv6, IPv4, and ARP Encapsulation ...............................7
4.1. FC Sequence Format for IPv6 and IPv4 Packets ...............7
4.2. FC Sequence Format for ARP Packets .........................9
4.3. FC Classes of Service .....................................10
4.4. FC Header Code Points .....................................10
4.5. FC Network_Header .........................................11
4.6. LLC/SNAP Header ...........................................12
4.7. Bit and Byte Ordering .....................................12
4.8. Maximum Transfer Unit .....................................12
5. IPv6 Stateless Address Autoconfiguration .......................13
5.1. IPv6 Interface Identifier and Address Prefix ..............13
5.2. Generating an Interface ID from a Format 1 N_Port_Name ....14
5.3. Generating an Interface ID from a Format 2 N_Port_Name ....15
5.4. Generating an Interface ID from a Format 5 N_Port_Name ....16
5.5. Generating an Interface ID from an EUI-64 Mapped
N_Port_Name ...............................................17
6. Link-local Addresses ...........................................18
7. ARP Packet Format ..............................................18
8. Link-layer Address/Hardware Address ............................20
9. Address Mapping for Unicast ....................................20
9.1. Overview ..................................................20
9.2. IPv6 Address Mapping ......................................20
9.3. IPv4 Address Mapping ......................................21
10. Address Mapping for Multicast .................................22
11. Sequence Management ...........................................23
12. Exchange Management ...........................................23
13. Interoperability with RFC 2625 ................................24
14. Security Considerations .......................................25
15. IANA Considerations ...........................................25
16. Acknowledgements ..............................................25
17. Normative References ..........................................26
18. Informative References ........................................26
A. Transmission of a Broadcast FC Sequence over FC Topologies
(Informative) ..................................................28
B. Validation of the <N_Port_Name, N_Port_ID> Mapping
(Informative) ..................................................29
C. Fibre Channel Bit and Byte Numbering Guidance ..................30
D. Changes from RFC 2625 ..........................................31
E. Changes from RFC 3831 ..........................................31
1. 序論…3 2. 繊維チャンネルの概要…4 2.1. 概要…4 2.2. 識別子とログイン…5 2.3. FCレベルとフレーム形式…5 2.4. 系列と交換…6 3. IPできるNx_ポート…7 4. IPv6、IPv4、およびARPカプセル化…7 4.1. IPv6とIPv4パケットのためのFC系列形式…7 4.2. ARPパケットのためのFC系列形式…9 4.3. サービスのFCのクラス…10 4.4. FCヘッダーコードは指します…10 4.5. FCは_ヘッダーをネットワークでつなぎます…11 4.6. LLC/スナップヘッダー…12 4.7. ビットとバイト注文…12 4.8. 最大の移動単位数…12 5. IPv6の状態がないアドレス自動構成…13 5.1. IPv6は識別子とアドレス接頭語を連結します…13 5.2. _形式1NからインタフェースIDを生成して、_名前を移植してください…14 5.3. _形式2NからインタフェースIDを生成して、_名前を移植してください…15 5.4. _形式5NからインタフェースIDを生成して、_名前を移植してください…16 5.5. EUI-64からインタフェースIDを生成すると、ポート_が命名するN_は写像されました…17 6. リンクローカルのアドレス…18 7. ARPパケット・フォーマット…18 8. リンクレイヤアドレス/ハードウェア・アドレス…20 9. ユニキャストのためにマッピングを扱ってください…20 9.1. 概要…20 9.2. IPv6はマッピングを扱います…20 9.3. IPv4はマッピングを扱います…21 10. マルチキャストのためにマッピングを扱ってください…22 11. 系列管理…23 12. 管理を交換してください…23 13. RFC2625がある相互運用性…24 14. セキュリティ問題…25 15. IANA問題…25 16. 承認…25 17. 標準の参照…26 18. 有益な参照…26 FC Topologies(有益な)の上の放送FC系列のA.送信…28 <N_ポート_名のB.合法化、N_ポート_ID>マッピング(有益な)…指導に付番する29C.繊維チャンネルビットとバイト…30 D.はRFC2625から変化します…31 E.はRFC3831から変化します…31
DeSanti, et al. Standards Track [Page 2] RFC 4338 IP over Fibre Channel January 2006
DeSanti、他 規格は繊維チャンネル2006年1月の間、RFC4338IPを追跡します[2ページ]。
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), IPv6 [IPv6], and IPv4 [IPv4].
繊維Channel(FC)はSmallコンピュータSystem Interface(SCSI)、IPv6[IPv6]、およびIPv4[IPv4]を含むいくつかのUpper Layerプロトコルをサポートする高速シリアルインタフェース技術です。
[RFC-2625] defined how to encapsulate IPv4 and Address Resolution Protocol (ARP) packets over Fibre Channel for a subset of Fibre Channel devices. This specification enables the support of IPv4 for a broader category of Fibre Channel devices. In addition, this specification simplifies [RFC-2625] by removing unused options and clarifying current implementations. This document obsoletes [RFC-2625].
[RFC-2625]はFibre Channelデバイスの部分集合のためにFibre Channelの上でIPv4とAddress Resolutionがプロトコル(ARP)パケットであるとカプセル化する方法を定義しました。 この仕様はFibre Channelデバイスの、より広いカテゴリのためにIPv4のサポートを可能にします。 さらに、この仕様は、未使用のオプションを取り除いて、現在の実装をはっきりさせることによって、[RFC-2625]を簡素化します。 このドキュメントは[RFC-2625]を時代遅れにします。
Specific [RFC-2625] limitations that this document aims to resolve are the following:
このドキュメントが決議することを目指す特定の[RFC-2625]制限は以下です:
- N_Port_Name format restriction. [RFC-2625] restricts the use of
IPv4 to Fibre Channel devices having the format 0x1 N_Port_Name,
but many current implementations use other N_Port_Name formats.
- N_ポート_Name形式制限。 [RFC-2625]はIPv4の使用を現在の実装使用他のN_Port_Nameがフォーマットする形式0x1N_Port_Nameにもかかわらず、多くを持っているFibre Channelデバイスに制限します。
- Use of Fibre Channel Address Resolution Protocol (FARP).
[RFC-2625] requires the support of FARP to map N_Port_Names to
N_Port_IDs, but many current implementations use other methods,
such as the Fibre Channel Name Server.
- 繊維チャンネル・アドレス解決プロトコル(FARP)の使用。 [RFC-2625]はN_Port_NamesをN_Port_IDに写像するためにFARPのサポートを必要としますが、多くの現在の実装が他のメソッドを使用します、Fibre Channel Name Serverなどのように。
- Missing support for IPv4 multicast. [RFC-2625] does not specify
how to transmit IPv4 packets with a multicast destination address
over Fibre Channel.
- IPv4マルチキャストのサポートを逃します。 [RFC-2625]はFibre Channelの上にマルチキャスト送付先アドレスがある状態でIPv4パケットを伝える方法を指定しません。
[RFC-3831] defines how to encapsulate IPv6 over Fibre Channel and a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured IPv6 addresses on Fibre Channel networks. [RFC-3831] 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. This document obsoletes [RFC-3831].
[AARCH]と状態がない自動構成されたIPv6がFibre Channelネットワークに関するアドレスであると[RFC-3831]はFibre Channelの上でIPv6をカプセル化する方法を定義して、リンク地方でIPv6を形成するメソッドは、扱います。 また、メッセージがFibre Channelネットワークで送られるとき、[RFC-3831]はオプションがNeighborディスカバリー[DISC]で使用したSource/目標Address Link-層の内容について説明します。 このドキュメントは[RFC-3831]を時代遅れにします。
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, et al. Standards Track [Page 3] RFC 4338 IP over Fibre Channel January 2006
DeSanti、他 規格は繊維チャンネル2006年1月の間、RFC4338IPを追跡します[3ページ]。
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)はストレージネットワークに主として使用されるギガビット速度ネットワーク技術です。 繊維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 that does not operate in a loop topology is called an N_Port. A Node Port that operates in a loop topology using the loop-specific protocols is designated as an NL_Port. The term Nx_Port is used to indicate a Node Port that is capable of operating in either mode.
輪のトポロジーで作動しないNode PortはN_Portと呼ばれます。 輪のトポロジーで輪の特有のプロトコルを使用することで作動するNode PortはNL_Portとして指定されます。 Nx_Portという用語は、モードで作動できるNode Portを示すのに使用されます。
A Fabric Port that does not operate in a loop topology is called an F_Port. A Fabric Port that operates in a loop topology using the loop-specific protocols is designated as an FL_Port. The term Fx_Port is used to indicate a Fabric Port that is capable of operating in either mode.
輪のトポロジーで作動しないFabric PortはF_Portと呼ばれます。 輪のトポロジーで輪の特有のプロトコルを使用することで作動するFabric Portはフロリダ_Portとして指定されます。 Fx_Portという用語は、モードで作動できるFabric Portを示すのに使用されます。
A Fibre Channel network, built with any combination of the FC topologies described above, is a multiaccess network with broadcast capabilities.
FC topologiesのどんな組み合わせも上で説明されている状態で造られたFibre Channelネットワークは放送能力がある多重処理ネットワークです。
From an IPv6 point of view, a Fibre Channel network is an IPv6 Link [IPv6]. IP-capable Nx_Ports are what [IPv6] calls Interfaces.
IPv6観点から、Fibre ChannelネットワークはIPv6 Link[IPv6]です。 IPできるNx_Portsは[IPv6]がInterfacesと呼ぶものです。
From an IPv4 point of view, a Fibre Channel network is an IPv4 Local Network [IPv4]. IP-capable Nx_Ports are what [IPv4] calls Local Network Interfaces.
IPv4観点から、Fibre ChannelネットワークはIPv4 Local Network[IPv4]です。 IPできるNx_Portsは[IPv4]がLocal Network Interfacesと呼ぶものです。
DeSanti, et al. Standards Track [Page 4] RFC 4338 IP over Fibre Channel January 2006
DeSanti、他 規格は繊維チャンネル2006年1月の間、RFC4338IPを追跡します[4ページ]。
2.2. Identifiers and Login
2.2. 識別子とログイン
Fibre Channel entities are identified by non-volatile 64-bit Name_Identifiers. [FC-FS] defines several formats of Name_Identifiers. The value of the most significant 4 bits defines the format of a Name_Identifier. These Name_Identifiers are referred to in a more concise manner as follows:
繊維Channel実体は非揮発性の64ビットのName_Identifiersによって特定されます。 [FC-FS]はName_Identifiersのいくつかの書式を定義します。 最も重要な4ビットの価値はName_Identifierの書式を定義します。 以下のより簡潔な方法でこれらのName_Identifiersは言及されます:
- 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と呼ばれます。
An Nx_Port connected to a Fibre Channel network is associated with two identifiers, its non-volatile N_Port_Name and a volatile 24-bit address called N_Port_ID. The N_Port_Name is used to identify the Nx_Port, and the N_Port_ID is used for communications among Nx_Ports.
Fibre Channelネットワークに接続されたNx_Portは2つの識別子、_NameとN_と呼ばれる揮発性の24ビットのアドレスの非揮発性のN_Port 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 ELSes) or implicit (i.e., in which the parameters are specified by configuration or other methods).
Fabric LoginとPort Loginの両方が、明白であるか(すなわち、Extended Link Services、またはELSesと呼ばれる特定のFCコントロールメッセージを使用することで、実行されます)、または内在しているかもしれません(すなわち、パラメタはそこで構成か他のメソッドで指定されます)。
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 the control functions necessary for information transfer. The FC-4 level supports Upper Level Protocols, such as IPv6, IPv4, and SCSI. The Fibre Channel frame format is shown in figure 1.
[FC-FS]は、5つの異なったレベルを使用することでFibre Channelプロトコルについて説明します。 この仕様において、FC-2とFC-4レベルは関連しています。 FC-2レベルは情報転送に必要なFCフレーム形式、輸送サービス、およびコントロール機能を定義します。 FC-4レベルはIPv6や、IPv4や、SCSIなどのプロトコルをUpper Levelにサポートします。 フレーム形式が示されるFibre Channelは1について計算します。
DeSanti, et al. Standards Track [Page 5] RFC 4338 IP over Fibre Channel January 2006
DeSanti、他 規格は繊維チャンネル2006年1月の間、RFC4338IPを追跡します[5ページ]。
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
+-----+-----------+-----------+--------//-------+-----+-----+ | | | データ・フィールド| | | | SOF| FCヘッダー| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| CRC| EOF| | | | 任意| フレーム| | | | | | ヘッダー| 有効搭載量| | | +-----+-----------+-----------+--------//-------+-----+-----+
Figure 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 Cyclic Redundancy Check (CRC) is 4 octets long and is used to verify the integrity of a frame.
FrameのStart(SOF)とFrameのEnd(EOF)はフレームデリミタとして機能する特別なFCトランスミッション単語です。 Cyclic Redundancy Check(CRC)は、長い間の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 the following:
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: ひたむきな接続を通した信頼できるマルチキャスト。
Classes 3 and 2 are commonly used for storage networking applications; Classes 1 and 6 are typically used for specialized applications in avionics. Class 3 is recommended for IPv6, IPv4, and ARP (see section 4.3).
クラス3と2はストレージネットワークアプリケーションに一般的に使用されます。 クラス1と6は航空電子工学における専門化しているアプリケーションに通常使用されます。 クラス3はIPv6、IPv4、およびARPのために推薦されます(セクション4.3を見てください)。
2.4. Sequences and Exchanges
2.4. 系列と交換
An application-level payload such as an IPv6 or IPv4 packet is called an Information Unit at the FC-4 level of Fibre Channel. Each FC-4
IPv6かIPv4パケットなどのアプリケーションレベルペイロードはFibre ChannelのFC-4レベルで情報Unitと呼ばれます。 各FC-4
DeSanti, et al. Standards Track [Page 6] RFC 4338 IP over Fibre Channel January 2006
DeSanti、他 規格は繊維チャンネル2006年1月の間、RFC4338IPを追跡します[6ページ]。
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.
情報UnitはFC-2レベルによってFC Sequenceに写像されます。 FC SequenceはFC HeaderのSequence_ID(SEQ_ID)分野の値によって関係づけられた1個以上のFCフレームから成ります。
The architectural 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 grouped 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 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 between a pair of Nx_Ports.
複数のSequencesが同じFC Exchangeに属すとして一緒に分類されるかもしれません。 Exchangeは彼らの間の操作を特定して、管理するのに2Nx_Portsによって使用されたメカニズムです。 操作が終わるとき、Exchangeは操業が2Nx_Portsで開始されるとき、開かれて、閉じられます。 同じExchangeに属すFCフレームがFC HeaderのExchange_ID分野の値によって関係づけられます。 Originator Exchange_ID(OX_ID)とResponder Exchange_ID(RX_ID)は唯一1組のNx_Portsの間のExchangeを特定します。
3. IP-capable Nx_Ports
3. IPできるNx_ポート
This specification requires an IP-capable Nx_Port to have the following properties:
この仕様は、IPできるNx_Portには以下の特性があるのを必要とします:
- The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
0xD, 0xE, 0xF (see section 5.1);
- 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 (see section 4.1);
- It SHOULD support a receive data field size for Device_Data FC
frames of at least 1024 octets (see section 10).
- N_Port_Nameの形式は0×1の1つ、0×2、0×5、0xC、0xD、0xE、0xFであるに違いありません(セクション5.1を見てください)。 - それはClass3をサポートしなければなりません。 - それは、増加するSEQ_がCNT[FC-FS]であると絶え間なくサポートしなければなりません。 - それは長い間、FC-4情報Unit少なくとも1304八重奏を送受信できなければなりません(セクション4.1を見てください)。 - それ、SHOULDは、受信データ分野がサイズであると少なくとも1024の八重奏のDevice_Data FCフレームにサポートします(セクション10を見てください)。
4. IPv6, IPv4, and ARP Encapsulation
4. IPv6、IPv4、およびARPカプセル化
4.1. FC Sequence Format for IPv6 and IPv4 Packets
4.1. IPv6とIPv4パケットのためのFC系列形式
An IPv6 or IPv4 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 [FC-FS]. An FC Information Unit containing an IP packet MUST carry the FC Network_Header [FC-FS] and the Logical Link Control/SubNetwork Access Protocol (LLC/SNAP) header [IEEE-LLC], resulting in the FC Information Unit format shown in figure 2.
IPv6かIPv4パケットがFibre ChannelのFC-4レベルで情報Unitに写像されます。(FC-2レベル[FC-FS]によってFibre Channelは順番にFC Sequenceに写像されます)。 IPパケットを含むFC情報UnitはFC Network_Header[FC-FS]とLogical Link Control/SubNetwork Accessプロトコル(LLC/SNAP)ヘッダー[IEEE-LLC]を運ばなければなりません、2が中で計算するのが示されたFC情報Unit書式をもたらして。
DeSanti, et al. Standards Track [Page 7] RFC 4338 IP over Fibre Channel January 2006
DeSanti、他 規格は繊維チャンネル2006年1月の間、RFC4338IPを追跡します[7ページ]。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 or IPv4 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ | | +- -+ | ネットワーク_ヘッダー| +(16の八重奏) -+| | +- -+ | | +---------------+---------------+---------------+---------------+ | LLC/SNAPヘッダー| +(8つの八重奏) -+| | +---------------+---------------+---------------+---------------+ | | +-+/IPv6かIPv4パケット///+-+| | +---------------+---------------+---------------+---------------+
Figure 2: FC Information Unit Mapping an IP Packet
図2: IPパケットを写像するFC情報ユニット
In order to support the minimum IPv6 MTU (i.e., 1280 octets), an Nx_Port supporting IP MUST be able to transmit and receive an FC-4 Information Unit at least 1304 octets long (i.e., 1280 + 8 + 16).
最小のIPv6 MTU(すなわち、1280の八重奏)をサポートするために、IPをサポートするNx_Portは長い間(すなわち、1280+8+16)、FC-4情報Unit少なくとも1304八重奏を送受信できなければなりません。
The FC ESP_Header [FC-FS] MAY be used to secure the FC frames composing an IP FC Sequence. Other FC Optional Headers MUST NOT be used in an IP FC Sequence.
FC ESP_Header[FC-FS]は、IP FC Sequenceを構成するFCフレームを固定するのに使用されるかもしれません。 IP FC Sequenceで他のFC Optional Headersを使用してはいけません。
An IP FC Sequence often consists of more than one frame, all frames having the same TYPE (see section 4.4). 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 shown in figure 3.
IP FC Sequenceは1個以上のフレーム、同じTYPEを持っているすべてのフレームからしばしば成ります(セクション4.4を見てください)。 Sequenceの最初のフレームはFC Network_HeaderとLLC/SNAPヘッダーを含まなければなりません。 3が中で計算するのが示されるように他のフレームはそれらを含んではいけません。
First Frame of an IP FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IP Packet |
+-----------+-------------------+-----------------+-------//--------+
IP FC系列+の最初のフレーム-----------+-------------------+-----------------+-------//--------+ | FCヘッダー| FCネットワーク_ヘッダー| LLC/SNAPヘッダー| 最初の塊| | | | | IPパケット| +-----------+-------------------+-----------------+-------//--------+
Subsequent Frames of an IP FC Sequence
+-----------+-----------------//--------------------+
| FC Header | Additional chunk of the IP Packet |
+-----------+----------------//---------------------+
IP FC系列+のその後のフレーム-----------+-----------------//--------------------+ | FCヘッダー| IP Packetの追加塊| +-----------+----------------//---------------------+
Figure 3: Optional Headers in an IP FC Sequence
図3: IP FC系列の任意のヘッダー
DeSanti, et al. Standards Track [Page 8] RFC 4338 IP over Fibre Channel January 2006
DeSanti、他 規格は繊維チャンネル2006年1月の間、RFC4338IPを追跡します[8ページ]。
4.2. FC Sequence Format for ARP Packets
4.2. ARPパケットのためのFC系列形式
An ARP 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 ARP packet MUST carry the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], resulting in the FC Information Unit format shown in figure 4.
ARPパケットはFibre ChannelのFC-4レベルで情報Unitに写像されます。(Fibre ChannelはFC-2レベルによって順番にFC Sequenceに写像されます)。 ARPパケットを含むFC情報UnitはFC Network_Header[FC-FS]とLLC/SNAPヘッダー[IEEE-LLC]を運ばなければなりません、4が中で計算するのが示されたFC情報Unit書式をもたらして。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ ARP Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ | | +- -+ | ネットワーク_ヘッダー| +(16の八重奏) -+| | +- -+ | | +---------------+---------------+---------------+---------------+ | LLC/SNAPヘッダー| +(8つの八重奏) -+| | +---------------+---------------+---------------+---------------+ | | +-+/ARPパケット///+ -+| | +---------------+---------------+---------------+---------------+
Figure 4: FC Information Unit Mapping an ARP Packet
図4: ARPパケットを写像するFC情報ユニット
Given the limited size of an ARP packet (see section 7), an FC Sequence carrying an ARP packet MUST be mapped to a single FC frame that MUST include the FC Network_Header and the LLC/SNAP header.
ARPパケット(セクション7を見る)の限られたサイズを考えて、FC Network_HeaderとLLC/SNAPヘッダーを含まなければならない単一のFCフレームにARPパケットを運ぶFC Sequenceを写像しなければなりません。
The FC ESP_Header [FC-FS] MAY be used to secure an FC frame carrying an ARP packet. Other FC Optional Headers MUST NOT be used in an FC frame carrying an ARP packet.
FC ESP_Header[FC-FS]は、ARPパケットを運ぶFCフレームを固定するのに使用されるかもしれません。 ARPパケットを運びながら、FCフレームで他のFC Optional Headersを使用してはいけません。
DeSanti, et al. Standards Track [Page 9] RFC 4338 IP over Fibre Channel January 2006
DeSanti、他 規格は繊維チャンネル2006年1月の間、RFC4338IPを追跡します[9ページ]。
4.3. FC Classes of Service
4.3. サービスのFCのクラス
This specification uses FC Class 3. The following types of packets MUST be mapped in Class 3 FC frames:
この仕様はFC Class3を使用します。 Class3FCフレームで以下のタイプのパケットを写像しなければなりません:
- multicast IPv6 packets;
- multicast/broadcast IPv4 packets;
- Control Protocol packets (e.g., ARP packets; IPv6 packets carrying
ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener
Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or
IGMP [IGMPv3] messages; IPv6 and IPv4 Routing Protocols packets).
- マルチキャストIPv6パケット。 - マルチキャスト/放送IPv4パケット。 - プロトコルパケット(例えば、ARPパケット; ICMPv6を運ぶIPv6パケット[ICMPv6]、Neighborディスカバリー[DISC]、またはMulticast Listenerディスカバリーメッセージ; ICMP[ICMPv4]かIGMP[IGMPv3]メッセージを伝えるIPv4パケット; IPv6とIPv4ルート設定プロトコルパケット[MLDv2])を制御してください。
Other IPv6 and IPv4 packets (i.e., unicast IP packets carrying data traffic) SHOULD be mapped in Class 3 FC frames as well. Support for reception of IPv4 or IPv6 packets mapped in FC frames of any Class other than Class 3 is OPTIONAL; receivers MAY ignore them.
他のIPv6とIPv4パケット、(すなわち、Class3FCが縁どる写像しているコネが同じくらい良かったならデータ通信量) SHOULDを運ぶユニキャストIPパケット。 Class3以外のどんなClassのFCフレームでも写像されたIPv4かIPv6パケットのレセプションのサポートはOPTIONALです。 受信機はそれらを無視するかもしれません。
4.4. FC Header Code Points
4.4. FCヘッダーコード・ポイント
The fields of the Fibre Channel Header are shown in figure 5. The D_ID and S_ID fields contain, respectively, the destination N_Port_ID and the source N_Port_ID.
Fibre Channel Headerの分野は5が中で計算するのが示されます。 D_IDとS_ID分野はそれぞれ目的地N_Port_IDとソース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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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| +---------------+---------------+---------------+---------------+ | パラメタ| +---------------+---------------+---------------+---------------+
Figure 5: FC Header Format
図5: FCヘッダー形式
To encapsulate IPv6 and IPv4 over Fibre Channel, the following code points apply. When a single value is listed without further qualification, that value MUST be used:
Fibre Channelの上でIPv6とIPv4をカプセル化するために、以下のコード・ポイントは申し込まれます。 ただ一つの値がさらなる資格なしで記載されているとき、その値を使用しなければなりません:
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [FC-FS]);
- TYPE: 0x05 (IP over Fibre Channel);
- _R CTL: 0×04 (Unsolicited Data情報Category[FC-FS]があるデバイス_Dataフレーム)。 - 以下をタイプしてください。 0×05(繊維チャンネルの上のIP)。
DeSanti, et al. Standards Track [Page 10] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 10] RFC 4338 IP over Fibre Channel January 2006
- CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values;
- DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 or
IPv4 Sequence, 0x00 for the following FC frames. If the FC
ESP_Header is used, then 0x60 for the first FC frame of an IPv6 or
IPv4 Sequence, 0x40 for the following FC frames;
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12,
and [FC-FS] for additional requirements;
- Parameter: if Relative Offset [FC-FS] is not used, the content of
this field MUST be ignored by the receiver, and SHOULD be set to
zero by the sender. If Relative Offset is used, see [FC-FS].
- CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values; - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 or IPv4 Sequence, 0x00 for the following FC frames. If the FC ESP_Header is used, then 0x60 for the first FC frame of an IPv6 or IPv4 Sequence, 0x40 for the following FC frames; - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12, and [FC-FS] for additional requirements; - Parameter: if Relative Offset [FC-FS] is not used, the content of this field MUST be ignored by the receiver, and SHOULD be set to zero by the sender. If Relative Offset is used, see [FC-FS].
To encapsulate ARP over Fibre Channel, the following code points apply. When a single value is listed without further qualification, that value MUST be used:
To encapsulate ARP over Fibre Channel, the following code points apply. When a single value is listed without further qualification, that value MUST be used:
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [FC-FS]);
- TYPE: 0x05 (IP over Fibre Channel);
- CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values;
- DF_CTL: 0x20 (Network_Header). If the FC ESP_Header is used, then
0x60;
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12,
and [FC-FS] for additional requirements;
- Parameter: SHOULD be set to zero.
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information Category [FC-FS]); - TYPE: 0x05 (IP over Fibre Channel); - CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values; - DF_CTL: 0x20 (Network_Header). If the FC ESP_Header is used, then 0x60; - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12, and [FC-FS] for additional requirements; - Parameter: SHOULD be set to zero.
4.5. FC Network_Header
4.5. FC Network_Header
The fields of the FC Network_Header are shown in figure 6. For use with IPv6, IPv4, and ARP, the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF [FC-FS].
The fields of the FC Network_Header are shown in figure 6. For use with IPv6, IPv4, and ARP, the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF [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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- Destination N_Port_Name -+ | | +---------------------------------------------------------------+ | | +- Source N_Port_Name -+ | | +---------------------------------------------------------------+
Figure 6: FC Network_Header Format
Figure 6: FC Network_Header Format
DeSanti, et al. Standards Track [Page 11] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 11] RFC 4338 IP over Fibre Channel January 2006
4.6. LLC/SNAP Header
4.6. LLC/SNAP Header
The fields of the LLC/SNAP header [IEEE-LLC] are shown in figure 7.
The fields of the LLC/SNAP header [IEEE-LLC] are shown in figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | +---------------+---------------+---------------+---------------+
Figure 7: LLC/SNAP Header Format
Figure 7: LLC/SNAP Header Format
To encapsulate IPv6, IPv4, and ARP over Fibre Channel, the following code points MUST be used:
To encapsulate IPv6, IPv4, and ARP over Fibre Channel, the following code points MUST be used:
- DSAP: 0xAA; - SSAP: 0xAA; - CTRL: 0x03; - OUI: 0x000000; - PID: 0x86DD for IPv6, 0x0800 for IPv4, 0x0806 for ARP.
- DSAP: 0xAA; - SSAP: 0xAA; - CTRL: 0x03; - OUI: 0x000000; - PID: 0x86DD for IPv6, 0x0800 for IPv4, 0x0806 for ARP.
4.7. Bit and Byte Ordering
4.7. Bit and Byte Ordering
IPv6, IPv4, and ARP 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, IPv4, and ARP 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.
4.8. Maximum Transfer Unit
4.8. Maximum Transfer Unit
The default MTU size for IPv6 packets over Fibre Channel is 65280 octets. Large IPv6 packets are mapped to a Sequence of FC frames (see section 2.4). 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.
The default MTU size for IPv6 packets over Fibre Channel is 65280 octets. Large IPv6 packets are mapped to a Sequence of FC frames (see section 2.4). 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.
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 [PMTUD6], or at least maintain different MTU values for on-link and off-link destinations.
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 [PMTUD6], or at least maintain different MTU values for on-link and off-link destinations.
DeSanti, et al. Standards Track [Page 12] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 12] RFC 4338 IP over Fibre Channel January 2006
For correct operation of IPv6 in a routed environment, it is critically important to configure an appropriate MTU option in Router Advertisements.
For correct operation of IPv6 in a routed environment, it is critically important to configure an appropriate MTU option in Router Advertisements.
For correct operation of IPv6 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 that is connected to a medium with a default MTU larger than the smallest MTU.
For correct operation of IPv6 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 that is connected to a medium with a default MTU larger than the smallest MTU.
The default MTU size for IPv4 packets over Fibre Channel is 65280 octets. Large IPv4 packets are mapped to a Sequence of FC frames (see section 2.4). This size may be reduced by manual configuration of each Nx_Port or by the Path MTU Discovery technique [PMTUD4].
The default MTU size for IPv4 packets over Fibre Channel is 65280 octets. Large IPv4 packets are mapped to a Sequence of FC frames (see section 2.4). This size may be reduced by manual configuration of each Nx_Port or by the Path MTU Discovery technique [PMTUD4].
5. IPv6 Stateless Address Autoconfiguration
5. IPv6 Stateless Address Autoconfiguration
5.1. IPv6 Interface Identifier and Address Prefix
5.1. IPv6 Interface Identifier and Address Prefix
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 (U/L) bit of the OUI field of the derived EUI-64 address. The U/L bit has no function in Fibre Channel; however, it has to be properly handled when a Name_Identifier is converted to an EUI-64 address.
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 (U/L) bit of the OUI field of the derived EUI-64 address. The U/L bit has no function in Fibre Channel; however, it has to be properly handled when a Name_Identifier is converted to an EUI-64 address.
[FC-FS] specifies a method to map format 0x1 (IEEE 48-bit address), 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] specifies a method to map format 0x1 (IEEE 48-bit address), 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.
IPv6 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.
IPv6 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.
DeSanti, et al. Standards Track [Page 13] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 13] RFC 4338 IP over Fibre Channel January 2006
5.2. Generating an Interface ID from a Format 1 N_Port_Name
5.2. Generating an Interface ID from a Format 1 N_Port_Name
The Name_Identifier format 0x1 is shown in figure 8.
The Name_Identifier format 0x1 is shown in figure 8.
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| 0x000 | OUI | +-------+-------+---------------+---------------+---------------+ | OUI | VSID | +---------------+---------------+---------------+---------------+
Figure 8: Format 0x1 Name_Identifier
Figure 8: Format 0x1 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format shown in figure 9 [FC-FS].
The EUI-64 address derived from this Name_Identifier has the format shown in figure 9 [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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI with complemented U/L bit |0 0 0 1| VSID | +---------------+---------------+-------+-------+-------+-------+ | VSID | 0x000 | +---------------+---------------+-------+-------+---------------+
Figure 9: EUI-64 Address from a Format 0x1 Name_Identifier
Figure 9: EUI-64 Address from a Format 0x1 Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. Therefore, 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 shown in figure 10.
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. Therefore, 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 shown in figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | 0x000 | +---------------+---------------+-------+-------+---------------+
Figure 10: IPv6 Interface ID from a Format 0x1 Name_Identifier
Figure 10: IPv6 Interface ID from a Format 0x1 Name_Identifier
As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:461A:BCDE:F000.
As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:461A:BCDE:F000.
DeSanti, et al. Standards Track [Page 14] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 14] RFC 4338 IP over Fibre Channel January 2006
5.3. Generating an Interface ID from a Format 2 N_Port_Name
5.3. Generating an Interface ID from a Format 2 N_Port_Name
The Name_Identifier format 0x2 is shown in figure 11.
The Name_Identifier format 0x2 is shown in figure 11.
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| Vendor Specific | OUI | +-------+-------+---------------+---------------+---------------+ | OUI | VSID | +---------------+---------------+---------------+---------------+
Figure 11: Format 0x2 Name_Identifier
Figure 11: Format 0x2 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format shown in figure 12 [FC-FS].
The EUI-64 address derived from this Name_Identifier has the format shown in figure 12 [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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI with complemented U/L bit |0 0 1 0| VSID | +---------------+-----------------------+-------+-------+-------+ | VSID | Vendor Specific | +---------------+-----------------------+-------+---------------+
Figure 12: EUI-64 Address from a Format 0x2 Name_Identifier
Figure 12: EUI-64 Address from a Format 0x2 Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. Therefore, 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 shown in figure 13.
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. Therefore, 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 shown in figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | Vendor Specific | +---------------+-----------------------+-------+---------------+
Figure 13: IPv6 Interface ID from a Format 0x2 Name_Identifier
Figure 13: IPv6 Interface ID from a Format 0x2 Name_Identifier
As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:462A:BCDE:F789.
As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:462A:BCDE:F789.
DeSanti, et al. Standards Track [Page 15] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 15] RFC 4338 IP over Fibre Channel January 2006
5.4. Generating an Interface ID from a Format 5 N_Port_Name
5.4. Generating an Interface ID from a Format 5 N_Port_Name
The Name_Identifier format 0x5 is shown in figure 14.
The Name_Identifier format 0x5 is shown in figure 14.
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 | +---------------+---------------+---------------+---------------+
Figure 14: Format 0x5 Name_Identifier
Figure 14: Format 0x5 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format shown in figure 15 [FC-FS].
The EUI-64 address derived from this Name_Identifier has the format shown in figure 15 [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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI with complemented U/L bit |0 1 0 1| VSID | +---------------+---------------+---------------+-------+-------+ | VSID | +---------------+---------------+---------------+---------------+
Figure 15: EUI-64 Address from a Format 0x5 Name_Identifier
Figure 15: EUI-64 Address from a Format 0x5 Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address complementing the U/L bit in the OUI field. Therefore, 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 shown in figure 16.
The IPv6 Interface Identifier is obtained from this EUI-64 address complementing the U/L bit in the OUI field. Therefore, 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 shown in figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | +---------------+---------------+---------------+---------------+
Figure 16: IPv6 Interface ID from a Format 0x5 Name_Identifier
Figure 16: IPv6 Interface ID from a Format 0x5 Name_Identifier
As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789.
As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789.
DeSanti, et al. Standards Track [Page 16] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 16] RFC 4338 IP over Fibre Channel January 2006
5.5. Generating an Interface ID from an EUI-64 Mapped N_Port_Name
5.5. Generating an Interface ID from an EUI-64 Mapped 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 the Universal/Local and Individual/Group bits from the OUI, 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 17.
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 the Universal/Local and Individual/Group bits from the OUI, 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 | +---------------+---------------+---------------+---------------+
Figure 17: EUI-64 Mapped Name_Identifiers Format
Figure 17: EUI-64 Mapped Name_Identifiers Format
The EUI-64 address used to generate the Name_Identifier shown in figure 17 has the format shown in figure 18.
The EUI-64 address used to generate the Name_Identifier shown in figure 17 has the format shown in figure 18.
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 | +---------------+---------------+---------------+---------------+
Figure 18: EUI-64 Address from an EUI-64 Mapped Name_Identifier
Figure 18: EUI-64 Address from an EUI-64 Mapped Name_Identifier
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 shown in figure 19.
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 shown in figure 19.
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 | +---------------+---------------+---------------+---------------+
Figure 19: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier
Figure 19: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier
DeSanti, et al. Standards Track [Page 17] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 17] RFC 4338 IP over Fibre Channel January 2006
As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A generates the IPv6 Interface Identifier 3663:46AB:0125:789A.
As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A generates the IPv6 Interface Identifier 3663:46AB:0125:789A.
6. Link-local Addresses
6. Link-local Addresses
The IPv6 link-local address [AARCH] for an Nx_Port is formed by appending the Interface Identifier (as defined in section 5) to the prefix FE80::/64. The resulting address is shown in figure 20.
The IPv6 link-local address [AARCH] for an Nx_Port is formed by appending the Interface Identifier (as defined in section 5) to the prefix FE80::/64. The resulting address is shown in figure 20.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+
Figure 20: IPv6 Link-local Address Format
Figure 20: IPv6 Link-local Address Format
7. ARP Packet Format
7. ARP Packet Format
The Address Resolution Protocol defined in [ARP] is designed to be a general purpose protocol, to accommodate many network technologies and many Upper Layer Protocols.
The Address Resolution Protocol defined in [ARP] is designed to be a general purpose protocol, to accommodate many network technologies and many Upper Layer Protocols.
[RFC-2625] chose to use for Fibre Channel the same ARP packet format used for Ethernet networks. In order to do that, [RFC-2625] restricted the use of IPv4 to Nx_Ports having N_Port_Name format 0x1. Although this may have been a reasonable choice at that time, today there are Nx_Ports with an N_Port_Name format other than 0x1 in widespread use.
[RFC-2625] chose to use for Fibre Channel the same ARP packet format used for Ethernet networks. In order to do that, [RFC-2625] restricted the use of IPv4 to Nx_Ports having N_Port_Name format 0x1. Although this may have been a reasonable choice at that time, today there are Nx_Ports with an N_Port_Name format other than 0x1 in widespread use.
This specification accommodates Nx_Ports with N_Port_Names of a format different from 0x1 by defining a Fibre Channel specific version of the ARP protocol (FC ARP), carrying both N_Port_Name and N_Port_ID as Hardware (HW) Address.
This specification accommodates Nx_Ports with N_Port_Names of a format different from 0x1 by defining a Fibre Channel specific version of the ARP protocol (FC ARP), carrying both N_Port_Name and N_Port_ID as Hardware (HW) Address.
IANA has registered the number 18 (decimal) to identify Fibre Channel as ARP HW type. The FC ARP packet format is shown in figure 21. The length of the FC ARP packet is 40 octets.
IANA has registered the number 18 (decimal) to identify Fibre Channel as ARP HW type. The FC ARP packet format is shown in figure 21. The length of the FC ARP packet is 40 octets.
DeSanti, et al. Standards Track [Page 18] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 18] RFC 4338 IP over Fibre Channel January 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Type = 0x0012 | Protocol = 0x0800 |
+---------------+---------------+---------------+---------------+
| HW Len = 12 | Proto Len = 4 | Opcode |
+---------------+---------------+---------------+---------------+
| |
+- -+
| HW Address of Sender |
+- -+
| |
+---------------+---------------+---------------+---------------+
| Protocol Address of Sender |
+---------------+---------------+---------------+---------------+
| |
+- -+
| HW Address of Target |
+- -+
| |
+---------------+---------------+---------------+---------------+
| Protocol Address of Target |
+---------------+---------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HW Type = 0x0012 | Protocol = 0x0800 | +---------------+---------------+---------------+---------------+ | HW Len = 12 | Proto Len = 4 | Opcode | +---------------+---------------+---------------+---------------+ | | +- -+ | HW Address of Sender | +- -+ | | +---------------+---------------+---------------+---------------+ | Protocol Address of Sender | +---------------+---------------+---------------+---------------+ | | +- -+ | HW Address of Target | +- -+ | | +---------------+---------------+---------------+---------------+ | Protocol Address of Target | +---------------+---------------+---------------+---------------+
Figure 21: FC ARP Packet Format
Figure 21: FC ARP Packet Format
The following code points MUST be used with FC ARP:
The following code points MUST be used with FC ARP:
- HW Type: 0x0012 (Fibre Channel);
- Protocol: 0x0800 (IPv4);
- HW Len: 12 (Length in octets of the HW Address);
- Proto Len: 4 (Length in octets of the Protocol Address);
- Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply [ARP];
- HW Address of Sender: the HW Address (see section 8) of the
Requester in an ARP Request, or the HW Address of the Responder in
an ARP Reply;
- Protocol Address of Sender: the IPv4 address of the Requester in
an ARP Request, or that of the Responder in an ARP Reply;
- HW Address of Target: set to zero in an ARP Request, and to the HW
Address (see section 8) of the Requester in an ARP Reply;
- Protocol Address of Target: the IPv4 address of the Responder in
an ARP Request, or that of the Requester in an ARP Reply.
- HW Type: 0x0012 (Fibre Channel); - Protocol: 0x0800 (IPv4); - HW Len: 12 (Length in octets of the HW Address); - Proto Len: 4 (Length in octets of the Protocol Address); - Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply [ARP]; - HW Address of Sender: the HW Address (see section 8) of the Requester in an ARP Request, or the HW Address of the Responder in an ARP Reply; - Protocol Address of Sender: the IPv4 address of the Requester in an ARP Request, or that of the Responder in an ARP Reply; - HW Address of Target: set to zero in an ARP Request, and to the HW Address (see section 8) of the Requester in an ARP Reply; - Protocol Address of Target: the IPv4 address of the Responder in an ARP Request, or that of the Requester in an ARP Reply.
DeSanti, et al. Standards Track [Page 19] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 19] RFC 4338 IP over Fibre Channel January 2006
8. Link-layer Address/Hardware Address
8. Link-layer Address/Hardware Address
The Link-layer Address used in the Source/Target Link-layer Address option (see section 9.2) and the Hardware Address used in FC ARP (see section 7) have the same format, shown in figure 22.
The Link-layer Address used in the Source/Target Link-layer Address option (see section 9.2) and the Hardware Address used in FC ARP (see section 7) have the same format, shown in figure 22.
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_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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- N_Port_Name -+ | | +---------------+---------------+---------------+---------------+ | Reserved | N_Port_ID | +---------------+---------------+---------------+---------------+
Figure 22: Link-layer Address/HW Address Format
Figure 22: Link-layer Address/HW Address Format
Reserved fields MUST be set to zero when transmitting, and MUST be ignored when receiving.
Reserved fields MUST be set to zero when transmitting, and MUST be ignored when receiving.
9. Address Mapping for Unicast
9. Address Mapping for Unicast
9.1. Overview
9.1. Overview
An Nx_Port has two kinds of Fibre Channel addresses:
An Nx_Port has two kinds of Fibre Channel addresses:
- a non-volatile 64-bit address, called N_Port_Name; - a volatile 24-bit address, called N_Port_ID.
- a non-volatile 64-bit address, called N_Port_Name; - a volatile 24-bit address, called N_Port_ID.
The N_Port_Name is used to uniquely identify the Nx_Port, and the N_Port_ID is used to route frames to the Nx_Port. Both FC addresses are required to resolve an IPv6 or IPv4 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).
The N_Port_Name is used to uniquely identify the Nx_Port, and the N_Port_ID is used to route frames to the Nx_Port. Both FC addresses are required to resolve an IPv6 or IPv4 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).
9.2. IPv6 Address Mapping
9.2. IPv6 Address Mapping
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 shown in figure 23 when the link layer is Fibre Channel.
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 shown in figure 23 when the link layer is Fibre Channel.
DeSanti, et al. Standards Track [Page 20] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 20] RFC 4338 IP over Fibre Channel January 2006
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 | |
+---------------+---------------+ -+
| |
+- Link-layer Address -+
| |
+- +---------------+---------------+
| | Padding |
+---------------+---------------+---------------+---------------+
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 | | +---------------+---------------+ -+ | | +- Link-layer Address -+ | | +- +---------------+---------------+ | | Padding | +---------------+---------------+---------------+---------------+
Figure 23: Source/Target Link-layer Address Option for Fibre Channel
Figure 23: Source/Target Link-layer Address Option for Fibre Channel
Type: 1 for Source Link-layer address.
2 for Target Link-layer address.
Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
Length: 2 (in units of 8 octets).
Length: 2 (in units of 8 octets).
Padding: MUST be set to zero when transmitting,
MUST be ignored when receiving.
Padding: MUST be set to zero when transmitting, MUST be ignored when receiving.
Link-layer Address: the Nx_Port's Link-layer Address (see section
8).
Link-layer Address: the Nx_Port's Link-layer Address (see section 8).
9.3. IPv4 Address Mapping
9.3. IPv4 Address Mapping
The procedure for mapping IPv4 unicast addresses into Fibre Channel link-layer addresses uses the FC ARP protocol, as specified in section 7 and [ARP]. A source Nx_Port that has to send IPv4 packets to a destination Nx_Port, known by its IPv4 address, MUST perform the following steps:
The procedure for mapping IPv4 unicast addresses into Fibre Channel link-layer addresses uses the FC ARP protocol, as specified in section 7 and [ARP]. A source Nx_Port that has to send IPv4 packets to a destination Nx_Port, known by its IPv4 address, MUST perform the following steps:
1) The source Nx_Port first consults its local mapping tables for a
mapping <destination IPv4 address, N_Port_Name, N_Port_ID>.
1) The source Nx_Port first consults its local mapping tables for a mapping <destination IPv4 address, N_Port_Name, N_Port_ID>.
2) If such a mapping is found, and a valid Port Login is in place
with the destination Nx_Port, then the source Nx_Port sends the
IPv4 packets to the destination Nx_Port using the retrieved
N_Port_ID as D_ID.
2) If such a mapping is found, and a valid Port Login is in place with the destination Nx_Port, then the source Nx_Port sends the IPv4 packets to the destination Nx_Port using the retrieved N_Port_ID as D_ID.
3) If such a mapping is not found, or a valid Port Login is not in
place with the destination Nx_Port, then the source Nx_Port sends
a broadcast FC ARP Request (see section 10) to its connected FC
network.
3) If such a mapping is not found, or a valid Port Login is not in place with the destination Nx_Port, then the source Nx_Port sends a broadcast FC ARP Request (see section 10) to its connected FC network.
DeSanti, et al. Standards Track [Page 21] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 21] RFC 4338 IP over Fibre Channel January 2006
4) When a broadcast FC ARP Request is received by the Nx_Port with
the matching IPv4 address, that Nx_Port caches the information
carried in the FC ARP Request in its local mapping tables and
generates a unicast FC ARP Reply. If a valid Port Login to the
Nx_Port that sent the broadcast FC ARP Request does not exist, the
Nx_Port MUST perform such a Port Login, and then use it for the
unicast reply. The N_Port_ID to which the Port Login is directed
is taken from the N_Port_ID field of the Sender HW Address field
in the received FC ARP packet.
4) When a broadcast FC ARP Request is received by the Nx_Port with the matching IPv4 address, that Nx_Port caches the information carried in the FC ARP Request in its local mapping tables and generates a unicast FC ARP Reply. If a valid Port Login to the Nx_Port that sent the broadcast FC ARP Request does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast reply. The N_Port_ID to which the Port Login is directed is taken from the N_Port_ID field of the Sender HW Address field in the received FC ARP packet.
5) If no Nx_Port has the matching IPv4 address, no unicast FC ARP
Reply is returned.
5) If no Nx_Port has the matching IPv4 address, no unicast FC ARP Reply is returned.
10. Address Mapping for Multicast
10. Address Mapping for Multicast
IPv6 multicast packets, IPv4 multicast/broadcast packets, and ARP broadcast packets MUST be mapped to FC Sequences addressed to the broadcast N_Port_ID 0xFFFFFF, sent in FC Class 3 in a unidirectional Exchange (see section 12). Appendix A specifies how to transmit a Class 3 broadcast FC Sequence over various Fibre Channel topologies. The Destination N_Port_Name field of the FC Network_Header MUST be set to the value:
IPv6 multicast packets, IPv4 multicast/broadcast packets, and ARP broadcast packets MUST be mapped to FC Sequences addressed to the broadcast N_Port_ID 0xFFFFFF, sent in FC Class 3 in a unidirectional Exchange (see section 12). Appendix A specifies how to transmit a Class 3 broadcast FC Sequence over various Fibre Channel topologies. The Destination N_Port_Name field of the FC Network_Header MUST be set to the value:
- for broadcast ARP and IPv4 packets: 0x10-00-FF-FF-FF-FF-FF-FF;
- for multicast IPv6 packets: 0x10-00-33-33-XX-YY-ZZ-QQ, where
XX-YY-ZZ-QQ are the 4 least significant octets of the multicast
destination IPv6 address;
- for multicast IPv4 packets: 0x10-00-01-00-5E-XX-YY-ZZ, where the
23 least significant bits of XX-YY-ZZ are the 23 least significant
bits of the multicast destination IPv4 address and the most
significant bit of XX-YY-ZZ is set to zero.
- for broadcast ARP and IPv4 packets: 0x10-00-FF-FF-FF-FF-FF-FF; - for multicast IPv6 packets: 0x10-00-33-33-XX-YY-ZZ-QQ, where XX-YY-ZZ-QQ are the 4 least significant octets of the multicast destination IPv6 address; - for multicast IPv4 packets: 0x10-00-01-00-5E-XX-YY-ZZ, where the 23 least significant bits of XX-YY-ZZ are the 23 least significant bits of the multicast destination IPv4 address and the most significant bit of XX-YY-ZZ is set to zero.
An Nx_Port supporting IPv6 or IPv4 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, IPv4 multicast or broadcast packets, and ARP broadcast 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 ELSes.
An Nx_Port supporting IPv6 or IPv4 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, IPv4 multicast or broadcast packets, and ARP broadcast 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 ELSes.
Receiving an FC Sequence carrying an IPv6 multicast packet, an IPv4 multicast/broadcast packet, or an FC ARP broadcast packet triggers some additional processing by the Nx_Port when that IPv6, IPv4, or FC ARP packet requires a unicast reply. In this case, if a valid Port Login to the Nx_Port that sent the multicast or broadcast packet
Receiving an FC Sequence carrying an IPv6 multicast packet, an IPv4 multicast/broadcast packet, or an FC ARP broadcast packet triggers some additional processing by the Nx_Port when that IPv6, IPv4, or FC ARP packet requires a unicast reply. In this case, if a valid Port Login to the Nx_Port that sent the multicast or broadcast packet
DeSanti, et al. Standards Track [Page 22] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 22] RFC 4338 IP over Fibre Channel January 2006
does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast 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 Link-layer Address in the received Neighbor Discovery message. In the case of FC ARP messages, the N_Port_ID to which the Port Login is directed is taken from the N_Port_ID field of the Sender HW Address field in the received FC ARP packet.
does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast 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 Link-layer Address in the received Neighbor Discovery message. In the case of FC ARP messages, the N_Port_ID to which the Port Login is directed is taken from the N_Port_ID field of the Sender HW Address field in the received FC ARP packet.
As an example, if a received broadcast FC Sequence carries an IPv6 multicast unsolicited Router Advertisement [DISC], the receiving Nx_Port processes it 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 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 0xFFFFFF.
As an example, if a received broadcast FC Sequence carries an IPv6 multicast unsolicited Router Advertisement [DISC], the receiving Nx_Port processes it 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 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 0xFFFFFF.
11. Sequence Management
11. Sequence Management
FC Sequences carrying IPv6, IPv4, or ARP packets are REQUIRED to be non-streamed [FC-FS]. In order to avoid missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting IPv6 or IPv4 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST start by setting SEQ_CNT to zero in the first frame; every frame transmitted after that MUST increment the previous SEQ_CNT by one. The Continue Sequence Condition field in the F_CTL field of the FC Header MUST be set to zero [FC-FS].
FC Sequences carrying IPv6, IPv4, or ARP packets are REQUIRED to be non-streamed [FC-FS]. In order to avoid missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting IPv6 or IPv4 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST start by setting SEQ_CNT to zero in the first frame; every frame transmitted after that MUST increment the previous SEQ_CNT by one. The Continue Sequence Condition field in the F_CTL field of the FC Header MUST be set to zero [FC-FS].
12. Exchange Management
12. Exchange Management
To transmit IPv6, IPv4, or ARP packets to another Nx_Port or to a multicast/broadcast address, an Nx_Port MUST use dedicated unidirectional Exchanges (i.e., Exchanges dedicated to IPv6, IPv4, or ARP packet transmission and that do not transfer Sequence Initiative). As such, the Sequence Initiative bit in the F_CTL field of the FC Header MUST be set to zero [FC-FS]. The RX_ID field of the FC Header MUST be set to 0xFFFF.
To transmit IPv6, IPv4, or ARP packets to another Nx_Port or to a multicast/broadcast address, an Nx_Port MUST use dedicated unidirectional Exchanges (i.e., Exchanges dedicated to IPv6, IPv4, or ARP packet transmission and that do not transfer Sequence Initiative). As such, the Sequence Initiative bit in the F_CTL field of the FC Header MUST be set to zero [FC-FS]. The RX_ID field of the FC Header MUST be set to 0xFFFF.
Unicast FC Sequences carrying unicast Control Protocol packets (e.g., ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) SHOULD be sent in short-lived unidirectional Exchanges (i.e., Exchanges containing only one Sequence, in which both the First_Sequence and
Unicast FC Sequences carrying unicast Control Protocol packets (e.g., ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) SHOULD be sent in short-lived unidirectional Exchanges (i.e., Exchanges containing only one Sequence, in which both the First_Sequence and
DeSanti, et al. Standards Track [Page 23] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 23] RFC 4338 IP over Fibre Channel January 2006
Last_Sequence bits in the F_CTL field of the FC Header are set to one [FC-FS]). Unicast FC Sequences carrying other IPv6 and IPv4 packets (i.e., unicast IP packets carrying data traffic) MUST be sent in a long-lived unidirectional Exchange (i.e., an Exchange containing one or more Sequences). IP multicast packets MUST NOT be carried in unicast FC Sequences (see section 10).
Last_Sequence bits in the F_CTL field of the FC Header are set to one [FC-FS]). Unicast FC Sequences carrying other IPv6 and IPv4 packets (i.e., unicast IP packets carrying data traffic) MUST be sent in a long-lived unidirectional Exchange (i.e., an Exchange containing one or more Sequences). IP multicast packets MUST NOT be carried in unicast FC Sequences (see section 10).
Broadcast FC Sequences carrying multicast or broadcast Control Protocol packets (e.g., ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) MUST be sent in short-lived unidirectional Exchanges. Broadcast FC Sequences carrying other IPv6 or IPv4 multicast traffic (i.e., multicast IP packets carrying data traffic) MAY be sent in long-lived unidirectional Exchanges to enable a more efficient multicast distribution.
Broadcast FC Sequences carrying multicast or broadcast Control Protocol packets (e.g., ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) MUST be sent in short-lived unidirectional Exchanges. Broadcast FC Sequences carrying other IPv6 or IPv4 multicast traffic (i.e., multicast IP packets carrying data traffic) MAY be sent in long-lived unidirectional Exchanges to enable a more efficient multicast distribution.
Reasons to terminate a long-lived Exchange include the termination of Port Login and the completion of the IP communication. A long-lived Exchange MAY be terminated by setting the Last_Sequence bit in the F_CTL field of the FC Header to one, or via the ABTS (Abort Sequence) protocol [FC-FS]. A long-lived Exchange SHOULD NOT be terminated by transmitting the LOGO ELS, since this may terminate active Exchanges on other FC-4s [FC-FS].
Reasons to terminate a long-lived Exchange include the termination of Port Login and the completion of the IP communication. A long-lived Exchange MAY be terminated by setting the Last_Sequence bit in the F_CTL field of the FC Header to one, or via the ABTS (Abort Sequence) protocol [FC-FS]. A long-lived Exchange SHOULD NOT be terminated by transmitting the LOGO ELS, since this may terminate active Exchanges on other FC-4s [FC-FS].
13. Interoperability with RFC 2625
13. Interoperability with RFC 2625
The IPv4 encapsulation defined in this document, along with Exchange and Sequence management, are as defined in [RFC-2625]. Implementations following this specification are expected to interoperate with implementations compliant to [RFC-2625] for IPv4 packet transmission and reception.
The IPv4 encapsulation defined in this document, along with Exchange and Sequence management, are as defined in [RFC-2625]. Implementations following this specification are expected to interoperate with implementations compliant to [RFC-2625] for IPv4 packet transmission and reception.
The main difference between this document and [RFC-2625] is in the address resolution procedure. [RFC-2625] uses the Ethernet format of the ARP protocol and requires all Nx_Ports to have a format 0x1 N_Port_Name. This specification defines a Fibre Channel format for the ARP protocol that supports all commonly used N_Port_Names. In addition, this specification does not use FARP [RFC-2625].
The main difference between this document and [RFC-2625] is in the address resolution procedure. [RFC-2625] uses the Ethernet format of the ARP protocol and requires all Nx_Ports to have a format 0x1 N_Port_Name. This specification defines a Fibre Channel format for the ARP protocol that supports all commonly used N_Port_Names. In addition, this specification does not use FARP [RFC-2625].
An Nx_Port following this specification, and not having a format 0x1 N_Port_Name, is able to interoperate with an [RFC-2625] implementation by manually configuring the mapping <destination IPv4 address, N_Port_Name, N_Port_ID> on the involved Nx_Ports. Through this manual configuration, the ARP protocol does not need to be performed. However, IPv4 communication is not possible if the [RFC-2625] implementation strictly enforces the requirement for Nx_Ports to use N_Port_Names of format 0x1.
An Nx_Port following this specification, and not having a format 0x1 N_Port_Name, is able to interoperate with an [RFC-2625] implementation by manually configuring the mapping <destination IPv4 address, N_Port_Name, N_Port_ID> on the involved Nx_Ports. Through this manual configuration, the ARP protocol does not need to be performed. However, IPv4 communication is not possible if the [RFC-2625] implementation strictly enforces the requirement for Nx_Ports to use N_Port_Names of format 0x1.
DeSanti, et al. Standards Track [Page 24] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 24] RFC 4338 IP over Fibre Channel January 2006
An Nx_Port following this specification, and having a format 0x1 N_Port_Name, is able to interoperate with an [RFC-2625] implementation by manually configuring the mapping <destination IPv4 address, N_Port_Name, N_Port_ID> on the involved Nx_Ports, or by performing the IPv4 address resolution in compatibility mode, as described below:
An Nx_Port following this specification, and having a format 0x1 N_Port_Name, is able to interoperate with an [RFC-2625] implementation by manually configuring the mapping <destination IPv4 address, N_Port_Name, N_Port_ID> on the involved Nx_Ports, or by performing the IPv4 address resolution in compatibility mode, as described below:
- When IPv4 address resolution is attempted, the Nx_Port MUST send
two ARP Requests, the first one according to the FC ARP format and
the second one according to the Ethernet ARP format. If only an
Ethernet ARP Reply is received, it provides the N_Port_Name of the
Nx_Port having the destination IPv4 address. The N_Port_ID
associated with the N_Port_Name received in an Ethernet ARP Reply
may be retrieved from the S_ID field of the received ARP Reply, or
by querying the Fibre Channel Name Server;
- The Nx_Port MUST respond to a received Ethernet ARP Request with
an Ethernet ARP Reply;
- The Nx_Port MAY respond to FARP Requests [RFC-2625].
- When IPv4 address resolution is attempted, the Nx_Port MUST send two ARP Requests, the first one according to the FC ARP format and the second one according to the Ethernet ARP format. If only an Ethernet ARP Reply is received, it provides the N_Port_Name of the Nx_Port having the destination IPv4 address. The N_Port_ID associated with the N_Port_Name received in an Ethernet ARP Reply may be retrieved from the S_ID field of the received ARP Reply, or by querying the Fibre Channel Name Server; - The Nx_Port MUST respond to a received Ethernet ARP Request with an Ethernet ARP Reply; - The Nx_Port MAY respond to FARP Requests [RFC-2625].
The reception of a particular format of ARP message does not imply that the sending Nx_Port will continue to use the same format later.
The reception of a particular format of ARP message does not imply that the sending Nx_Port will continue to use the same format later.
Support of compatibility mode is REQUIRED by each implementation. The use of compatibility mode MUST be administratively configurable.
Support of compatibility mode is REQUIRED by each implementation. The use of compatibility mode MUST be administratively configurable.
14. Security Considerations
14. Security Considerations
IPv6, IPv4, and ARP do 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 and IPv4, because IPv6 and IPv4 over Fibre Channel do 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, IPv4, and ARP packets. All the techniques defined to secure IP traffic at the IP layer may be used in a Fibre Channel environment.
IPv6, IPv4, and ARP do 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 and IPv4, because IPv6 and IPv4 over Fibre Channel do 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, IPv4, and ARP packets. All the techniques defined to secure IP traffic at the IP layer may be used in a Fibre Channel environment.
15. IANA Considerations
15. IANA Considerations
The directory of ARP parameters has been updated to reference this document for hardware type 18.
The directory of ARP parameters has been updated to reference this document for hardware type 18.
16. Acknowledgements
16. Acknowledgements
The authors would like to acknowledge the ANSI INCITS T11.3 Task Group members who reviewed this document as well as the authors of [RFC-2625] and [RFC-3831]. The authors also thank the IMSS WG and Brian Haberman for their review and comments.
The authors would like to acknowledge the ANSI INCITS T11.3 Task Group members who reviewed this document as well as the authors of [RFC-2625] and [RFC-3831]. The authors also thank the IMSS WG and Brian Haberman for their review and comments.
DeSanti, et al. Standards Track [Page 25] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 25] RFC 4338 IP over Fibre Channel January 2006
17. Normative References
17. Normative References
[FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and
Signaling (FC-FS)".
[FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and Signaling (FC-FS)".
[FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2
(FC-AL-2)".
[FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 (FC-AL-2)".
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[PMTUD6] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[PMTUD6] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[ARP] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[ARP] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture".
[IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture".
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
18. Informative References
18. Informative References
[RFC-3831] DeSanti, C., "Transmission of IPv6 Packets over Fibre
Channel", RFC 3831, July 2004.
[RFC-3831] DeSanti, C., "Transmission of IPv6 Packets over Fibre Channel", RFC 3831, July 2004.
[RFC-2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP
over Fibre Channel", RFC 2625, June 1999.
[RFC-2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
DeSanti, et al. Standards Track [Page 26] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 26] RFC 4338 IP over Fibre Channel January 2006
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[PMTUD4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[PMTUD4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html
DeSanti, et al. Standards Track [Page 27] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 27] RFC 4338 IP over Fibre Channel January 2006
A. Transmission of a Broadcast FC Sequence over FC Topologies
(Informative)
A. Transmission of a Broadcast FC Sequence over FC Topologies (Informative)
A.1. Point-to-Point Topology
A.1. Point-to-Point Topology
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.
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.
A.2. Private Loop Topology
A.2. Private Loop Topology
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].
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].
1) 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.
1) 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.
2) The source NL_Port then removes the OPN(fr) signal when it returns
to it.
2) The source NL_Port then removes the OPN(fr) signal when it returns to it.
3) The source NL_Port then sends the Class 3 broadcast FC Sequence
having D_ID 0xFFFFFF.
3) The source NL_Port then sends the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF.
A.3. Public Loop Topology
A.3. Public Loop Topology
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].
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].
The Fabric propagates the broadcast to all other FC_Ports [FC-FS], including the FL_Port that the broadcast arrives on. This includes all F_Ports, and other FL_Ports.
The Fabric propagates the broadcast to all other FC_Ports [FC-FS], including the FL_Port that the broadcast arrives on. This includes all F_Ports, and other FL_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.
Each FL_Port propagates the broadcast by using the primitive signal OPN(fr), in order to prepare the loop to receive the broadcast sequence.
A.4. Fabric Topology
A.4. Fabric Topology
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].
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].
DeSanti, et al. Standards Track [Page 28] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 28] RFC 4338 IP over Fibre Channel January 2006
B. Validation of the <N_Port_Name, N_Port_ID> Mapping
(Informative)
B. Validation of the <N_Port_Name, N_Port_ID> Mapping (Informative)
B.1. Overview
B.1. Overview
At all times, the <N_Port_Name, N_Port_ID> mapping must be valid before use.
At all times, the <N_Port_Name, N_Port_ID> mapping must be valid before use.
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 Loop Initialization Primitive Sequence (LIP) in a loop topology [FC-AL-2] or after Not_Operational Primitive Sequence / Offline Primitive Sequence (NOS/OLS) in a point-to-point topology [FC-FS].
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 Loop Initialization Primitive Sequence (LIP) in a loop topology [FC-AL-2] or after Not_Operational Primitive Sequence / Offline Primitive Sequence (NOS/OLS) in a point-to-point topology [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_Port_IDs do not change as a result of Link Reset (LR) [FC-FS]; thus, address validation is not required in this case.
B.2. FC Layer Address Validation in a Point-to-Point Topology
B.2. FC Layer Address Validation in a Point-to-Point Topology
No validation is required after Link Reset (LR). In a point-to-point topology, NOS/OLS causes implicit Logout of each N_Port and after an NOS/OLS each N_Port must again perform a Port Login [FC-FS].
No validation is required after Link Reset (LR). In a point-to-point topology, NOS/OLS causes implicit Logout of each N_Port and after an NOS/OLS each N_Port must again perform a Port Login [FC-FS].
B.3. FC Layer Address Validation in a Private Loop Topology
B.3. FC Layer Address Validation in a Private Loop Topology
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 the Address Discovery procedure with the ADISC ELS [FC-FS].
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 the Address Discovery procedure with the ADISC ELS [FC-FS].
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.
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.
If any of the three FC addresses has changed, then the remote NL_Port must be logged out.
If any of the three FC addresses has changed, then the remote NL_Port must be logged out.
If an NL_Port's N_Port_ID changes after a LIP, then all active logged-in NL_Ports must be logged out.
If an NL_Port's N_Port_ID changes after a LIP, then all active logged-in NL_Ports must be logged out.
DeSanti, et al. Standards Track [Page 29] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 29] RFC 4338 IP over Fibre Channel January 2006
B.4. FC Layer Address Validation in a Public Loop Topology
B.4. FC Layer Address Validation in a Public Loop Topology
A Fabric Address Notification (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.
A Fabric Address Notification (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.
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.
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.
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 (i.e., to any private loop NL_Port).
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 (i.e., to any private loop NL_Port).
B.5. FC Layer Address Validation in a Fabric Topology
B.5. FC Layer Address Validation in a Fabric Topology
No validation is required after Link Reset (LR).
No validation is required after 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].
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].
C. Fibre Channel Bit and Byte Numbering Guidance
C. Fibre Channel Bit and Byte Numbering Guidance
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit numbering is different.
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit numbering is different.
Fibre Channel bit numbering can be observed if the data structure heading shown in figure 24 is cut and pasted at the top of the figures present in this document.
Fibre Channel bit numbering can be observed if the data structure heading shown in figure 24 is cut and pasted at the top of the figures present in this document.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Fibre Channel Bit Numbering
Figure 24: Fibre Channel Bit Numbering
DeSanti, et al. Standards Track [Page 30] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 30] RFC 4338 IP over Fibre Channel January 2006
D. Changes from RFC 2625
D. Changes from RFC 2625
- Nx_Ports with N_Port_Name format 0x2, 0x5, 0xC, 0xD, 0xE, and 0xF
are supported, in addition to format 0x1;
- An IP-capable Nx_Port MUST support Class 3;
- An IP-capable Nx_Port MUST support continuously increasing
SEQ_CNT;
- An IP-capable Nx_Port SHOULD support a receive data field size for
Device_Data FC frames of at least 1024 octets;
- The FC ESP_Header MAY be used;
- FC Classes of services other than 3 are not recommended;
- Defined a new FC ARP format;
- Removed support for FARP because some FC implementations do not
tolerate receiving broadcast ELSes;
- Added support for IPv4 multicast;
- Clarified the usage of the CS_CTL and Parameter fields of the FC
Header;
- Clarified the usage of FC Classes of service;
- Clarified the usage of FC Sequences and Exchanges.
- Nx_Ports with N_Port_Name format 0x2, 0x5, 0xC, 0xD, 0xE, and 0xF are supported, in addition to format 0x1; - An IP-capable Nx_Port MUST support Class 3; - An IP-capable Nx_Port MUST support continuously increasing SEQ_CNT; - An IP-capable Nx_Port SHOULD support a receive data field size for Device_Data FC frames of at least 1024 octets; - The FC ESP_Header MAY be used; - FC Classes of services other than 3 are not recommended; - Defined a new FC ARP format; - Removed support for FARP because some FC implementations do not tolerate receiving broadcast ELSes; - Added support for IPv4 multicast; - Clarified the usage of the CS_CTL and Parameter fields of the FC Header; - Clarified the usage of FC Classes of service; - Clarified the usage of FC Sequences and Exchanges.
E. Changes from RFC 3831
E. Changes from RFC 3831
- Clarified the usage of the CS_CTL and Parameter fields of the FC
Header;
- Clarified the usage of FC Classes of service;
- Clarified and updated the mapping of IPv6 multicast on Fibre
Channel;
- Clarified the usage of FC Sequences and Exchanges;
- Clarified and updated the format of the Neighbor Discovery
Link-layer option for Fibre Channel.
- Clarified the usage of the CS_CTL and Parameter fields of the FC Header; - Clarified the usage of FC Classes of service; - Clarified and updated the mapping of IPv6 multicast on Fibre Channel; - Clarified the usage of FC Sequences and Exchanges; - Clarified and updated the format of the Neighbor Discovery Link-layer option for Fibre Channel.
DeSanti, et al. Standards Track [Page 31] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 31] RFC 4338 IP over Fibre Channel January 2006
Authors' Addresses
Authors' Addresses
Claudio DeSanti Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Claudio DeSanti Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Phone: +1 408 853-9172 EMail: cds@cisco.com
Phone: +1 408 853-9172 EMail: cds@cisco.com
Craig W. Carlson QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 USA
Craig W. Carlson QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 USA
Phone: +1 952 932-4064 EMail: craig.carlson@qlogic.com
Phone: +1 952 932-4064 EMail: craig.carlson@qlogic.com
Robert Nixon Emulex 3333 Susan Street Costa Mesa, CA 92626 USA
Robert Nixon Emulex 3333 Susan Street Costa Mesa, CA 92626 USA
Phone: +1 714 885-3525 EMail: bob.nixon@emulex.com
Phone: +1 714 885-3525 EMail: bob.nixon@emulex.com
DeSanti, et al. Standards Track [Page 32] RFC 4338 IP over Fibre Channel January 2006
DeSanti, et al. Standards Track [Page 32] RFC 4338 IP over Fibre Channel January 2006
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
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.
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.
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.
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.
Intellectual Property
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
DeSanti, et al. Standards Track [Page 33]
DeSanti、他 標準化過程[33ページ]
一覧
スポンサーリンク
