Re: ipv4 and ipv6 stacks for new link layers?
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 - 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/
Re: ipv4 and ipv6 stacks for new link layers?
> 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 - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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 - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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 - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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. - 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/
Re: ipv4 and ipv6 stacks for new link layers?
> > > 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. - 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/
Re: ipv4 and ipv6 stacks for new link layers?
> 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 - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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 - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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. - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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. - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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. - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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/ - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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/ - 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/
Re: ipv4 and ipv6 stacks for new link layers?
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. - 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/
