All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@web.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] Batman-adv gateways vs IPv6
Date: Tue, 15 Mar 2011 16:15:25 +0100	[thread overview]
Message-ID: <20110315151525.GA4987@Sellars> (raw)
In-Reply-To: <9B37313E-1B65-4D3F-BE01-1374D13681A8@online.de>

Hi Jan,

On Mon, Mar 14, 2011 at 01:39:51PM +0100, Jan Lühr wrote:
> Hello @all,
> 
> I'm new to batman - so, sorry if this was discussed already...
> 
> We're up to deploy batman-adv in an wireless mesh network with multiple routers / gateways providing access to the outside world. Furthermore deploying an IPv4 / v6 dual stack networking is one goals we're trying to archive.
> We stumbled up on batman-adv and its gateway feature, which looks quite promising. (http://www.open-mesh.org/wiki/batman-adv-gateways)
> However, since dhcp is used for implementing batman-adv gateways, this feature doesn't affect IPv6 ND / icmp6 - am I right?
Yes, that's right, the gateway feature only applies for DHCPv4/6.
And IPv6 ND / icmp6 is not being touched at all. Like ARP needs to
be done for IPv4, also still IPv6 needs to do IPv6 ND with all
hosts.

Also the IPv6 Router Advertisements, which I guess you were
indirectly refering to with the icmp6, are untouched, they are
still being flooded through the mesh. There were some ideas on how
a batman-adv gateway optimization could look like for that, based
on RFC4191, Router Preference, but some tests showed that the
Router Preference in Linux was not working as expected:
http://comments.gmane.org/gmane.linux.ipv6.usagi.users/2242

But do you actually need that, is there a difficulty with using
DHCPv6 in your use-case?

> 
> Having this in mind, what do you think is a suitable deployment strategy for IPv6 in batman-adv networks?
> Of course, assigning a single /64 to the mesh-cloud is a simple option, but icmp6 flooding might occur ...
As said previously, IPv6 ND will be needed anyway, so there's ICMP
flooding anyway. However that's rather low bandwidth traffic and
doesn't happen that frequently.

Could you describe your use-case a little further? So far no one
has noticed any constraints with that in practical setups, afaik.

> 
> Thanks,
> Jan
> 
> 

Cheers, Linus

  reply	other threads:[~2011-03-15 15:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-14 12:39 [B.A.T.M.A.N.] Batman-adv gateways vs IPv6 Jan Lühr
2011-03-15 15:15 ` Linus Lüssing [this message]
2011-03-15 15:38   ` Jan Lühr
2011-03-15 16:40     ` Jan Lühr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110315151525.GA4987@Sellars \
    --to=linus.luessing@web.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.