On Mar 29, 2010, at 17:52, Jonathan Hui wrote: > > Hi Carsten, > > I think part of the confusion comes from some of the text in RFC 4862. In > particular, RFC 4862 seems to indicate that a particular link defines a fixed > length for IIDs (RFC 4944 currently defines IIDs to be 64 bits). Then RFC > 4862 has the following text: > > "If the sum of the prefix length and interface identifier length does not > equal 128 bits, the Prefix Information option MUST be ignored."
Aha! Note to the ND authors: We don't have to copy that restriction. (Actually, my text is about the prefix in the context, not the one used for SLAAC; I have always been arguing that the two should be disseminated using the same bits in the PIO/6IO while others thought that this was an unnecessary conflation; this now becomes even more interesting.) > And RFC 4944 has text to remind of the above constraint: > > "An IPv6 address prefix used for stateless autoconfiguration [RFC4862] of an > IEEE 802.15.4 interface MUST have a length of 64 bits." Interesting. Again, this could be changed (e.g., in ND). > So one question is whether it's possible to utilize a 'variable sized' IID to > generate global addresses. We already have 64-bit IIDs when generating > global addresses from EUI-64s. It may be a bit strange to have two different > IID lengths for a 6lowpan link, so defining a 17-bit IID already bends rules > a bit. Would it be too much of a stretch to say that using a short address, > we can generate an IID of length between 16 and 64 bits? :) That would mesh well with my proposal for HC (but the latter only prepares for any ND fixes needed here). (In my twisted mind, the IID would still be 64 bits, but part of it would be generated from the prefix. But that's just me.) Now I still don't know what would be better about ::1:xxxx -- using this would require the exact same changes to all these items, no? Except that my proposal also needs the "override" (= use only as many bits of ::ff:fe00:xxxx as you need to fill the prefix) rule. Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
