Hi Colin,
The mapping was really intended for global-scope IEEE addresses. I
don't think overlap of locally generated IIDs with other IEEE EUI-64
addresses is really a concern. Some examples:
1) The whole purpose of complementing the u/l bit when generating IIDs
is to make best use of the '::' when typing IPv6 addresses.
2) CGAs don't make any attempt to avoid overlap with existing IEEE
EUI-64 addresses.
3) DHCPv6 servers can assign whatever they want.
The assumption is that once you have locally managed Interface
Identifiers, you need to have a mechanism that manages their
assignment/uniqueness anyway. Furthermore, there is no requirement
that IIDs have to be generated from link-layer addresses. Setting the
u/l bit to zero ensures that no overlap will occur with global scope
IEEE EUI-64 addresses.
So to frame the current discussion while attempting to be specific to
6lowpan-hc:
1) How is an IID generated from an IEEE 802.15.4 short address? This
is necessary to fill in bits not covered by the HC prefix and the IEEE
802.15.4 short address.
- For short addresses, I personally prefer keeping as many contiguous
zeros as possible to make typing IPv6 addresses simpler. This may
seem like a minor nuisance, but the IPv6 addr arch did go through the
trouble of complementing the u/l bit.
2) If the bits contained by the HC prefix and the IID are greater than
128 bits, which takes precedence in the overlapping bits?
- I think the prefix must take precedence in case you want to assign
IPv6 addresses that do not follow the standard IID -> mac address
mapping. There currently is no requirement within IPv6 that says the
two have to map to each other. But we shouldn't disallow the case
where some bits of the IID happen to utilize the same value in the
link-layer address.
--
Jonathan Hui
On Mar 29, 2010, at 9:19 AM, Colin O'Flynn wrote:
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
