netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
To: stephan.gatzka@gmail.com
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>,
	netdev@vger.kernel.org, linux1394-devel@lists.sourceforge.net,
	YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Subject: Re: [RFC PATCH 6/6] ipv6: IPv6 over IEEE1394 (RFC3146) support.
Date: Sun, 13 Jan 2013 12:57:08 +0900	[thread overview]
Message-ID: <50F23094.9040003@linux-ipv6.org> (raw)
In-Reply-To: <50F192DF.9090100@gmail.com>

Stephan Gatzka wrote:
>> How about putting EUI64, maxrec, sspd and fifo in dev->dev_addr?
>> This enable us to send NDISC/ARP packet easily (based on neighbor
>> cache entry), and driver can be notified for new neighbors (thus
>> new peers).
> Hm, that looks a bit strange to me, because we need that only for link layer option packets and not for every IPv6 packet transmitted via firewire.

It seems the stack will be clearner, overall.

In addition to ARP/NDP things, for example, it will become easier to
implement multicast as well; IP layer can tell net_device layer
multicast listener information via special mapping.

Given multicast bit is disabled in the Unique ID (well, it should be
disabled; otherwise, disable multicast bit and trun on locally
administrated bit), IP layer can tell full IPv6 address via
ip6_mc_map() by copying full IPv6 address to EUI-64 + additional
space, e.g: 
  IPv6: FF xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx (IPv6 mutlicast address (FF00::/8))
Similar in IPv4:
  IPv4: 01 00 00 00 00 00 00 00 00 00 00 00 xx xx xx xx (IPv4 multicast address)

Device will be notified via dev_mc_add() / dev_mc_del(),
then net_device_opts->ndo_set_rx_mode(), and you can manage
multicast lists based on that.

When sending the driver can determine if the packet is multicast or not
by seeing 0x01 bit in the first octet in the destination virtual
"MAC" address, and then MCAP manager can determine IP version by seeing
the first octet of our virtual "MAC" address.

--yoshfuji

      reply	other threads:[~2013-01-13  3:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-12 14:21 [RFC PATCH 6/6] ipv6: IPv6 over IEEE1394 (RFC3146) support YOSHIFUJI Hideaki
2013-01-12 14:40 ` Stephan Gatzka
2013-01-12 15:47 ` Stefan Richter
2013-01-12 16:37   ` Stephan Gatzka
2013-01-12 16:39   ` YOSHIFUJI Hideaki
2013-01-12 16:44     ` Stephan Gatzka
2013-01-13  3:57       ` YOSHIFUJI Hideaki [this message]

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=50F23094.9040003@linux-ipv6.org \
    --to=yoshfuji@linux-ipv6.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --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).