gabriel montenegro wrote:
> Hi Tim,
>
> There is an incorrect assumption in the message below:
>
> The 6lowpan "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"
> draft specifies that the link-local portion of an IPv6 address is
> actually the 64-bit or 16-bit [link-layer] address used by 802.15.4.
>
> 6lowpan does not mandate such a relationship. It only says that if it
does in fact exist, then here is how to take advantage of it. The fact
> that this is not being mandated
> should be evident from the text in section 10.1: ...
Having thought about this a bit more, a few additional comments follow
about whether the 6lowpan format document should mandate that the IPv6
addresses of devices on a 6lowpan network _must_ be derived from
802.15.4 64-bit or 16-bit addresses.
The 6lowpan format document includes the following language:
6. Stateless Address Autoconfiguration
This section defines how to obtain an IPv6 interface identifier.
The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may
be based on the EUI-64 identifier [EUI64] assigned to the IEEE
802.15.4 device. ...
All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
addresses (Section 3 and Section 12) are also possible. In these
cases, a "pseudo 48-bit address" is formed as follows. ...
A different MAC address set manually or by software MAY be used to
derive the Interface Identifier. ...
So, if I understand correctly, an IPv6 interface identifier created by
an implementation of the 6lowpan format specification can be pretty much
any arbitrary string of bits of the appropriate length. This appears
to me to imply that either:
The 6lowpan specifications should explicitly require every conforming
6lowpan implementation to implement duplicate address detection and
address resolution functionality analogous to that specified in the
IPv6 neighbor discovery protocols. This is because a 6lowpan
implementation must (it would seem) be capable of operating in a
6lowpan network in which one or more devices are using arbitrary
interface identifiers. This appears to me to conflict with the
objective of creating a solution for 802.15.4 networks that requires
a small memory footprint. I also suspect that, given that many
6lowpan devices will sleep most of the time, a general duplicate
address detection mechanism is unlikely to work (unless, of course,
the duplicate address detection mechanism wakes up every sleeping
device and asks it if its address is a duplicate...).
or,
Implementations that conform to the 6lowpan specifications are not
assured to interoperate. This is because a device that doesn't
implement IPv6-like duplicate address detection and address
resolution functionality can't be assured of interoperating with
devices that create arbitrary interface identifiers. Note that
non-interoperable conforming implementations appear to be
acceptable to some standards communities, but I don't think this
approach should be acceptable to the IETF.
Alternatively, the 6lowpan format document could _require_ that
IPv6 interface identifiers be derived from either 64-bit or 16-bit
802.15.4 addresses. This would enable us to avoid requiring every
6lowpan device to implement IPv6-like duplicate address detection
or address resolution functionality (or accept that conforming
implementations may not interoperate).
Is it technically feasible to require that 6lowpan devices
derive IPv6 interface identifiers from 802.15.4 64-bit or
16-bit addresses?
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?
Should the 6lowpan format specification require that IPv6 interface
identifiers be derived from 802.16.4 addresses?
Or, have I simply missed the point somehow?
-tjs
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
