Re: [Contiki-developers] WSN border router in LAN environment-discovery

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

radvd configures all the windows boxes with the ipv6 prefix assigned to its 
eth0 interface. Then all ipv6 packets from windows go to the radvd box, and 
on to the internet if it has ipv6 connectivity, e.g. a sixxs tunnel. With 
the jackdaw plugged into the radvd box you assign aaaa::1/64 to the RNDIS 
interface and have radvd send RAs; they go out 6lowpan and configure the 
contiki nodes.  Any reference to aaaa:: goes out the jackdaw interface, and 
NS/NA will operate to show neighbors.

With rpl the NS/NA/RA's are ignored so you need to some other way to pass 
the prefix and find the connected nodes.  Slip passes a prefix with a ?P !P 
interchange so the prefix does not have to be hard coded like it is for the 
jackdaw border router. aaaa::/64 packets are routed to the tun0 or rndis 
interface as before, and arp is turned off so no NS/NA will go to the border 
router; if the unicast  destination is in the border router route table it 
will go out. Again, if you can reach it from linux you can automatically 
reach it from any lan or wan request.

But I don't know what happens if the linux box is not the default ipv6 
route. It may advertise the aaaa::/64 prefix through the lan, I think I have 
seen that.

-----Original Message----- 
From: Maciej Wasilak
Sent: Saturday, September 24, 2011 4:17 PM
To: Contiki developer mailing list
Subject: Re: [Contiki-developers] WSN border router in LAN 
environment-discovery

Thanks for your replies.

David: I'm not sure if I understand correctly, but will the PC's on the 
network be able to contact RPL nodes automatically? If not, maybe the static 
routes are necessary like Mohammad says. But I don't know if searching 
static routes happens before checking if destination is on-link.

Jon: it seems that radvd uses RFC 4191 (it wouldn't be possible to advertise 
a default route without it). If I understand it right, in your setup Linux 
hosts receive RFC 4191 Router Advertisments and insert default route into 
their routing tables. According to Microsoft, Windows hosts also should 
understand it. Therefore it's safe to assume that RFC 4191 is a standard 
now. It shouldn't be hard to implement it in Contiki.

Last thing I wonder is if it's possible to determine what is the next free 
subnet in some automatic way.

Best Regards
Maciek

2011/9/20 jon...@gm... <jon...@gm...>

On Tue, Sep 20, 2011 at 8:16 AM, Mohammad Abdellatif
<moh...@gm...> wrote:
> i think this is really the easiest way.. :)
> another harder way would be to enable ip forwarding on the linux machine
> "with the border router connected" and then add a static route on the 
> other
> machines to the rpl network through the linux ethernet interface.

You shouldn't need to add static routes.
http://www.dslreports.com/forum/r25832421-Multiple-IPv6-routers-on-LAN

>
> Mohammad Abdellatif
> Phd student at Faculty of Engineering University of Porto (FEUP)
> Researcher at Inesc Porto, UTM, WiN
> http://win.inescporto.pt/mma
>
>
>
> On Sun, Sep 18, 2011 at 10:09 PM, David Kopf <da...@em...> 
> wrote:
>>
>> The easiest way is to have a linux box as the switch and router, then
>> radvd will handle everything. Plug the rpl border router into
>> that and it will pick up its assigned prefix and advertise it through 
>> rpl.
>>  radvd autoconfigures all your devices and routes between
>> its local interfaces and the internet.  RPL nodes could perhaps
>> periodically send packets to some well known address that the linux
>> box can use to keep a list of the active ones and perhaps enter the names
>> in the hosts file.
>>
>> Don't know what happens when you introduce another ip6 router.
>>
>>
>>
>> -----Original Message-----
>> From: Maciej Wasilak
>> Sent: Sunday, September 18, 2011 4:39 PM
>> To: Contiki developer mailing list
>> Subject: [Contiki-developers] WSN border router in LAN environment
>> -discovery
>>
>> Hello,
>>
>> I would like to ask your opinion about the theoretical home LAN setup: a
>> Contiki-based WSN border router plugged into a switch with
>> a home router (switch and home router might be in the same device), and
>> some number of PC's or smartphones. Border router has some
>> nodes on its 802.15.4 side and uses RPL (with no other IPv6 ND or
>> 6lowpan-ND functionality). PC's use Linux/Windows (powerful OS
>> with its own routing tables), smartphones use Android or other OS (also
>> powerful but not as much).
>>
>> The problem is how to make the devices in LAN discover the WSN border
>> router without disrupting their communication with internet. I
>> am thinking about two scenarios:
>>
>> 1) RFC4861 + RIPng - WSN border router sends standard Router
>> Advertisements. Home router does the same. Hosts are not able to
>> recognize which router is better for WSN or Internet. It is possible to
>> implement some simple routing protocol like RIPng - the
>> Contiki border-router should be powerful enough to run it. When hosts 
>> send
>> internet traffic WSN border router, it should send a
>> Redirect pointing to the home router. Similarly the home router should
>> redirect the WSN traffic to the WSN border router.
>>
>> 2) RFC4861 + RFC4191 (+ RIPng) - WSN border router sends modified Router
>> Advertisements with Route Information Option containing RPL
>> prefix. Home router also sends Router Advertisements with Route
>> Information Option containing default prefix ::/0. Both advertise
>> themselves as default routers (so that if one of them fails, the other 
>> one
>> still works) and with medium priority (WSN and Internet
>> don't overlap, so priority is useless). Hosts should immediately know
>> where to send their traffic - no redirects should happen. To
>> redirect traffic from WSN to Internet RIPng is still necessary.
>>
>> My question is which of these tactics has a better chance of working?
>>
>>
>>
>> ------------------------------------------------------------------------------
>> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>> http://p.sf.net/sfu/rim-devcon-copy2
>> _______________________________________________
>> Contiki-developers mailing list
>> Con...@li...
>> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1

> _______________________________________________
> Contiki-developers mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>
>

--
Jon Smirl
jon...@gm...

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1

_______________________________________________
Contiki-developers mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/contiki-developers

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2

_______________________________________________
Contiki-developers mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/contiki-developers 