netdev - Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130121141548.6327224b@stein>
Date:	Mon, 21 Jan 2013 14:15:48 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Cc:	netdev <netdev@...r.kernel.org>,
	linux1394-devel@...ts.sourceforge.net,
	David Miller <davem@...emloft.net>
Subject: Re: [RFC:] struct net_device_ops: Add function pointer to fill
 device specific ndisc information

On Jan 21 YOSHIFUJI Hideaki wrote:
> Stefan Richter wrote:
> > On Jan 20 Stephan Gatzka wrote:
> >> On 01/20/2013 07:47 PM, YOSHIFUJI Hideaki wrote:
> >>
> >>> My current position is to change "mac address" to
> >>>
> >>> struct fwnet_hwaddr {
> >>> 	u8	guid[8];
> >>> 	u8	max_rec;
> >>> 	u8	sspd;
> >>> 	u8	fifo[6];
> >>> };
> >>>
> >>
> >> That is something I'm not really convinced of. As Stefan Richter pointed 
> >> out clearly, the fifo address might be different between IPv4 and IPv6 
> >> communication.
> > 
> > If it is of any help, the initial implementation could assume that IPv4
> > unicast_FIFO and IPv6 unicast_FIFO are the same.  RFC 3146 is silent on
> > this topic (which means it can be one way or the other), but from an
> > implementation point of view, using one FIFO offset for both seems quite
> > natural.  Currently the only existing RFC 3146 implementation which is
> > known to us is Mac OS X, and since your tests with OS X 10.6 went well,
> > they obviously use one offset for both protocols.
> > 
> > But if we actually put this assumption into the implementation now, we
> > should make sure that we can easily expand the implementation later in the
> > event that a third implementation comes across which uses separate
> > unicast_FIFOs.
> 
> Well, FIFO for which side?

Our Linux implementation should expose a single unicast_FIFO for
reception of both protocols, just in case that another implementation
expects just this.

For transmission, we should be ready to keep an IP-peer-to-1394-node
mapping with per-protocol unicast_FIFOs, but in my mind it is doubtful
that any such implementation exists (hence we could just stand prepared
to implement it later when proven to be needed -- if this simplifies the
initial implementation notably).

> I do believe sender will not (or say, must not) care if they use
> different FIFO for both protocol or not.
> 
> Assume that peer has FIFO per protocol, one for IPv4 and another for
> IPv6.  ARP advertise FIFO for IPv4 and NDP advertise FIFO for IPv6.
> neighbour subsystem has protocol dependent tables, and two different
> NCEs (neighbour cache entries) will be created.  So, sender will
> correctly get FIFO from NCE for each protocol.

OK.
-- 
Stefan Richter
-=====-===-= ---= =-=-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html