Hi Owen, When creating the IID from a 16-bit, you first generate a fake EUI-48. From that you generate the IID, which has the format xx:xx:xx:ff:fe:xx:xx:xx
Any EUI-64 with ff:fe or ff:ff in the middle is *not* a valid EUI-64, so Xerox shouldn't be too worried ;-) Reference: http://standards.ieee.org/regauth/oui/tutorials/EUI64.html For option #2: I also agree there are some issues around the prefix. If it always had ff:fexx:xxxx at the end, it would always be obvious you are using 16-bit addresses (assuming you do this with 16-bit addresses only). Regards. -Colin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Owen Kirby Sent: March 29, 2010 7:38 PM To: [email protected] Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses Regarding option 1: If the goal is to create a pseudo-EUI64 from the 16-bit address. Should be concerned about using Xerox's OUI in the first three octets? The OUI is something that got trampled in RFC4944's (short address -> IID) conversion. Perhaps an IID of the form ACDE:4800::xxxx would make a better IID. The AC-DE-48 in this case is the "private" OUI. We could even apply to the IEEE (or is it IANA that handles this?) to reserve an OUI specifically for 6LoWPAN IID's so that we know they won't conflict with other devices on the PAN. Regarding option 2: Is there any concern that 17-bit IID's might conflict with 64-bit EUI's? If one device has the short address 0x0000, and the other has the long address 00-00-00-00-00-01-00-00, then wouldn't they both wind up using the same link-local address FE80::1:0000? I prefer option 1, since it's easier to tell which address type the IID was derived from. Thanks, Owen Kirby 6lowpan issue tracker wrote: > #65: Deriving IIDs from Short Addresses > --------------------------------+------------------------------------------- > Reporter: j...@… | Owner: j...@… > Type: defect | Status: new > Priority: major | Milestone: > Component: hc | Version: > Severity: Active WG Document | Keywords: > --------------------------------+------------------------------------------- > One of the issues raised on the ML and in Anaheim is the issue of deriving > IIDs from IEEE 802.15.4 short addresses. There was general consensus that > the PAN ID should never be included in the IID. As such, I think we now > have the following two options: > > 1) Maintain the RFC 4944 translation (short address -> ethernet address -> > 64-bit IID). Generated IIDs will be 64 bits in length and of the form > (0000:00ff:fe00:xxxx), where xxxx is the short address. > > 2) Update RFC 4944 translation to (short address -> 17-bit IID). > Generated IIDs will be 17 bits in length and of the form > (0000:0000:0001:xxxx), where xxxx is the short address. > > The primary difference between the two options are the lengths of prefixes > that may be used to generate global addresses. Option 1 says that > different PANs must be assigned unique 64-bit prefixes. Option 2 says > that different PANs must be assigned unique 111-bit prefixes, but that > multiple PANs may utilize the same 64-bit prefix. > > I am comfortable with either option, but we need to agree on one that is > well-defined. So which would people prefer? If you have no preference, > please provide that feedback as well. > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
