Subject: [6lowpan] draft-ietf-6lowpan-nd-14 Address Resolution

From: Luis Maqueda Ara <[email-masked]>
Date: Mon, 6 Dec 2010 14:52:22 +0100

Hi everyone,

First of all, I would like to apologize in advance if this is not the right place to ask my questions or if this topic has been mentioned in a previous thread, but I didn't find one that addresses my doubts.

I have read several times section 5.7 (Address Resolution) of the draft-ietf-6lowpan-nd-14 document, but the way Address Resolution is performed is not completely clear to me. I have quoted here the whole section divided in bits that I have commented, accordingly with my understanding of them and posted two final question that remains unsolved to me. I would really appreciate if you could give me your feedback and suggestions for my comments and questions:

> 	The address registration mechanism and the SLLA option in Router
>    Advertisement messages provide sufficient a priori state in routers
>    and hosts to resolve an IPv6 address to its associated link-layer
>    address.  

As I understand from the document, this address registration mechanism registers hosts with routers and vice-versa, but it does not register hosts with hosts. 

> As all prefixes but the link-local prefix are always
>    assumed to be off-link, multicast-based address resolution between
>    neighbors is not needed.
> 

This paragraph is also confusing to me. As I understand, the reason why multicast-based address resolution is not needed is that the link-local prefix is on-link. If I am right, I guess that I just  have problems with the way this paragraph is formulated, which is a bit unclear. 

>    	Link-layer addresses for neighbors are stored in Neighbor Cache
>    entries [RFC4861]. 

According to this section and to several places along the whole document, I clearly understand how host create NCE storing router's  information. I also understand the process in which a router creates a NCE due to the registration mechanism. However, I would like to know whether a host might create a NCE for another host at any moment and, how that situation would be if that is the case.

>  In order to achieve LoWPAN compression, most
>    global addresses are formed using a link-layer address.  Thus a host
>    can minimize memory usage by optimizing for this case and only
>    storing link-layer address information if it differs from the link-
>    layer address corresponding to the Interface ID of the IPv6 address
>    (i.e., differs in more than the on-link/global bit being inverted).

Thus, after going through the draft, important questions that remain unsolved to me are:

a) How does a host send a packet to another neighboring host?
b) Should hosts maintain NCEs for other hosts? If so, under which circumstances would these NCEs be created?

Thank you in advance and best regards,

Luis Maqueda

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 6 Dec 2010 15:21:34 +0100

Hi Luis,

thanks for bringing this question to the mailing list.  Specifications are sometimes like trapdoor functions:  If you already know what's in there, they are quite clear, but it is difficult to find an answer to a question.  Maybe we can add some more explanatory text.

> a) How does a host send a packet to another neighboring host?

6LoWPAN-ND doesn't give you this capability.
As you cited, all addresses are considered off-link, so you always go through a router.

> b) Should hosts maintain NCEs for other hosts? If so, under which circumstances would these NCEs be created?

Corollary: The answer is no.

Why is this a sensible approach?  Of course, it is a design decision, with the usual trade-offs.  The rationale is approximately:

If a node is capable of maintaining relationships to multiple other nodes, it might as well be a router.
The routing protocol will provide a way to maintain neighborhood relationships that is more powerful than the simplistic 6LoWPAN-ND.
(Note that being a router does not have to mean that you accept packets that are actually routed through you -- it just means you participate in routing.  E.g., in RPL, there is a concept of a "leaf node".)

Really simple nodes restrict themselves to a host role.  They use 6LoWPAN-ND (and, in particular, NUD) to maintain a default-router relationship to a router (or possibly two or three routers, if desired for additional robustness).  They use their default router to talk to other hosts.

There may be 6LoWPANs that do not have any host-only nodes. (According to various IETF hallway discussions, this model appears to a preferred model for some, but not all RPL advocates.)  Router nodes may still use 6LoWPAN-ND in their bootstrapping processes, as well as a mechanism to talk to hosts (if they want to provide forwarding services for those).

Gruesse, Carsten