1

IPv4 and ARP over Fibre Channeldraft-desanti-imss-ipv4-over-fibre-channel-00.txt

61th IETF, Washington DC

Claudio DeSanti

cds@cisco.com

222Claudio DeSanti

History

• RFC 2625 has been evaluated for advancement to Draft Standard status

• Discovered that some implementations are not following RFC 2625 because of:

N_Port_Name format restriction

RFC 2625 allowed only NAA 1

Use of FARP

RFC 2625 required its support for interoperability

Major problems

• The new specification tries to resolve these issues

333Claudio DeSanti

RFC 2625 ARP Format

Sender

Target IP Address

HW Type = Ethernet

HW Len = 6

ProtocolType = IPv4

Proto Len = 4 Opcode

Sender HW Address

IP Address

Target HW Address

444Claudio DeSanti

RFC 2625 IPv4 Address Resolution (1)

ARP Request:- Sender HW Address = HW(A)- Sender IP Address = IP(A)- Target HW Address = ??- Target IP Address IP(B)

A

B C D

555Claudio DeSanti

RFC 2625 IPv4 Address Resolution (2)

ARP Reply:- Sender HW Address = HW(B)- Sender IP Address = IP(B)- Target HW Address = HW(A)- Target IP Address IP(A)

A

B C D

666Claudio DeSanti

RFC 2625 IPv4 Address Resolution (3)

FARP Request:- Requester N_Port_Name- Requester N_Port_ID- Responder N_Port_Name- Responder N_Port_ID = ??

A

B C D

777Claudio DeSanti

RFC 2625 IPv4 Address Resolution (4)

FARP Reply:- Requester N_Port_Name- Requester N_Port_ID- Responder N_Port_Name- Responder N_Port_ID

A

B C D

888Claudio DeSanti

The Nasty FARP…

• FARP is a broadcast ELS

• Several (old?) disk implementation do (did?) not tolerate receiving unexpected ELSs

They may reinitialize or issue some SCSI errors

B resolving C’s IPv4 address may cause I/O errors to A!

• Some vendors did not implement FARP at all!

• The Switch vendors defined “broadcast zoning” in FC-SW-3 to administratively limit the scope of the FARP broadcast ELS

999Claudio DeSanti

New ARP Format

Sender HW Address

HW Type = Fibre Channel ProtocolType = IPv4

HW Len = 12 Proto Len = 4 Opcode

Sender IP Address

Target HW Address

Target IP Address

Sender N_Port_Name

Sender N_Port_IDReserved

Target N_Port_Name

Target N_Port_IDReserved

101010Claudio DeSanti

Updated IPv4 Address Resolution (1)

ARP Request:- Sender HW Address = N_Port_Name(A), N_Port_ID(A)- Sender IP Address = IP(A)- Target HW Address = ??- Target IP Address IP(B)

A

B C D

111111Claudio DeSanti

Updated IPv4 Address Resolution (2)

ARP Reply:- Sender HW Address = N_Port_Name(B), N_Port_ID(B)- Sender IP Address = IP(B)- Target HW Address = N_Port_Name(A), N_Port_ID(A)- Target IP Address IP(A)

A

B C D

121212Claudio DeSanti

New Draft Benefits

• All commonly used Name_Identifier formats are supported

• Simplified ARP resolution process

No more need for FARP

• Missing functionality added

IPv4 multicast support

131313Claudio DeSanti

Backward Compatibility (1)

• Communication between an RFC 2625 implementation and an Nx_Port with NAA ≠ 1

If the RFC 2625 implementation strictly enforces theNAA =1 requirement, no way!

IP encapsulation issue

If the RFC 2625 implementation does not strictly enforce the NAA = 1 requirement, only address resolution does not work

Use manual mapping tables

141414Claudio DeSanti

Backward Compatibility (2)

• Communication between an RFC 2625 implementation and an Nx_Port with NAA = 1

No issues with IP encapsulation

For address resolution send two ARP requests:

one according to the Fibre Channel format

one according to the Ethernet format

Use the first reply received

Reply with an Ethernet ARP reply to any received Ethernet ARP request

151515Claudio DeSanti

How to move forward

• There is consensus in T11 in replacing RFC 2625

• Create a combined IPv6/IPv4 document to replace both RFC 2625 and RFC 3831

Easier for implementors to work over it

It shows that IPv6 support is straightforward

Allows “standard developers” to think to both worlds

A single Exchange for IPv4 and IPv6, or one per protocol?

The quality of the combined document is better

The new draft is getting a deeper review