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
On Fri, Feb 23, 2007 at 01:49:47PM +0200, Markku Savela wrote:
> 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]
>
patches welcome :)
> --
> Markku Savela
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
From: Neil Horman <[email protected]>
Date: Fri, 23 Feb 2007 08:47:06 -0500
> patches welcome :)
And it's a non-trivial task. The semantics and way in which
link level encapsulation is done is not straight-forward
on some devices.
So the hooks either have to be too generic, or too specific
to be useful.
> 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.
You mean, the link layer drivers should know of IP addressing modes?
Sounds like a layering violation to me. The mapping from IP to MAC
address is (for a good reason) part of the IP specs, not of the
Ethernet, Token Ring etc. specs, so the right place to implement it is
not the network drivers.
Olaf
>
> > 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.
>
> You mean, the link layer drivers should know of IP addressing modes?
> Sounds like a layering violation to me. The mapping from IP to MAC
> address is (for a good reason) part of the IP specs, not of the
> Ethernet, Token Ring etc. specs, so the right place to implement it is
> not the network drivers.
I disagree.
In current architecture, you have to patch kernel IPv6 and IPv4
protocols when you add new link layer that they don't recognize.
I think that is worse than allow a new driver to provide a simple
service function which maps IPv4/6 multicast address into link layer
address, when asked.
From: Markku Savela <[email protected]>
Date: Sat, 24 Feb 2007 18:45:03 +0200
> I think that is worse than allow a new driver to provide a simple
> service function which maps IPv4/6 multicast address into link layer
> address, when asked.
The problem is that this mapping isn't so simple for several
link layer types.
I outlined in another email this problem, in that any interface
which would allow a driver-like-API for this would be either
overly general or so specific as to be useless.
> In current architecture, you have to patch kernel IPv6 and IPv4
> protocols when you add new link layer that they don't recognize.
Which is right, because the IP layer is the place which knows how to
map IP addresses to link layer addresses.
IP must know its link layer. E.g. it needs a way to decide if the link
layer is multicast capable at all.
> I think that is worse than allow a new driver to provide a simple
> service function which maps IPv4/6 multicast address into link layer
> address, when asked.
"Link layer address" is not a generic concept at all, even though too
much code assumes everything is Ethernet.
Olaf
David Miller wrote:
> From: Markku Savela <[email protected]>
> > I think that is worse than allow a new driver to provide a simple
> > service function which maps IPv4/6 multicast address into link layer
> > address, when asked.
>
> The problem is that this mapping isn't so simple for several
> link layer types.
But this mapping seems to be just a simple de-coupling tool, and any
de-coupling by definition does/should not change the underlying
implementation in any way, while allowing for a dynamic rather than a
fixed/hardcoded relation between the layers.
So, can you give an example of a link-layer that does not easily de-couple
from the transport?
Thanks!
--
Al