From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: stephan.gatzka@gmail.com, "Waskiewicz Jr,
Peter P" <peter.p.waskiewicz.jr@intel.com>,
linux1394-devel@lists.sourceforge.net, netdev@vger.kernel.org,
davem@davemloft.net, YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Subject: Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
Date: Mon, 21 Jan 2013 21:32:53 +0900 [thread overview]
Message-ID: <50FD3575.1060303@linux-ipv6.org> (raw)
In-Reply-To: <20130121092806.3c741bd2@stein>
Stefan Richter wrote:
> b) RFC 2734 MCAP (Multicast Channel Allocation Protocol): currently not
> implemented; not sure if needed (I see a few big downsides to using
> per-multicast-group channels); not sure if networking core support
> would be needed for this
It is definitely needed because we need to listen on multicast group
for NDP, which might have already had its own channel.
MCAP sends "multicast group address", which is whole IP address.
In IP stack we only manages listening groups by special
"link-layer address" mapped by device specific transform function.
See net/ipv6/ndiscc:ndisc_mc_map() for IPv6.
I am proposing to extend MAC address to 16 bytes long so that we can
"map" whole IPv6 address into the "MAC".
On tx on fwnet, it can determine if the destination is multicast or not
by either by
- Checking protocol, and looking into protocol dependent multicast
range
or
- Checking "EUI-64" group bit (here, we assume all node do not set it
in its unique Id, and we map IPv6 multicast and IPv4 multicast in
special way; e.g.
ff00::/8 (which has "multicast bit" set)
0100::/96 (which is also "multicast bit" set)
--yoshfuji
next prev parent reply other threads:[~2013-01-21 12:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-20 17:52 [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information Stephan Gatzka
2013-01-20 18:47 ` YOSHIFUJI Hideaki
2013-01-20 21:23 ` Stephan Gatzka
2013-01-21 2:29 ` YOSHIFUJI Hideaki
2013-01-21 6:25 ` Stephan Gatzka
2013-01-21 7:39 ` Stefan Richter
2013-01-21 11:50 ` YOSHIFUJI Hideaki
2013-01-21 19:25 ` Stephan Gatzka
2013-01-21 19:57 ` YOSHIFUJI Hideaki
2013-01-21 21:16 ` Stephan Gatzka
2013-01-27 14:43 ` Stefan Richter
2013-01-27 17:21 ` Stephan Gatzka
2013-01-27 18:20 ` Stephan Gatzka
2013-01-27 18:25 ` YOSHIFUJI Hideaki
2013-01-27 19:28 ` YOSHIFUJI Hideaki
2013-01-27 23:26 ` Stefan Richter
2013-01-21 11:50 ` YOSHIFUJI Hideaki
2013-01-21 8:09 ` Stefan Richter
2013-01-21 12:04 ` YOSHIFUJI Hideaki
2013-01-21 13:15 ` Stefan Richter
2013-01-21 6:37 ` Stephan Gatzka
2013-01-21 12:16 ` YOSHIFUJI Hideaki
2013-01-20 21:22 ` Waskiewicz Jr, Peter P
2013-01-21 6:17 ` Stephan Gatzka
2013-01-21 8:28 ` Stefan Richter
2013-01-21 12:32 ` YOSHIFUJI Hideaki [this message]
2013-01-21 14:15 ` YOSHIFUJI Hideaki
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=50FD3575.1060303@linux-ipv6.org \
--to=yoshfuji@linux-ipv6.org \
--cc=davem@davemloft.net \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=netdev@vger.kernel.org \
--cc=peter.p.waskiewicz.jr@intel.com \
--cc=stefanr@s5r6.in-berlin.de \
--cc=stephan.gatzka@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).