Jonathan Hui wrote:
Timothy J. Salo wrote:
Is there a requirement that 6lowpan devices be able to create
arbitrary IPv6 interface identifiers? Or, was this feature
simply included because it seemed like a good idea at the time?
I don't think there is any explicit requirement for nodes using
arbitrary interface identifiers. Though I do think that when the format
doc was drafted, it was meant to support IPv6 with a minimal set of
constraining assumptions. One obvious example is support for the minimum
IPv6 MTU. While its unlikely that we'll see LoWPAN nodes transmitting
relatively large datagrams, the support for the full minimum IPv6 MTU
was included as part of the LoWPAN format specification. Many would
argue that this adds non-trivial complexity.
Support for the minimum IPv6 MTU enables 6lowpan devices to interoperate
with traditional IPv6 hosts. Ensuring interoperability between 6lowpan
devices and non-6lowpan IPv6 hosts seems to be a pretty important
objective.
Arbitrary link-local interface identifiers, on the other hand, do not
appear to provide any benefits that are nearly so fundamental. Perhaps
they are useful in some circumstances (although I haven't heard what
these circumstances might be) but they don't appear to be really
important, much less facilitate interoperability.
Should the 6lowpan format specification require that IPv6 interface
identifiers be derived from 802.16.4 addresses?
I wouldn't go as far as to limit LoWPAN nodes to using only interface
identifiers derived from link addresses. Rather, I would prefer an
approach where DAD and link address resolution is not required for IPv6
addresses with interface identifiers that have universal scope (i.e. u/l
bit set to one). DAD would still be required IPv6 addresses with local
scope interface identifiers. The main advantage of this approach is that
it would be possible for nodes using only global scope interface
identifiers to avoid implementing any form of DAD and be completely
agnostic to whatever LoWPAN DAD approach is defined. It would just need
to route the packets between nodes participating in the DAD protocol. I
would also go as far to say that interface identifiers derived from
802.15.4 short addresses also do not require DAD, as it is assumed that
lower layers will enforce the uniqueness of the short address within the
PAN. For nodes that do want to use arbitrary local scope interface
identifiers (e.g. for privacy), then they would be burdened by the extra
support required for DAD. This follows the "pay-as-you-go" spirit of the
LoWPAN format, where only nodes that utilize more "advanced"
functionality carry most of the extra costs.
I believe that if the 6lowpan format document permits the use of
interface identifiers that are _not_ derived from 64-bit or 16-bit
802.15.4 addresses, then _every_ 6lowpan device must implement a
IPv6-like address resolution capability. This is because, even
though a device may derive its own interface identifier from
an 802.15.4 address, the device might be connected to a network in
which other devices create arbitrary interface identifiers. That
is, every 6lowpan device must be prepared to resolve arbitrary
interface identifiers used by other 6lowpan devices. On the other
hand, any 6lowpan node that wishes to communicate with a 6lowpan
device that uses an arbitrary interface address must execute an
IPv6-like address resolution function. This function will involve
additional network traffic and probably additional stored state (to
cache address resolution information to avoid unnecessary network
traffic). Of course, a 6lowpan device won't know until it connects
to a network whether it will need to use this IPv6-like address
resolution capability, and so every 6lowpan device must implement
this functionality just in case.
(I assume that interface identifiers derived from 802.15.4 addresses can
be resolved to 802.15.4 addresses without any additional network traffic
or stored state. I also assume, but haven't verified, that 16-bit
802.15.4 addresses can be used directly, and don't need to be resolved
to 64-bit 802.15.4 addresses.)
It appears to me that restricting 6lowpan interface identifiers to
those derived from 64-bit and 16-bit 802.15.4 addresses is a really
big win. First, this restriction would eliminate the need for _every_
6lowpan device to implement an IPv6-like address resolution function,
thereby reducing the minimum memory footprint of all 6lowpan
implementations. Second, this restriction would eliminate the
possibility that any 6lowpan device would ever need to use an IPv6-like
address resolution capability, thereby avoiding (what to my mind is)
unnecessary additional network traffic and state storage.
- - - -
As Jonathan points out, the issue of duplicate address detection (DAD)
is far less clear (well, at least to me). I understand that any 6lowpan
device that creates only interface identifiers in which the
Universal/Local (U/L) bit is set (to indicate that the identifier is
globally unique) will not need to implement DAD functionality. This
leaves 6lowpan devices that create interface identifiers in which the
U/L bit is zero. These include arbitrary, not-globally-unique
interface identifiers, as well as interface identifiers derived from
16-bit 802.15.4 addresses. However, as I note below, making DAD
actually work for these devices could be non-trivial.
It appears to me that restricting 6lowpan interface identifiers to those
derived from 64-bit and 16-bit 802.15.4 addresses will eliminate the
need for any 6lowpan device to implement a duplicate address detection
capability. Interface identifiers derived from (globally unique)
64-bit 802.15.4 [MAC] addresses are assured to be globally unique.
I assume that we can rely upon the 802.15.4 PAN controller to ensure
that 16-bit 802.15.4 addresses are unique within the PAN.
The part I don't understand is how DAD will work when:
1. A 6lowpan device might create an arbitrary interface identifier that
is the same as a 16-bit 802.15.4 address (assuming that the PAN
identifier is zero or unknown). Clearly the device creating an
arbitrary interface identifier must execute a DAD procedure. But,
what about another device that later joins the network and derives
its interface identifier from a 16-bit 802.15.4 addresses? Does
it need to execute a DAD procedure? Of course, that raises the
small question of what the device could possible do, if it detects
a collision. Perhaps, ask the PAN controller for another 16-bit
802.15.4 address? Or, maybe we should simmply assume that no
implementor will ever use small integers as arbitrary interface
identifiers...
2. An arbitrary interface identifier might conflict with the interface
identifier of a device that is currently sleeping (which, in some
networks might be most of the devices most of the time). Are we
going to develop a DAD algorithm that assumes that most of the
potentially conflicting devices might be sleeping most of the time?
I think that the loss of functionality that results from restricting
6lowpan interface identifiers to 64-bit and 16-bit 802.15.4 addresses
is minimal (and might even be null), but the benefits are substantial.
I recommend we make this change to the 6lowpan format document.
-tjs
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
