IPv4%20and%20ARP%20over%20Fibre%20Channel%20draft-desanti-imss-ipv4-over-fibre-channel-00.txt

1
IPv4 and ARP over Fibre Channeldraft-desanti-ims
s-ipv4-over-fibre-channel-00.txt

• 61th IETF, Washington DC
• Claudio DeSanti
• cds_at_cisco.com

2
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

3
RFC 2625 ARP Format
HW Type Ethernet
HW Len 6
Opcode
Sender HW Address
Sender
IP Address
Target HW Address
Target IP Address
4
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
5
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
6
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
7
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
8
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 Cs 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

9
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
10
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
11
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
12
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

13
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

14
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

15
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