+1 Robert Cragie (Pacific Gas & Electric)
Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com <http://www.gridmerge.com/> On 29/03/2010 9:19 AM, Colin O'Flynn wrote:
Hello,Except that my proposal also needs the "override" (= use only as many bitsof::ff:fe00:xxxx as you need to fill the prefix) rule. (In my twisted mind, the IID would still be 64 bits, but part of it wouldbegenerated from the prefix. But that's just me.)With the 16-bit IID, it can make sense to just override up to the last 16 bits. But with the 64-bit EUI, unless you are using the full 64-bits there is no promise the IPv6 address will be unique. The last 16-bits will be the same among many different EUI64's, and indeed has a chance of being the same as a 16-bit short address in use by the network. The ::ff:fe00:xxxx format is helpful as it maps to a restricted EUI-64 type (http://standards.ieee.org/regauth/oui/tutorials/EUI64.html), so anybody receiving an IPv6 frame from ::ff:fe00:xxxx can ensure someone else doesn't happen to have this EUI. Thus I think the longer-than-64-bit prefix should only be supported with 16-bit short address only, and the prefix must have the format ::xxff:fexx:0000 . This ensure that someone cannot pick a prefix that maps to an EUI-64 space, which could be quite confusing. This would still work with the "override" idea, in that you generate an IID of the ff:fe00:xxxx format, and override as many bits as needed. If the prefix is of that :ff:fexx: format it will maintain the separation from EUI-64, as you just need that ff:fe in place. Regards, -Colin O'Flynn -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Carsten Bormann Sent: March 29, 2010 5:04 PM To: Jonathan Hui Cc: [email protected] Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses 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. Inparticular, 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 notequal 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] ofan 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' IIDto 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
