Subject: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing"

From: "Timothy J. Salo" <[email-masked]>
Date: Sat, 14 Jul 2007 14:00:39 -0500

Gabriel,

Thanks for the note.  Some questions and comments follow.

gabriel montenegro wrote:
> 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.

Gabriel is, of course, absolutely correct.  For various classes of
IPv6 addresses (e.g., non-link-local addresses and multicast addresses)
the 6lowpan format document simply cannot mandate that the link-local
portion of the IPv6 address is actually an 802.15.4 address -- it
doesn't make any technical sense.

Perhaps, the interesting issue is whether the 6lowpan format document
should specify that the link-local portion of IPv6 unicast addresses
assigned to 6lowpan hosts _must_ be derived from either the 64-bit or
16-bit addresses used by 802.15.4.

I can think of a few reasons why this might be undesirable:

o  It probably conflicts with the RFC 3041 privacy extensions

o  It may prohibit a host from having multiple IPv6 addresses (or, it
    might not, if the host requests multiple 16-bit addresses from
    the PAN controller)

o  It might prohibit a host from aliasing as another host

o  It might prohibit the specification of well-defined IPv6 addresses

Are there other reasons why this might be a bad idea?

On the other hand, it appears to me that requiring that IPv6 unicast
addresses within a PAN be created by using either the 64-bit or the
16-bit 802.15.4 addresses has some tremendous advantages:

o  It probably eliminates the need for duplicate address detection
    functionality, thereby simplifying efforts to emulate IPv6
    neighbor discovery functionality

o  It probably eliminates the need for address resolution functionality,
    thereby simplifying efforts to emulate IPv6 neighbor discovery
    functionality

o  It probably allows issues of link-local routing, neighbor
    reachability, and link-layer neighbor discovery to be addressed in a
    coordinated fashion.  It appears that a coordinated solution is much
    more likely to be well-adapted to highly resource-constrained
    networks, compared to attacking each of these topics individually (or
    trying to emulate IPv6 neighbor discovery for as many functions as
    possible).

Of course, I have a few other questions:

o  How important are RFC 3041 privacy extensions in 6lowpan networks?
    If this functionality is important, can some other technique be used
    to provide the same functionality (e.g., translate/scramble IPv6
    addresses at the border of the 6lowpan network)?

o  Is there a requirement that conflicts with using 802.15.4 addresses
    to form the link-local part of IPv6 addresses assigned to 6lowpan
    hosts?

o  Are there cases where it is technically infeasible to use 802.15.4
    addresses to form the link-local part of IPv6 addresses assigned to
    6lowpan hosts?

o  Have I missed something fundamental, and this is all really a bad
    idea?

> 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. ...
> Notice that the above is merely an optimization, and one applied to the 
> IPv6 header compression scheme.

Yes.  I am asking whether it should be required, rather than optional,
when it is possible.

> As such, it is orthogonal and independent to the mesh delivery support.

Yes.  But, should it be?

> We want that independence as
> the IPv6 header compression works only for IPv6, whereas the lowpan 
> layer (including the mesh delivery) works independently of the protocol
> being transported in this link. In other words, you could use the lowpan
> layer for IPv4, appletalk, or any other protocol.

I think it would be useful to discuss the use of IPv4 in 802.15.4,
rather than assume a particular technical solution in advance of
those discussions.  For example, given the highly resource-constrained
nature of these networks, it might make sense to use 802.15.4 addresses
within a 4lowpan network as network addresses, and then translate them
to [real] IPv4 addresses at the boundary of the network.  This would
enable a common routing protocol to be used for IPv4 and IPv6, and would
avoid having to create an IPv4 ARP function.

Does even Apple use AppleTalk anymore?  From
<http://en.wikipedia.org/wiki/AppleTalk>: "AppleTalk is a proprietary
suite of protocols developed by Apple Inc for computer networking. It
was included in the original Macintosh (1984) and is now deprecated by
Apple in favor of TCP/IP networking."

Or, maybe someone wants to run the OSI protocols over 802.15.4
networks...

It seems like we should talk about this some more, before we potentially
clutter up an 802.15.4 solution in order to potentially support dead
protocols such as AppleTalk.

> So your suggested wording below is not true in general,  but it may 
> apply in a meaningful subset of possible cases.

Or, I might be totally confused.  But, it seems like the approach I
propose could simplify, perhaps even dramatically, our task of
creating effective solutions for low-power wireless networks.

-tjs

_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: "Timothy J. Salo" <[email-masked]>
Date: Sat, 14 Jul 2007 17:06:20 -0500

gabriel montenegro wrote:
> Hi Tim,
> 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

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 14 Jul 2007 22:26:19 -0700

> 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.

> 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.

--
Jonathan Hui
[email-masked]

---

From: "Timothy J. Salo" <[email-masked]>
Date: Sun, 15 Jul 2007 21:56:23 -0500

> 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.

> 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

---

From: Jonathan Hui <[email-masked]>
Date: Sun, 15 Jul 2007 22:39:49 -0700

> devices and non-6lowpan IPv6 hosts seems to be a pretty important

