agree
Message: 2 > Date: Mon, 29 Mar 2010 17:19:31 +0100 > From: "Colin O'Flynn" <[email protected]> > Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses > To: "'Carsten Bormann'" <[email protected]>, "'Jonathan Hui'" > <[email protected]> > Cc: [email protected] > Message-ID: <004601cacf5b$a0925a80$e1b70f...@com> > Content-Type: text/plain; charset="us-ascii" > > Hello, > > > 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. > >(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.) > > 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. > 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
