| 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
| ||
|
Message-Id: <200702231149.l1NBnlZD029626@moth.iki.fi> Date: Fri, 23 Feb 2007 13:49:47 +0200 From: Markku Savela <msa@...h.iki.fi> To: linux-kernel@...r.kernel.org Subject: ipv4 and ipv6 stacks for new link layers? The IPv6 and IPv4 both seem to be rather akwardly hardcoded to support only link layers they know. This is a pity, because it would be so easy to make the both stacks totally independent of the actual link layers. It only needs one (or two) new function pointer in net_device. This function should do the conversion from IPv4/IPv6 address into corresponding hardware multicast/broadcast address. In both IPv4 and IPv6, all places where symbols ARPHRD_* are reference, are suspect (there are some related to tunnels, which may be appropriate). For example, in ipv4/arp.c arp_mc_map would call this mapping function, if provided. Similarly ipv6/ndisc.c ndisc_mc_map. In ipv6/addrconf.c the ivp6_generate_eui64 may possibly need yet another netdev function provided by the driver. The current Ethernet specific code for these mappings could be moved from the ipv6/ipv6 into eth.c, and ether_setup would give defaults for the functions. [I run into this while trying to do a netdev to a device is not known by the stacks, and IPv6 even refuses to start on it (because of the ivp6_generate_eui64 fails?). IPv4 ARP seems to fall back to broadcast, so it sort of starts] -- Markku Savela - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists