Pascal Thubert (pthubert) wrote:
[Pascal] Who knows? One might use a disseminated sensor network as
access for some signaling, or limited upstream when no other medium is
available. If we do not need that assumption, let's not make it...
Looks like we both agree. My point throughout this thread was that
sometimes we can't make certain assumptions even if they may have
significant advantages.
[Pascal] Agreed. I understand that we decide which formats do not need
DAD (those described in the draft) and decide that those are ever DADed,
or are optimistically DADed. But that does not secure the address
ownership like SeND does.
Agreed. Though some of the address security issues may be mitigated by
link-layer security mechanisms.
I understand that a device could roll its 16-bit short address if it
really wanted to for privacy reasons, correct?
Correct. But the availability of a short address depends on the
configuration of the link-layer. According to the IEEE 802.15.4 spec, a
PAN coordinator is not obligated to dole out 16-bit short addresses. I
don't know how often we see this in practice, and maybe its okay if, in
these cases, nodes refuse to communicate to preserve privacy.
If so, what I'd suggest is that when the u/l bit is set to local, we
force the 16 bits at a given place, say the last bits of the address,
and leave the rest up to the device. That way, DAD is not necessary and
the specification is still open for the device to do what it likes with
the rest of the address, such as a CGA that we would define over 48 bits
instead of 64.
The current 6LoWPAN format draft suggests that interface identifiers
derived from short addresses is done similar to RFC2464, by creating a
48-bit Ethernet-style address using the PAN ID and short address. So it
doesn't support creating any form of CGA with a well-defined mapping to
short addresses. But, maybe we should revisit this issue.
In general, I am in agreement with Timothy Salo's proposal. Correct me
if I'm wrong, but most, if not all, current 6LoWPAN implementations
assume that the interface identifier and link address (16 and 64-bit)
have a one-to-one mapping, including the Arch Rock implementation. It
does reduce resource requirements in energy and code. I'm playing a bit
of devil's advocate here to vet out that such an assumption don't cause
unwanted constraints in the future.
[Pascal] It seems fair to believe that the coordinators and FFDs will
end up proxying ND and some routing for the RFDs, which this draft
proposes. At the moment, the IPv6 routers do not talk 6LowPAN and
there's a gateway that interconnects say, Ethernet and 802.15.4. Should
there be a specific 6LowPAN ND support in the router? And can we define
that functionality so that it can be proxyed/snooped in the gateway?
I believe there should be 6LoWPAN support in routers. It is a better fit
architecturally - it is where router-specific ND mechanisms are intended
to be implemented. It can also open doors for 6LoWPAN specific
extensions to ND at the router.
--
Jonathan Hui
[EMAIL PROTECTED]
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
