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: <50FD2EBE.9050608@linux-ipv6.org>
Date:	Mon, 21 Jan 2013 21:04:14 +0900
From:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	stephan.gatzka@...il.com, netdev <netdev@...r.kernel.org>,
	linux1394-devel@...ts.sourceforge.net,
	David Miller <davem@...emloft.net>,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: [RFC:] struct net_device_ops: Add function pointer to fill device
 specific ndisc information

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?

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.

--
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