The link local address that we are currently passing down from the rdmacm encodes a MAC address that was obtained through neighbor discovery; so we are safe.
There are RDMAoE applications (some in the embedded space) that do not use the rdmacm. Some of these rely on custom L2 address assignment and would like to completely avoid the use of neighbor discovery. For these, we can clearly state the requirement that the "Interface Identifier" in the link local address that they pass down should be such that it encodes a valid MAC address that the interface currently responds to. In the future we also intend to allow the use of (non link local) IP addresses encoded in the GIDs. And we will definitely use neighbor discovery to translate those. --Liran -----Original Message----- From: Roland Dreier [mailto:rdre...@cisco.com] Sent: Monday, November 30, 2009 7:34 AM To: Liran Liss Cc: Richard Frank; o...@lists.openfabrics.org; OpenFabrics EWG Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes > RFC 4291, Appendix A. Thanks for the pointer. As far as I can tell from reading some IPv6 stuff, it really is broken to try to go from a link-local IPv6 address back to a L2 ethernet address. For example, RFC 2464 (pointed to by RFC 4291) says: Ethernet Address The 48 bit Ethernet IEEE 802 address, in canonical bit order. This is the address the interface currently responds to, and may be different from the built-in address used to derive the Interface Identifier. It really seems to be setting ourselves up for trouble not to use neighbor discovery to map IPv6 addresses to link-layer addresses. - R. _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg