Hi Tony, Reply inline. > Technically you would comply with the RFCs, but the FFFE value was > negotiated with the IEEE to avoid colliding with their eventual conversion > to EUI-64. If you pick other values for the actual mac you need to talk to > the IEEE, but if it is only the IPv6 address the bits will work until an > implementation gets a full EUI-64 and doesn't want you claiming its > autoconfigured address.
=> I presume that the "u" bit i.e. universal/local bit that indicates the scope will have its significance in any IEEE EUI-64 identifier. In that case all IEEE EUI-64 identifiers assigned to IEEE 802.3 MAC interfaces will have "0" in their "u" bit and will result in "global" scoped interface-ids. Since my implementation generates only "local"scoped interface-ids, I don't think I'll be claiming any other interface's autoconf address. My implementation will anyway have to change if and when they move to EUI-64. Probably I'll then have to hash it to 48-bits. But, for now, my hash function is the NULL function. > If you really want an implementation specific value, don't bother copying > the mac, hash it then put in your filler. => I did consider hashing but due to the unique requirements of my environment, I've decided to specifically have the MAC address in the Interface-ID. Thanks & Regards Vijay On Thu, Jun 25, 2009 at 4:49 AM, Tony Hain<[email protected]> wrote: > Technically you would comply with the RFCs, but the FFFE value was > negotiated with the IEEE to avoid colliding with their eventual conversion > to EUI-64. If you pick other values for the actual mac you need to talk to > the IEEE, but if it is only the IPv6 address the bits will work until an > implementation gets a full EUI-64 and doesn't want you claiming its > autoconfigured address. Other than that you will simply confuse people that > read documents that state the EUI-48 transform is supposed to be FFFE. > > If you really want an implementation specific value, don't bother copying > the mac, hash it then put in your filler. > > Tony > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Vijayrajan ranganathan >> Sent: Tuesday, June 23, 2009 10:09 PM >> To: [email protected] >> Subject: Implementation specific Interface-ID >> >> Hi Everyone, >> >> I have an ethernet interface for which I am defining the Interface-ID >> in a different manner. >> >> For an ethernet interface with MAC "34-56-78-9A-BC-DE", I am defining >> the Interface-ID to be "34-56-78-xy-zw-9A-BC-DE" instead of >> "36-56-78-FF-FE-9A-BC-DE" >> >> where x,y,z,w are my implementation-defined octets. >> >> Note: >> 1. I am fine with a locally-unique Interface-ID >> 2. The solicited-node multicast address i'll generate for a given >> unicast/anycast address based on this Interface-ID is the same as >> that for RFC 2464 based Interface-ID. >> >> >> Assuming I make this change in an IPv6 stack which conforms to RFCs >> >> 2464 - Transmission of IPv6 Packets over Ethernet Networks >> 3513 - Internet Protocol Version 6 (IPv6) Addressing Architecture >> 4861 - Neighbor Discovery for IP version 6 (IPv6) >> 4862 - IPv6 Stateless Address Autoconfiguration >> 3810 - Multicast Listener Discovery Version 2 (MLDv2) for IPv6 >> >> After this change, will I still conform to these RFCs?? >> >> >> Thanks & Regards >> Vijay >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
