Hello, > I think this was meant to exclude :: as the IID, but that may be just my > interpretation.
I think this was the intent, as it makes the most sense. The way it's written though it seems to me like it's disallowing an all-zero 64 or 48-bit address. The sentence before it specifies: The interface identifier is formed from this 48-bit address as per the "IPv6 over Ethernet" specification [RFC2464]. However, in the resultant interface identifier, the "Universal/Local" (U/L) bit SHALL be set to zero in keeping with the fact that this is not a globally unique value. For either address format, all zero addresses MUST NOT be used. So for me "either address format" means the pseudo-48 or the real EUI-64. > If we really need that 32768th address, we could also do that. The bigger issue is that short address zero is used as a default coordinator address in some networks. Thus although it's just another address, it's one that is likely to come up more than address 8956 for example. Sure it's easy to not use it. But one person's implementation might use it, and someone else's might specifically check for it and throw away any packets with this format. Adding some extra text to clarify would be an improvement here, as I don't think there is any real problem with using address fe80::ff:fe00:0 that I can see for example, so we shouldn't artificially limit that address. I'd be most in favor of using the PAN-ID of 0x0000 as is currently done, and just specifying that the IID cannot be ::, but the short address can be 0. Regards, -Colin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Gavelle Sent: March 29, 2010 5:39 PM To: Jonathan Hui Cc: [email protected] Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses A prefix of less than 64 bits would be useful when having a small Public Internet -> Ethernet -> 6LowPAN network. Public prefix's are normally allocated in 64 or 48 bit sizes. When I set up a network like this, I needed a public /48 instead of a /64 so that I could have one /64 for the Ethernet and one for the 6LowPAN. In my case, the Ethernet was only used between the edge router and the IPv6 router so just had the address of these two routers on it. Setting up a network in this way would force the use of the 16 bit short addresses when using the public Internet. However, these addresses compress better than EUI 64 addresses and so may be a better choice anyway. To avoid confusion between the EUI 64 derived addresses and the short address, it may be better to use a /40 (or /48) rather than a /17 addressing scheme. We could then keep the pseudo 48 address with the ::xxff:fexx: as part of the prefix and so keep the advantage of easily identifying EUI64 or short addresses. I am therefore in favour of the second proposal, using a /17. However, if there are reasons why it would not be possible to use the spare bits in this way then I prefer the first proposal of a /64 because it is simpler. Daniel. Jonathan Hui wrote: > > In an effort to update 6lowpan-hc so that we can quickly move it back > into WGLC, I'd like to close on this issue by the end of the week. > Please provide your feedback. > > -- > Jonathan Hui > > On Mar 29, 2010, at 8:10 AM, 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. >> >> -- >> Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/65> >> 6lowpan <http://tools.ietf.org/6lowpan/> > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
