On Jun 19, 2012, at 8:44 AM, Alexandru Petrescu wrote: > I think, the length of Interface ID be 64 is so mostly because IEEE > works now with 64bit EUI identifiers (instead of older 48bit MAC > addresses). I.e. compatibility between IEEE and IETF IPv6 would be the > main reason for this Interface ID to be 64. > > And this is so, even though there are IEEE links for which the MAC > address is even shorter than 64bit, like 802.15.4 short addresses being > on 16bit. For those, an IPv6 prefix length of 112bit would even make > sense. But it's not done, because same IEEE which says the 15.4 MAC > address is 16bit says that its EUI is 64bit. (what 'default' fill that > with is what gets into an IPv6 address as well). >
It's easy to put a 16 bit value into a 64 bit bucket. It's very hard to put a 64 bit value into a 16 bit bucket. Just saying. > The good thing isthere is nothing in the RFC IPv6 Addressing > Architecture that makes the Interface ID to be MUST 64bit. It just says > 'n'. > > What there _is_, is that when using RFC stateless addess > autoconfiguration (not DHCP) and on Ethernet and its keen (WiFi, > Bluetooth, ZigBee, more; but not USB nor LTE for example) then one must > use Interface ID of 64bit; and consequently network prefix length of > 64bit no more. > Well, there's another issue... On such a network, how would you go about doing ND? How do you construct a solicited node multicast address for such a node if it has, say, a /108 prefix? Owen
