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

["Timothy J. Salo" <[e-mail]>]

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


_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan