150 likes | 331 Views
IPv4 and ARP over Fibre Channel draft-desanti-imss-ipv4-over-fibre-channel-00.txt. 61 th IETF, Washington DC Claudio DeSanti cds@cisco.com. History. RFC 2625 has been evaluated for advancement to Draft Standard status
E N D
IPv4 and ARP over Fibre Channeldraft-desanti-imss-ipv4-over-fibre-channel-00.txt 61th IETF, Washington DC Claudio DeSanti cds@cisco.com
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
ProtocolType = IPv4 Proto Len = 4 RFC 2625 ARP Format HW Type = Ethernet HW Len = 6 Opcode Sender HW Address Sender IP Address Target HW Address Target IP Address
RFC 2625 IPv4 Address Resolution (1) A ARP Request: - Sender HW Address = HW(A) - Sender IP Address = IP(A) - Target HW Address = ?? - Target IP Address IP(B) C B D
RFC 2625 IPv4 Address Resolution (2) A ARP Reply: - Sender HW Address = HW(B) - Sender IP Address = IP(B) - Target HW Address = HW(A) - Target IP Address IP(A) C B D
RFC 2625 IPv4 Address Resolution (3) A FARP Request: - Requester N_Port_Name - Requester N_Port_ID - Responder N_Port_Name - Responder N_Port_ID = ?? C B D
RFC 2625 IPv4 Address Resolution (4) A FARP Reply: - Requester N_Port_Name - Requester N_Port_ID - Responder N_Port_Name - Responder N_Port_ID C B D
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
Sender N_Port_Name Reserved Sender N_Port_ID Target N_Port_Name Reserved Target N_Port_ID New ARP Format HW Type = Fibre Channel ProtocolType = IPv4 HW Len = 12 Proto Len = 4 Opcode Sender HW Address Sender IP Address Target HW Address Target IP Address
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 C B D
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 C B D
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
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
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
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