< draft-ietf-imss-ipv6-over-fibre-channel-01.txt   draft-ietf-imss-ipv6-over-fibre-channel-02.txt >
IMSS Working Group C. DeSanti IMSS Working Group C. DeSanti
Internet Draft Andiamo Systems Internet Draft Cisco Systems
draft-ietf-imss-ipv6-over-fibre-channel-01.txt December 2003 draft-ietf-imss-ipv6-over-fibre-channel-02.txt April 2004
Expires: June 2004 Expires: October 2004
Category: Standards Track Category: Standards Track
Transmission of IPv6 Packets over Fibre Channel Transmission of IPv6 Packets over Fibre Channel
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 48 skipping to change at page 2, line 48
17. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 19 17. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 19
A. Transmission of a Broadcast FC Sequence over FC Topologies. . 20 A. Transmission of a Broadcast FC Sequence over FC Topologies. . 20
B. Validation of the <N_Port_Name, N_Port_ID> mapping. . . . . . 21 B. Validation of the <N_Port_Name, N_Port_ID> mapping. . . . . . 21
C. Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . 22 C. Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . 22
1. Introduction 1. Introduction
Fibre Channel (FC) is a high speed serial interface technology that Fibre Channel (FC) is a high speed serial interface technology that
supports several Upper Layer Protocols including Small Computer supports several Upper Layer Protocols including Small Computer
System Interface (SCSI) and IPv4, as specified in [IPFC]. System Interface (SCSI) and IPv4 as specified in [IPFC].
The purpose of this document is to specify a way of encapsulating IP The purpose of this document is to specify a way of encapsulating IP
version 6 [IPv6] over Fibre Channel and to describe a method of version 6 [IPv6] over Fibre Channel and to describe a method of
forming IPv6 link-local addresses [AARCH] and statelessly forming IPv6 link-local addresses [AARCH] and statelessly
autoconfigured addresses on Fibre Channel networks. This document autoconfigured addresses on Fibre Channel networks. This document
also describes the content of the Source/Target Link-layer Address also describes the content of the Source/Target Link-layer Address
option used in Neighbor Discovery [DISC] when the messages are option used in Neighbor Discovery [DISC] when the messages are
transmitted on a Fibre Channel network. transmitted on a Fibre Channel network.
Warning to readers familiar with Fibre Channel: both Fibre Channel Warning to readers familiar with Fibre Channel: both Fibre Channel
skipping to change at page 6, line 25 skipping to change at page 6, line 25
related by the value of the Exchange_ID fields in the FC Header. An 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) Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID)
uniquely identify the Exchange. uniquely identify the Exchange.
3. IPv6 Capable Nx_Ports 3. IPv6 Capable Nx_Ports
This specification requires an IPv6 capable Nx_Port to have the This specification requires an IPv6 capable Nx_Port to have the
following properties: following properties:
- The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is 0xD, 0xE, 0xF (see section 6.1). IPv6 support for other
outside the scope of this specification; Name_Identifier formats is outside the scope of this
specification;
- It MUST support Class 3; - It MUST support Class 3;
- It MUST support continuously increasing SEQ_CNT [FC-FS]; - It MUST support continuously increasing SEQ_CNT [FC-FS];
- It MUST be able to transmit and receive an FC-4 Information Unit - It MUST be able to transmit and receive an FC-4 Information Unit
at least 1304 octets long; at least 1304 octets long;
- It SHOULD support a receive data field size for Device_Data FC - It SHOULD support a receive data field size for Device_Data FC
frames of at least 1024 octets. frames of at least 1024 octets.
4. IPv6 Encapsulation 4. IPv6 Encapsulation
4.1 FC Sequence Format 4.1 FC Sequence Format
An IPv6 packet is mapped to an Information Unit at the FC-4 level of An IPv6 packet is mapped to an Information Unit at the FC-4 level of
Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2 Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2
level. An FC Information Unit containing an IPv6 packet MUST carry level. An FC Information Unit containing an IPv6 packet MUST carry
the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC],
resulting to the FC Information Unit format depicted in figure 2. resulting in the FC Information Unit format depicted in figure 2.
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
+- -+ +- -+
| Network_Header | | Network_Header |
+- (16 octets) -+ +- (16 octets) -+
| | | |
+- -+ +- -+
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at page 10, line 26 skipping to change at page 10, line 26
As the default MTU size far exceeds the message sizes typically used As the default MTU size far exceeds the message sizes typically used
in the Internet, an IPv6 over FC implementation SHOULD implement Path in the Internet, an IPv6 over FC implementation SHOULD implement Path
MTU Discovery [PMTUD], or at least maintain different MTU values for MTU Discovery [PMTUD], or at least maintain different MTU values for
on-link and off-link destinations. on-link and off-link destinations.
For correct operation in a routed environment, it is critically For correct operation in a routed environment, it is critically
important to configure an appropriate MTU option in Router important to configure an appropriate MTU option in Router
Advertisements. Advertisements.
For correct operation when mixed media are bridged together, the For correct operation when mixed media (e.g., Ethernet and Fibre
smallest MTU of all the media must be advertised by routers in an MTU Channel) are bridged together, the smallest MTU of all the media must
option. If there are no routers present, this MTU must be manually be advertised by routers in an MTU option. If there are no routers
configured in each node which is connected to a medium with a default present, this MTU must be manually configured in each node which is
MTU larger than the smallest MTU. connected to a medium with a default MTU larger than the smallest
MTU.
6. Stateless Address Autoconfiguration 6. Stateless Address Autoconfiguration
6.1 IPv6 Interface Identifier and Address Prefix 6.1 IPv6 Interface Identifier and Address Prefix
The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 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 address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6
Interface Identifier is obtained by complementing the Universal/Local Interface Identifier is obtained by complementing the Universal/Local
bit of the OUI field of the derived EUI-64 address. bit of the OUI field of the derived EUI-64 address.
[FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), [FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address),
or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers
in EUI-64 addresses. This allows the usage of these 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 to support IPv6. [FC-FS] also defines EUI-64 mapped FC
Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived
from an EUI-64 address. It is possible to reverse this address from an EUI-64 address. It is possible to reverse this address
mapping to obtain the original EUI-64 address in order to support mapping to obtain the original EUI-64 address in order to support
IPv6. IPv6.
An IPv6 Address Prefix used for stateless address autoconfiguration Stateless address autoconfiguration MUST be performed as specified in
[ACONF] of an Nx_Port MUST have a length of 64 bits. [ACONF]. An IPv6 Address Prefix used for stateless address
autoconfiguration of an Nx_Port MUST have a length of 64 bits.
6.2 Generating an Interface ID from a Format 1 N_Port_Name 6.2 Generating an Interface ID from a Format 1 N_Port_Name
The Name_Identifier format 0x1 is depicted in figure 7. The Name_Identifier format 0x1 is depicted in figure 7.
0 1 2 3 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 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 | |0 0 0 1| 0x000 | OUI |
+-------+-------+---------------+---------------+---------------+ +-------+-------+---------------+---------------+---------------+
skipping to change at page 15, line 30 skipping to change at page 15, line 30
8. Address Mapping for Unicast 8. Address Mapping for Unicast
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 non-volatile 64-bit address, called N_Port_Name;
- a volatile 24-bit address, called N_Port_ID. - a volatile 24-bit address, called N_Port_ID.
The N_Port_Name is used to uniquely identify the Nx_Port, while the The N_Port_Name is used to uniquely identify the Nx_Port, while the
N_Port_ID is used to route frames to the Nx_Port. Both FC addresses N_Port_ID is used to route frames to the Nx_Port. Both FC addresses
are required to resolve an IPv6 unicast address. The fact that the are required to resolve an IPv6 unicast address. The fact that the
N_Port_ID is volatile implies that the mapping between N_Port_Name N_Port_ID is volatile implies that an Nx_Port MUST validate the
and N_Port_ID MUST be valid before use. Appendix B discusses the mapping between its N_Port_Name and N_Port_ID when certain Fibre
validation process. Channel events occur (see Appendix B).
The procedure for mapping IPv6 unicast addresses into Fibre Channel The procedure for mapping IPv6 unicast addresses into Fibre Channel
link-layer addresses uses the Neighbor Discovery Protocol [DISC]. The link-layer addresses uses the Neighbor Discovery Protocol [DISC]. The
Source/Target Link-layer Address option has the format depicted in Source/Target Link-layer Address option has the format depicted in
figure 20 when the link layer is Fibre Channel. figure 20 when the link layer is Fibre Channel.
0 1 2 3 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 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Reserved | | Type | Length = 2 | Reserved |
skipping to change at page 18, line 11 skipping to change at page 18, line 11
or Exchange Responder by using the ABTS (Abort Sequence) protocol or Exchange Responder by using the ABTS (Abort Sequence) protocol
[FC-FS]. IPv6 Exchanges SHOULD NOT be terminated by Logout, since [FC-FS]. IPv6 Exchanges SHOULD NOT be terminated by Logout, since
this may terminate active Exchanges on other FC-4s [FC-FS]. this may terminate active Exchanges on other FC-4s [FC-FS].
12. Security Considerations 12. Security Considerations
IPv6 does not introduce any additional security concerns beyond those IPv6 does not introduce any additional security concerns beyond those
that already exist within the Fibre Channel protocols. Zoning that already exist within the Fibre Channel protocols. Zoning
techniques based on FC Name Server masking (soft zoning) do not work techniques based on FC Name Server masking (soft zoning) do not work
with IPv6, because IPv6 over Fibre Channel does not use the FC Name with IPv6, because IPv6 over Fibre Channel does not use the FC Name
Server. All the techniques defined to secure IPv6 traffic may be used Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames
in a Fibre Channel Environment. composing FC Sequences carrying IPv6 packets. All the techniques
defined to secure IPv6 traffic at the IPv6 layer may be used in a
Fibre Channel environment.
13. IANA Considerations 13. IANA Considerations
None. None.
14. Acknowledgments 14. Acknowledgments
The author would like to acknowledge the authors of [IPFC], [ETHER], The author would like to acknowledge the authors of [IPFC], [ETHER],
and [IPv6-1394], since some part of this document has been derived and [IPv6-1394], since some part of this document has been derived
from them, as well as the ANSI INCITS T11.3 Task Group members who from them, as well as the ANSI INCITS T11.3 Task Group members who
skipping to change at page 18, line 49 skipping to change at page 19, line 5
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[PMTUD] McCann, J., Deering, S. and J. Mogul, "Path MTU [PMTUD] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996. Discovery for IP version 6", RFC 1981, August 1996.
[IEEE-LLC] IEEE Standards for Local Area Networks: Logical Link [IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and
Control", IEEE, New York, 1985. Metropolitan Area Networks: Overview and Architecture".
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
16. Informative References 16. Informative References
[IPFC] Rajagopal, M., Bhagwat, R. and W. Rickard, "IP and ARP [IPFC] Rajagopal, M., Bhagwat, R. and W. Rickard, "IP and ARP
over Fibre Channel", RFC 2625, June 1999. over Fibre Channel", RFC 2625, June 1999.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", [AH] Kent, S. and R. Atkinson, "IP Authentication Header",
skipping to change at page 19, line 31 skipping to change at page 19, line 34
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets [IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
over IEEE 1394 Networks", RFC 3146, October 2001. over IEEE 1394 Networks", RFC 3146, October 2001.
17. Author's Address 17. Author's Address
Claudio DeSanti Claudio DeSanti
Andiamo Systems, Inc. Cisco Systems, Inc.
375 E. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 853-9172 Phone: +1 408 853-9172
EMail: cds@andiamo.com EMail: cds@cisco.com
A. Transmission of a Broadcast FC Sequence over FC Topologies A. Transmission of a Broadcast FC Sequence over FC Topologies
A.1 Point-to-Point Topology A.1 Point-to-Point Topology
No particular mechanisms are required for this case. The Nx_Port No particular mechanisms are required for this case. The Nx_Port
connected at the other side of the cable receives the broadcast FC connected at the other side of the cable receives the broadcast FC
Sequence having D_ID 0xFFFFFF. Sequence having D_ID 0xFFFFFF.
A.2 Private Loop Topology A.2 Private Loop Topology
 End of changes. 11 change blocks. 
24 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/