Subject: [6lowpan] SLLA option in NS

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 26 May 2010 15:21:50 -0700

Hi All,

According to the current 6lowpan-nd draft, I have one question.

The draft mentioned NS must include SLLA option in order to inform the link-layer address of the host. However when the router receives RS message from the host, the router responds RA to the host. At that time, the router needs to know the link-layer address of the host in order to send out RA to the host. So, I think SLLA option of the host must be included in RS instead of NS.

According to the current ND draft, after receiving RS message, the router sends NS message in order to solve the link layer address of the host by using solicited node multicast address. In order to eliminate the multicast packet as much as possible, I recommend to include SLLA option in RS instead of NS.

Thanks,
Tetsuya Murakami

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 26 May 2010 19:23:31 -0700

Hi Tetsuya,

> 
> The draft mentioned NS must include SLLA option in order to inform the
link-
> layer address of the host. However when the router receives RS message
from
> the host, the router responds RA to the host. At that time, the router
needs
> to know the link-layer address of the host in order to send out RA to the
> host. So, I think SLLA option of the host must be included in RS instead
of
> NS.

[SC>]   6lowpan-nd section 5.2 refers to Section 6.3.7 of rfc4861 for
sending RS. Rfc4861
        States that an implementation SHOULD include SLLA option with RS
when the src ip address is not an un-specified address.

However, your point is taken and we will discuss this among the co-authors.

> 
> According to the current ND draft, after receiving RS message, the router
> sends NS message in order to solve the link layer address of the host by
> using solicited node multicast address. In order to eliminate the
multicast
> packet as much as possible, I recommend to include SLLA option in RS
instead
> of NS.
[SC>] Actually, if the implementation allows, a router may figure out the
link-layer address of the sender of RS from the RS packet(MAC header) and
resolve the link-layer address that way. 

However, in case of 6lowpan devices it might make sense to expect the SLLA
option with RS request in order to save some extra processing to figure out
from MAC header.
[SC>] 

Thanks,
-Samita

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 30 May 2010 06:13:46 -0700

On 05/26/10 03:21 PM, Tetsuya Murakami wrote:
> The draft mentioned NS must include SLLA option in order to inform
> the link-layer address of the host. However when the router receives
> RS message from the host, the router responds RA to the host. At that
> time, the router needs to know the link-layer address of the host in
> order to send out RA to the host. So, I think SLLA option of the host
> must be included in RS instead of NS.

We should make it clear that the SLLA is required in the RS.
FWIW the ability to omit them in RFC4861 is for the case of sending a RS 
before DAD has completed, in which case RFC4861 allows an unspecified 
source address in the RS. We don't need that for 6lowpan.

But we still need SLLA in the NS, since it is the SLLA plus the ARO that 
are used to form the registration with the router.

> According to the current ND draft, after receiving RS message, the
> router sends NS message in order to solve the link layer address of
> the host by using solicited node multicast address. In order to
> eliminate the multicast packet as much as possible, I recommend to
> include SLLA option in RS instead of NS.

I don't think there is anything in 6lowpan-nd-09 that says that the 
router should multicast a NS in this case. (RFC 4861 implementations 
might do that, or might instead multicast the RA to all-nodes.)
Do you  have a pointer to specific text in 6lowpan-nd-09 that says this, 
or that isn't sufficiently clear on never sending multicast NS?

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 31 May 2010 10:35:40 +0200

OTOH, 

oDAD (RFC 4429) has it that:

   * Never using an Optimistic Address as the source address of a Router
        Solicitation with a SLLAO.  Another address, or the unspecified
        address, may be used, or the RS may be sent without a SLLAO.

What the new ND is doing is making a superOptimistic address out of
EUI-64 based addresses that would bypass even oDAD's limitations.

For addresses for which there is no way to be absolutely sure that
there's no dup, it still makes sense to apply oDAD.

That will be more efficient if the draft enforces that the routers place
the SLLA option in their RAs, because otherwise, the optimistic device
has no way to learn the router LLA.

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Erik Nordmark
> Sent: Sunday, May 30, 2010 3:14 PM
> To: Tetsuya Murakami
> Cc: [email-masked]
> Subject: Re: [6lowpan] SLLA option in NS
> 
the
> > link-layer address of the host. However when the router receives RS
> > message from the host, the router responds RA to the host. At that
> But we still need SLLA in the NS, since it is the SLLA plus the ARO
that are
> used to form the registration with the router.
> 
router
> should multicast a NS in this case. (RFC 4861 implementations might do
that,
> or might instead multicast the RA to all-nodes.) Do you  have a
pointer to
> specific text in 6lowpan-nd-09 that says this, or that isn't
sufficiently clear on
> never sending multicast NS?
> 
>     Erik
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 31 May 2010 05:39:34 -0700

> there's no dup, it still makes sense to apply oDAD.

I don't see how the additional complexity of oDAD makes anything 
different in 6lowpans; as I stated in an earlier email I think it is 
impossible to detect duplicate EUI-64's in a 6lowpan.

> has no way to learn the router LLA.

Good point - we need to require the inclusion of the SLLA option in RAs.

    Erik

---

From: Zach Shelby <[email-masked]>
Date: Mon, 31 May 2010 23:23:03 +0300

> Good point - we need to require the inclusion of the SLLA option in RAs.

Yep, I will add that to the existing ticket about SLLAs. 

Thanks,
Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297