On Apr 18, 2006, at 11:42 PM, Geoff Mulligan wrote:
On Tue, 2006-04-18 at 23:33 -0500, Timothy J. Salo wrote:
Subject: Re: [6lowpan] Working Group Charter
From: Geoff Mulligan <[EMAIL PROTECTED]>
Date: Tue, 18 Apr 2006 22:20:32 -0600
What do you mean "that we have no intention of actually implementing
IPv6 in wireless PANs". We have every intention of implementing
IPv6 in
wireless PANs!
The working group arguably isn't implementing IPv6 from two
perspectives:
o I don't think the IETF accepts the notion that implementing
a subset of IPv6 is actually implementing IPv6. But, I could
be wrong. I may ask this on question on the main IETF mail list.
Having said that, the working group intends to implement
only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc).
Too bad that we have to rehash this again because you are coming
late to
this discussion. We dealt with this issue already and the IESG said
that an implementation that did not include IPsec and the like was
still
an implementation of IPv6.
o The protocol described in the format specification is not
IPv6. If you fed it into an IPv6 stack, nothing good would
happen. It is, however, a protocol that can easily be
transformed into [a subset of] IPv6.
If you do not use header compression then an IPv6 packet in the
payload
of the 6lowpan frame format will work perfectly fine and everything
good
will happen. The 6lowpan compressed headers are never intended to be
passed uncompressed out of a 6lowpan.
I might be, as Geoff puts it, merely rehashing old arguments, and if
so, I apologize.
I don't think there's any question as to whether you can implement
IPv6 on 802.15.4. It's a link layer, after all. Sure, the headers
might be big, but you can compress them, etc. Even IPSec is possible;
without hardware support, it might be an energy nightmare and your
crypto time might be the throughput bottleneck, but it's possible,
and hardware support could make it not a big deal.
If you take the IPv6 over 15.4 route (no pun intended), under the
assumption of low-power embedded devices, I'd argue that it's not the
data plane that changes, but rather the control plane. E.g., many
existing IP routing approaches become problematic, predominantly due
to the fact that the assume any-to-any connectivity as an end goal,
while in PANs this is less commonly the case. I think this gets to
the point raised earlier, of whether the group considers 802.15.4
networks being used as transmit networks, which is a very very
important consideration.
Coming from the world of TinyOS and sensor networks, I'd argue that
it's pretty clear that a set of protocols and mechanisms enabling IP
devices to directly communicate with PAN devices would be very useful
(why I'm here). The most common case for this is management, as it's
a situation where a user definitely wants to talk to a specific
*node*, i.e., an address, rather than use some other naming scheme
(e.g., "the lights in the living room"). The advantage that a direct
IP-level protocol transcoder would provide is that it would preclude
the need for application-level protocol stacks to even communicate
with nodes within a network. Furthermore, you can begin to use all of
the basic IP tricks and techniques when managing these networks
(e.g., firewalls).
That being said, if the plan is not to push IPv6 into the PAN, then
this raises the simple question of what L3 protocols will run within
the PAN.
Phil
http://csl.stanford.edu/~pal
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
