lkml.org 
[lkml]   [2007]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectipv4 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-02-23 12:53    [W:0.074 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site