LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* ipv4 and ipv6 stacks for new link layers?
@ 2007-02-23 11:49 Markku Savela
  2007-02-23 13:47 ` Neil Horman
  2007-02-24 16:00 ` Olaf Titz
  0 siblings, 2 replies; 8+ messages in thread
From: Markku Savela @ 2007-02-23 11:49 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ipv4 and ipv6 stacks for new link layers?
  2007-02-23 11:49 ipv4 and ipv6 stacks for new link layers? Markku Savela
@ 2007-02-23 13:47 ` Neil Horman
  2007-02-24  0:26   ` David Miller
  2007-02-24 16:00 ` Olaf Titz
  1 sibling, 1 reply; 8+ messages in thread
From: Neil Horman @ 2007-02-23 13:47 UTC (permalink / raw)
  To: Markku Savela; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ipv4 and ipv6 stacks for new link layers?
  2007-02-23 13:47 ` Neil Horman
@ 2007-02-24  0:26   ` David Miller
  0 siblings, 0 replies; 8+ messages in thread
From: David Miller @ 2007-02-24  0:26 UTC (permalink / raw)
  To: nhorman; +Cc: msa, linux-kernel

From: Neil Horman <nhorman@tuxdriver.com>
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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ipv4 and ipv6 stacks for new link layers?
  2007-02-23 11:49 ipv4 and ipv6 stacks for new link layers? Markku Savela
  2007-02-23 13:47 ` Neil Horman
@ 2007-02-24 16:00 ` Olaf Titz
  2007-02-24 16:45   ` Markku Savela
  1 sibling, 1 reply; 8+ messages in thread
From: Olaf Titz @ 2007-02-24 16:00 UTC (permalink / raw)
  To: linux-kernel

> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ipv4 and ipv6 stacks for new link layers?
  2007-02-24 16:00 ` Olaf Titz
@ 2007-02-24 16:45   ` Markku Savela
  2007-02-25  0:52     ` David Miller
  2007-02-25 10:27     ` Olaf Titz
  0 siblings, 2 replies; 8+ messages in thread
From: Markku Savela @ 2007-02-24 16:45 UTC (permalink / raw)
  To: olaf; +Cc: linux-kernel

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ipv4 and ipv6 stacks for new link layers?
  2007-02-24 16:45   ` Markku Savela
@ 2007-02-25  0:52     ` David Miller
  2007-02-25 10:27     ` Olaf Titz
  1 sibling, 0 replies; 8+ messages in thread
From: David Miller @ 2007-02-25  0:52 UTC (permalink / raw)
  To: msa; +Cc: olaf, linux-kernel

From: Markku Savela <msa@moth.iki.fi>
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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ipv4 and ipv6 stacks for new link layers?
  2007-02-24 16:45   ` Markku Savela
  2007-02-25  0:52     ` David Miller
@ 2007-02-25 10:27     ` Olaf Titz
  1 sibling, 0 replies; 8+ messages in thread
From: Olaf Titz @ 2007-02-25 10:27 UTC (permalink / raw)
  To: linux-kernel

> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ipv4 and ipv6 stacks for new link layers?
@ 2007-02-25 11:21 Al Boldi
  0 siblings, 0 replies; 8+ messages in thread
From: Al Boldi @ 2007-02-25 11:21 UTC (permalink / raw)
  To: netdev; +Cc: linux-kernel

David Miller wrote:
> From: Markku Savela <msa@moth.iki.fi>
> > 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


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-02-25 11:18 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-23 11:49 ipv4 and ipv6 stacks for new link layers? Markku Savela
2007-02-23 13:47 ` Neil Horman
2007-02-24  0:26   ` David Miller
2007-02-24 16:00 ` Olaf Titz
2007-02-24 16:45   ` Markku Savela
2007-02-25  0:52     ` David Miller
2007-02-25 10:27     ` Olaf Titz
2007-02-25 11:21 Al Boldi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).