True. Though I don't think any LoWPAN network will ever operate as a 
transit network for more capable networks. Thus, leaving 
interoperability in LoWPAN networks to imply that protocols and 
applications will actually process such large packets. I suspect very 
few, if any, will make use of the full minimum IPv6 MTU. The one 
exception is ICMP, but do we really expect LoWPAN nodes to generate ICMP 
errors to maximum sized packets?

> important, much less facilitate interoperability.

There are a class of applications that may require support for privacy 
extensions. One of the major issues with RFID is privacy. Like RFID, 
current or future LoWPAN application may associate a LoWPAN node with an 
item or person, making tracking possible without the users knowledge or 
consent. It's not that I'm a privacy advocate, but privacy tends to be a 
concern that slows or inhibits technology adoption and shouldn't be 
treated lightly. If we do decide to adopt the approach you suggest, then 
we should either provide a solution that satisfies privacy advocates or 
understand that we will face adoption hurdles in those applications.

> I recommend we make this change to the 6lowpan format document.

I agree with you that tying LoWPAN interface identifiers to 802.15.4 
addresses removes the need for both address resolution and DAD. If we 
are comfortable with dropping privacy extensions, then it will 
definitely lower the resource requirements of LoWPAN implementations. 
If privacy wasn't an issue, then I'm all for it. The key question is 
whether the lowered resource requirements outweigh the benefits of 
privacy extensions. While we could get concrete numbers for the former, 
the latter is a bit more difficult to quantify. Where on the tipping 
point do people think we lie? Are there other applications or use cases 
where arbitrary interface identifiers are desirable?

FYI, there is some work within LoWPAN to minimize ND costs in LoWPAN 
networks. Though I haven't had a chance to look at it in detail yet. 
http://tools.ietf.org/wg/6lowpan/draft-chakrabarti-6lowpan-ipv6-nd-03.txt

--
Jonathan Hui
[email-masked]

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 18 Jul 2007 09:44:03 +0200

Hi Jonathan

>errors to maximum sized packets?

[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...

>understand that we will face adoption hurdles in those applications.
[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.

I understand that a device could roll its 16-bit short address if it
really wanted to for privacy reasons, correct? 

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.

>http://tools.ietf.org/wg/6lowpan/draft-chakrabarti-6lowpan-ipv6-nd-03.t
xt

[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?

Pascal

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 18 Jul 2007 09:23:56 -0700

> 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.

> ownership like SeND does.

Agreed. Though some of the address security issues may be mitigated by 
link-layer security mechanisms.

> 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.

> the rest of the address, such as a CGA that we would define over 48 bits

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.

> 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-masked]

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 19 Jul 2007 11:24:25 +0200

Hi Jonathan

Pascal

>-----Original Message-----
>From: Jonathan Hui [mailto:[email-masked]]
>Sent: Wednesday, July 18, 2007 6:24 PM
>To: Pascal Thubert (pthubert)
>Cc: Timothy J. Salo; [email-masked]; [email-masked]
>Subject: Re: [RSN] Re: [6lowpan] "Link-Local Routing" versus
"Network-LayerRouting"
>sometimes we can't make certain assumptions even if they may have
[Pascal] :)

>these cases, nodes refuse to communicate to preserve privacy.

[Pascal] That's fine. If the burnin EUI64 address is used, we all agree
that DAD can be skipped or made very very optimistic.

>short addresses. But, maybe we should revisit this issue.
[Pascal] Yes, that's specifically what I'm discussing right now. If we
want to be open to some CGA or other privacy extension in the future and
still avoid DAD, then there is a need to change the draft before it's
too late. The proposal was that if we have a short address, we just lock
its position in the IID, and leave the rest open. That ensures the
uniqueness of the address and whatever game the nodes play in the future
with the 46 bits left will be backward compatible.

>unwanted constraints in the future.
[Pascal] You can not lock the draft because of early implementations,
can you?
Anyway, I'm don't see that I'm asking to change that? I'm just proposing
to leave the rest of the IID open to the node's support of various
upcoming features, as opposed to forcing the draft EUI48 format. 

At the moment, the draft still assumes that a PAN maps to a link, so the
PAN id in the IID is not necessary. If that assumption breaks later, we
can always define the PAN ID in the address at that time and be backward
compatible; IOW future nodes will be able to insert into a legacy
network which obeys the current draft limitation (1 PAN per link) and
will interact with legacy nodes that do not know better. 

OTOH, if the legacy nodes expect the PAN ID in the EUI 48 and do
something about it, they will never interwork with a newer device that
needs the bits for something else, e.g. CGA. Seems to me that we share
the objective is to prevent the nodes from making any unnecessary
assumption. So we should agree on this, do I miss something?

>extensions to ND at the router.
[Pascal] Things like MLD can be snooped in a switch, and there has been
some effort in the past for ND proxy. Depending on how things are done,
such things could happen for 6LowPAN or not. We might make it a goal or
a non goal. Your answer makes it a non goal. I'm fine with that, I just
wanted to make it clear to the lists that there was an option there.

Pascal