Subject: [6lowpan] 6lowpan-ND: host-to-router interaction

From: Jan Kramer <[email-masked]>
Date: Tue, 01 Feb 2011 14:54:03 +0100

Hello all,

I'm currently implementing a 6LoWPAN-stack and I have few questions 
about draft-ietf-6lowpan-nd-15.

1.) I'm not quite sure, which address has to be set in the Target 
Address field of the Neighbor Solicitation message a hosts sends to a 
router.
Do I have to set the address, the host is about to register, in this field?
If it has to be that way, does the router register the source address of 
the IP header or the target address of the Neighbor Solicitation?

2.) How do the flags in a Neighbor Advertisement have to be handled?
I guess a router will set the R (router) flag, if it sends a NA + ARO to 
a host.
But will it set the S (solicited) or the O (override) flag? Or do the 
hosts don't care about them anyway?

3.) Do hosts have to proccess unicast Neighbor Solicitations and respond 
with Neighbor Advertisements, if they're not sleeping.

4.) If a router gets a packet destined to one of its registered hosts, 
does it always have to cache the packets until this host re-registers 
its address to the router? Or is there any way to let the router check, 
whether the host is awake and forward the packet immediately? Maybe send 
a unicast NS?

Greetings

Jan

--------------------------------------------------------------
Jan Kramer                                    Coalesenses GmbH
Phone:  +49 451 883695-14                Maria-Goeppert-Str. 1
                                                   23562 Lübeck
[email-masked]  www.coalesenses.com            Germany
--------------------------------------------------------------
Geschäftsführer/Managing Director:  Dr.-Ing. Carsten Buschmann
Sitz/Registered office: Lübeck
Handelsregister/Register Court: Amtsgericht Lübeck, HRB 6109HL
--------------------------------------------------------------

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 1 Feb 2011 14:35:49 -0000

Hello,

The answers to your question are in RFC4861, which 6lowpan-nd extends. So
you really need to read RFC4861 before 6lowpan-nd, and I'm sure that will
reference some other RFCs too. But briefly to answer your specific
questions:

>1.) I'm not quite sure, which address has to be set in the Target...

The target address is the address of the router being sent the NS. The
router replies with an NA, so it MUST have the router's address.

>2.) But will it set the S (solicited) or the O (override) flag?...

>From RFC4861:
	S              Solicited flag.  When set, the S-bit indicates that
                     the advertisement was sent in response to a
                     Neighbor Solicitation from the Destination address.
                     The S-bit is used as a reachability confirmation
                     for Neighbor Unreachability Detection.  It MUST NOT
                     be set in multicast advertisements or in
                     unsolicited unicast advertisements.

      O              Override flag.  When set, the O-bit indicates that
                     the advertisement should override an existing cache
                     entry and update the cached link-layer address.
                     When it is not set the advertisement will not
                     update a cached link-layer address though it will
                     update an existing Neighbor Cache entry for which
                     no link-layer address is known.  It SHOULD NOT be
                     set in solicited advertisements for anycast
                     addresses and in solicited proxy advertisements.
                     It SHOULD be set in other solicited advertisements
                     and in unsolicited advertisements.

> 3.) Do hosts have to proccess unicast Neighbor Solicitations and
respond...

To match RFC4861, yes they would have to.

> 4.) If a router gets a packet destined to one of its registered hosts...

This is more to do with the routing layer/protocol. Bare IPv6 wouldn't
handle this, and you would just forward the packet immediately, assuming the
node in question is awake.

It may be your IPv6 router layer handles this, or your 802.15.4/MAC layer
handles sleeping. Or you have some other solution, but either way it's
outside of 6LoWPAN-ND.

It's worth looking how other people have done 6LoWPAN/IPv6 to answer a lot
of these questions to. There is a number of stacks out there, including
Contiki, TinyOS's IPv6 stack, and I have a stack called 'fip'
(http://www.newae.com/fip) which is a work in progress.

Warm Regards,

  -Colin O'Flynn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jan Kramer
Sent: February 1, 2011 1:54 PM
To: [email-masked]
Subject: [6lowpan] 6lowpan-ND: host-to-router interaction

Hello all,

Greetings

Jan

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan