Re: [RFC] ip / ifconfig redesign
Bernd Eckenfels wrote: > Al Boldi wrote: > > The current ip / ifconfig configuration is arcane and inflexible. The > > reason being, that they are based on design principles inherited from > > the last century. > > Yes I agree, however note that some of the asumptions are backed up and > required by RFCs. For example the binding of addresses to interfaces. This > is especially strongly required in the IPV6 world with all the scoping and > renumbering RFCs. Can you point me to those RFCs? Thanks! > The things you want to change need to be changed in kernel space, btw. True. I mentioned ip / ifconfig not to imply that they are the culprit, but instead to expose the underlying kernel implementation. This does not mean though, that ip / ifconfig cannot offer an emulated OSI compliant mode, which would be an impetus to change the underlying implementation. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. >>And there may be many other benefits... (i.e. 100% OSI compliance) >> > > What does Open Source Initiative have to do with this at all??? > You are just spewing stuff out. *cough* http://www.webopedia.com/quick_ref/OSI_Layers.asp He's talking about the OSI layers and not anything else. Ie networking ... // Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDmyPIBrn2kJu9P78RAoo1AJ4vmiwaNNXjbYhOTYBTzGzeaaT8rQCdFywX rAaJ9HFR11fpG0fk91ezFl8= =qCfq -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
On Mon, Dec 05, 2005 at 11:48:52PM +0100, Jeroen Massar wrote: > John Heffner wrote: > > Jeroen Massar wrote: > >> I wonder how many RFC's it violates. An interface must only answer ARP's > >> on the interface that it is configured on, not anything else. > > > > Not true. See RFC 1122, section 3.3.4. The standard leaves this > > decision up to the implementation, for good reason. > > RFC1122 is a document about multicast. ARP is broadcast see the very old > RFC826/STD0037. Multicast didn't even work on much of the hardware from > the times that that document was written. > > Probably the best text about this subject can be found in RFC1027: > 8<--- > 2.4 Sanity checks > > Care must be taken by the network and gateway administrators to keep > the network masks the same on all the subnet gateway machines. The > most common error is to set the network mask on a host without a > subnet implementation to include the subnet number. This causes the > host to fail to attempt to send packets to hosts not on its local > subnet. Adjusting its routing tables will not help, since it will > not know how to route to subnets. > > If the IP networks of the source and target hosts of an ARP request > are different, an ARP subnet gateway implementation should not > reply. This is to prevent the ARP subnet gateway from being used to > reach foreign IP networks and thus possibly bypass security checks > provided by IP gateways. > -->8 > > Which is almost the same as what I noted. Note that the document is > about Proxy ARP, when a host is responding ARP queries for an IP on a > different link, this is exactly what it is doing: proxy arp. Interesting, but I don't think it applies. We're talking about reaching the node, not about using the node as a transparent gateway. Note the part about "an ARP subnet gateway implementation" that need to be careful. > > > This topic has been discussed many times on a variety of mailing lists. > > I think the best way to do this is to make the behavior configurable, > > which Linux currently does. > > As long as the default is off I am fine with it, people turning it on > themselves break their own network :) Indeed. Safety (sanity) first. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
On Mon, Dec 05, 2005 at 06:03:02PM -0500, John Heffner wrote: > Rick Jones wrote: > >John Heffner wrote: > >>Yes, but if an interface will accept packets for a certain IP address, > >>and will send packets with that IP address, is there any reason it > >>can't ARP for that address? > > > > > >If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP, > >accepting IPs is IP. The maze of twisty passages may be similar, but > >they are distinct. > > I actually think it would be out of scope for an ARP RFC to specify this > (and none I'm aware of do). It really is an IP layer decision. That > is, the decision naturally extends beyond the scope of ARP, applying > also to layer 2 devices which don't even do ARP. Indeed. We've been talking about ARP responses, not queries. > >Is a MAC address a property of the host, or of the interface connected > >to the host? > > Depends on whether you run your interfaces in promiscuous mode, and send > frames with different MAC addresses from one interface. ;-) MAC addresses are owned by the link. It is not meaningful for eth1 to transmit the MAC for eth0. Consider that both interfaces could be on the same link. Yes, we can do all manner of gymnastics, but this is something that IEEE standardizes. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
John Heffner wrote: > Jeroen Massar wrote: >> John Heffner wrote: >> >>> Jeroen Massar wrote: >>> I wonder how many RFC's it violates. An interface must only answer ARP's on the interface that it is configured on, not anything else. >>> >>> Not true. See RFC 1122, section 3.3.4. The standard leaves this >>> decision up to the implementation, for good reason. >> >> >> RFC1122 is a document about multicast. ARP is broadcast see the very old >> RFC826/STD0037. Multicast didn't even work on much of the hardware from >> the times that that document was written. > > ??? RFC 1122 is the Hosts Requirements RFC. It applies to any host > implementing IP. Maybe you're thinking of 1112? Oops, mixed up a number. 1122 refers to 826, with 1027 extending it partially for situations where one is multihomed. Section 3.3.4 of 1122 is about IP and not about ARP, which is, just like IP directly on top of Ethernet. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: [RFC] ip / ifconfig redesign
Rick Jones wrote: John Heffner wrote: Yes, but if an interface will accept packets for a certain IP address, and will send packets with that IP address, is there any reason it can't ARP for that address? If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP, accepting IPs is IP. The maze of twisty passages may be similar, but they are distinct. I actually think it would be out of scope for an ARP RFC to specify this (and none I'm aware of do). It really is an IP layer decision. That is, the decision naturally extends beyond the scope of ARP, applying also to layer 2 devices which don't even do ARP. Is a MAC address a property of the host, or of the interface connected to the host? Depends on whether you run your interfaces in promiscuous mode, and send frames with different MAC addresses from one interface. ;-) -John - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Jeroen Massar wrote: John Heffner wrote: Jeroen Massar wrote: I wonder how many RFC's it violates. An interface must only answer ARP's on the interface that it is configured on, not anything else. Not true. See RFC 1122, section 3.3.4. The standard leaves this decision up to the implementation, for good reason. RFC1122 is a document about multicast. ARP is broadcast see the very old RFC826/STD0037. Multicast didn't even work on much of the hardware from the times that that document was written. ??? RFC 1122 is the Hosts Requirements RFC. It applies to any host implementing IP. Maybe you're thinking of 1112? -John - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
John Heffner wrote: > Jeroen Massar wrote: >> I wonder how many RFC's it violates. An interface must only answer ARP's >> on the interface that it is configured on, not anything else. > > Not true. See RFC 1122, section 3.3.4. The standard leaves this > decision up to the implementation, for good reason. RFC1122 is a document about multicast. ARP is broadcast see the very old RFC826/STD0037. Multicast didn't even work on much of the hardware from the times that that document was written. Probably the best text about this subject can be found in RFC1027: 8<--- 2.4 Sanity checks Care must be taken by the network and gateway administrators to keep the network masks the same on all the subnet gateway machines. The most common error is to set the network mask on a host without a subnet implementation to include the subnet number. This causes the host to fail to attempt to send packets to hosts not on its local subnet. Adjusting its routing tables will not help, since it will not know how to route to subnets. If the IP networks of the source and target hosts of an ARP request are different, an ARP subnet gateway implementation should not reply. This is to prevent the ARP subnet gateway from being used to reach foreign IP networks and thus possibly bypass security checks provided by IP gateways. -->8 Which is almost the same as what I noted. Note that the document is about Proxy ARP, when a host is responding ARP queries for an IP on a different link, this is exactly what it is doing: proxy arp. > This topic has been discussed many times on a variety of mailing lists. > I think the best way to do this is to make the behavior configurable, > which Linux currently does. As long as the default is off I am fine with it, people turning it on themselves break their own network :) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: [RFC] ip / ifconfig redesign
John Heffner wrote: Rick Jones wrote: That's the discussion related to things like the "Strong ES" (end system) model right? As such, isn't that discussing what _IP_ may do rather than what ARP may do? 1122 doesn't say much about the interfaces/MAC's that should be part of a given ARP reply. ARP seems to be RFC 826 and probably others, and the algorithm described in 826 doesn't seem to be specific on the topic of interfaces - at least not to my really brief read. rick jones Yes, but if an interface will accept packets for a certain IP address, and will send packets with that IP address, is there any reason it can't ARP for that address? If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP, accepting IPs is IP. The maze of twisty passages may be similar, but they are distinct. Is a MAC address a property of the host, or of the interface connected to the host? rick jones is on netdev, so no need for direct reply to my address... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Rick Jones wrote: That's the discussion related to things like the "Strong ES" (end system) model right? As such, isn't that discussing what _IP_ may do rather than what ARP may do? 1122 doesn't say much about the interfaces/MAC's that should be part of a given ARP reply. ARP seems to be RFC 826 and probably others, and the algorithm described in 826 doesn't seem to be specific on the topic of interfaces - at least not to my really brief read. rick jones Yes, but if an interface will accept packets for a certain IP address, and will send packets with that IP address, is there any reason it can't ARP for that address? -John - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
John Heffner wrote: Jeroen Massar wrote: I wonder how many RFC's it violates. An interface must only answer ARP's on the interface that it is configured on, not anything else. Not true. See RFC 1122, section 3.3.4. The standard leaves this decision up to the implementation, for good reason. From 1122 (note the use of MAY, not MUST or SHOULD): " There are two key requirement issues related to multihoming: (A) A host MAY silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received. (B) A host MAY restrict itself to sending (non-source- routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams. " That's the discussion related to things like the "Strong ES" (end system) model right? As such, isn't that discussing what _IP_ may do rather than what ARP may do? 1122 doesn't say much about the interfaces/MAC's that should be part of a given ARP reply. ARP seems to be RFC 826 and probably others, and the algorithm described in 826 doesn't seem to be specific on the topic of interfaces - at least not to my really brief read. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Jeroen Massar wrote: I wonder how many RFC's it violates. An interface must only answer ARP's on the interface that it is configured on, not anything else. Not true. See RFC 1122, section 3.3.4. The standard leaves this decision up to the implementation, for good reason. From 1122 (note the use of MAY, not MUST or SHOULD): " There are two key requirement issues related to multihoming: (A) A host MAY silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received. (B) A host MAY restrict itself to sending (non-source- routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams. " This topic has been discussed many times on a variety of mailing lists. I think the best way to do this is to make the behavior configurable, which Linux currently does. -John - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
On Mon, Dec 05, 2005 at 10:00:41AM -0800, Ben Greear wrote: > >Precisely the case. It should be the case that a box response to an > >arp on *any* interface for *any* IP address known to the box. > > I certainly don't mind if this is a configurable, or even default > behaviour, but we also need the ability to only respond to particular > arps on particular interfaces, based on the IP addresses assigned > to those interfaces. Why? The routing determines connectivity, not ARP. AFAIK, ARP requests are not made on interfaces that lack that the network being queried. If I put a host with an address on network 12 onto an ethernet segment for network 10 and then ARP for addresses on network 10, I ought to be able to send packets to those hosts (baring a firewal). However, I won't be able to get anything back because those hosts don't know how to send to network 12. Misconfiguration? Yes. Non-compliant? No. > I am able to get this particular arp binding working today, so I'm > not suggesting changes, just mentioning that there are other > configurations than what you mention that are useful to people. Anyway, I haven't seen a good reason to change the current behavior. While the above described functionality is missing, no one has made a case to support it. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
On Mon, Dec 05, 2005 at 06:59:07PM +0100, Jeroen Massar wrote: > Marc Singer wrote: > > On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote: > >> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: > > >> The association between IP addresses and links is already a bit murky. > >> Reference the arp_announce sysctl for what I mean. I recall Dave M. > >> emphasizing on at least one occassion that IP addresses belong to > >> the _box_, not to the link. > > > > Precisely the case. It should be the case that a box response to an > > arp on *any* interface for *any* IP address known to the box. > > Thus you have the following nice setup: > > 10.100.10.0/24 = 10Gbit streaming network > 10.100.20.0/24 = 10mbit admin network > > 10.100.10.1 on eth0 > 10.100.20.1 on eth2 > > Then some idiot misconfigures his client box, putting 10.100.10.42/24 on > the NIC that is supposed to be in the admin network only. > Suddenly your 10mbit link is full because the arp's get answered on this > link. Huh? The arp requests don't establish routing and they aren't a significant source of traffic. Besides, all I suggested is that if a machine receives an arp request on eth2 for an address it has on 10.100.10/24, it should answer with it's MAC address on eth2. My readings of the RFC do not address this issue directly. My understand of this behaviour is from a discussion with someone regarding iptables. Moreover, if you allow users to willy-nilly connect to your networks, you've got a completely different kind of problem on your hands. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
John W. Linville wrote: > > Al Boldi wrote: > > >Here specifically, ip/ifconfig is implemented upside-down requiring a > > >link/dev to exist for an address to be defined, in effect containing > > > layer 3 inside layer 2, when an address should be allowed to be > > > defined w/o a link/dev much like an app is allowed to be defined w/o > > > an address. > > > I think Al B.'s idea merits some consideration. I definitely think > we blur the distinctions between L2 and L3 a bit too much in places. > > Of course, patches would be helpful... I am envisaging a complete decoupling of the current implementation to achieve OSI compliance. And that's not for the sake of OSI but for the sake of scalability. This means that it should be possible define a layer 3 network architecture completely independent of a layer 2 link architecture. This also means that we are free to choose means other than a layer 2 link to fulfill layer 3 requests and vice/versa. And it may open the door to many other things... due to scalability. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
On Mon, Dec 05, 2005 at 10:00:41AM -0800, Ben Greear wrote: > Marc Singer wrote: > >On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote: > >>The association between IP addresses and links is already a bit murky. > >>Reference the arp_announce sysctl for what I mean. I recall Dave M. > >>emphasizing on at least one occassion that IP addresses belong to > >>the _box_, not to the link. > >Precisely the case. It should be the case that a box response to an > >arp on *any* interface for *any* IP address known to the box. > > I certainly don't mind if this is a configurable, or even default > behaviour, but we also need the ability to only respond to particular It was not my intention to derail this discussion to the arp_announce topic. I only cited it as an example where the IP address <-> interface mapping is not 100% absolute. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Marc Singer wrote: On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote: On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: Al Boldi wrote: Here specifically, ip/ifconfig is implemented upside-down requiring a link/dev to exist for an address to be defined, in effect containing layer 3 inside layer 2, when an address should be allowed to be defined w/o a link/dev much like an app is allowed to be defined w/o an address. [Removed lkml from CC list] You can add multiple virtual IP addresses to physical interfaces. It makes no sense to have an IP without any association to an interface in my opinion. Often, when you have multiple interfaces, you most definately want different IPs associated specifically with particular interfaces. Think about redundant paths, routers, firewalls, and such. The association between IP addresses and links is already a bit murky. Reference the arp_announce sysctl for what I mean. I recall Dave M. emphasizing on at least one occassion that IP addresses belong to the _box_, not to the link. I think Al B.'s idea merits some consideration. I definitely think we blur the distinctions between L2 and L3 a bit too much in places. Of course, patches would be helpful... Precisely the case. It should be the case that a box response to an arp on *any* interface for *any* IP address known to the box. I certainly don't mind if this is a configurable, or even default behaviour, but we also need the ability to only respond to particular arps on particular interfaces, based on the IP addresses assigned to those interfaces. I am able to get this particular arp binding working today, so I'm not suggesting changes, just mentioning that there are other configurations than what you mention that are useful to people. As for changing the behavior, I haven't seen a compelling reason to change it. IMHO, without a motivating case, we would be mucking about without a clear goal. Agreed. Thanks, Ben - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Marc Singer wrote: > On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote: >> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: >> The association between IP addresses and links is already a bit murky. >> Reference the arp_announce sysctl for what I mean. I recall Dave M. >> emphasizing on at least one occassion that IP addresses belong to >> the _box_, not to the link. > > Precisely the case. It should be the case that a box response to an > arp on *any* interface for *any* IP address known to the box. Thus you have the following nice setup: 10.100.10.0/24 = 10Gbit streaming network 10.100.20.0/24 = 10mbit admin network 10.100.10.1 on eth0 10.100.20.1 on eth2 Then some idiot misconfigures his client box, putting 10.100.10.42/24 on the NIC that is supposed to be in the admin network only. Suddenly your 10mbit link is full because the arp's get answered on this link. I wonder how many RFC's it violates. An interface must only answer ARP's on the interface that it is configured on, not anything else. There is a low level of brokeness here already. When you have: eth0 = 10.100.10.1/24 eth1 = 192.168.1.1/24 default route towards 192.168.1.250, forwarding enabled. SMTP on 192.168.1.1. Now when a client from 10.100.10.5 contacts 192.168.1.1, the FORWARD chain of iptables is skipped. The packet directly comes into INPUT. Blocking based on the decision that it is actually being forwarded is impossible because of this, unless you do -i eth0 -d 192.168.1.1. Combine this with the above and you can suddenly access internal IP's when the firewall is configured correctly to block FORWARD's from the eth1 interface and you have an internal service on 10.100.10.1. You only have to find a way to be local on the external interface so that you can do arp's for internal IP's. It will be loved by pesky ISP's who limit people and disallow them to do NAT of course. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: [RFC] ip / ifconfig redesign
On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote: > On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: > > Al Boldi wrote: > > > > >Here specifically, ip/ifconfig is implemented upside-down requiring a > > >link/dev to exist for an address to be defined, in effect containing layer > > >3 inside layer 2, when an address should be allowed to be defined w/o a > > >link/dev much like an app is allowed to be defined w/o an address. > > > > [Removed lkml from CC list] > > > > You can add multiple virtual IP addresses to physical interfaces. It > > makes no sense to have an IP without any association to an interface > > in my opinion. Often, when you have multiple interfaces, you most > > definately > > want different IPs associated specifically with particular interfaces. > > Think about redundant paths, routers, firewalls, and such. > > The association between IP addresses and links is already a bit murky. > Reference the arp_announce sysctl for what I mean. I recall Dave M. > emphasizing on at least one occassion that IP addresses belong to > the _box_, not to the link. > > I think Al B.'s idea merits some consideration. I definitely think > we blur the distinctions between L2 and L3 a bit too much in places. > > Of course, patches would be helpful... Precisely the case. It should be the case that a box response to an arp on *any* interface for *any* IP address known to the box. As for changing the behavior, I haven't seen a compelling reason to change it. IMHO, without a motivating case, we would be mucking about without a clear goal. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
John W. Linville wrote: > Of course, patches would be helpful... /sbin/ipadd #!/bin/sh ip addr add $1 dev lo /sbin/ipdel #!/bin/sh ip addr del $1 dev lo /sbin/ipactivate #!/bin/sh ip addr add $1 dev $2 /sbin/ipdeactivate #!/bin/sh ip addr del $1 dev $2 There are your 'patches'. Add -6's to places for IPv6 versions. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: [RFC] ip / ifconfig redesign
On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: > Al Boldi wrote: > > >Here specifically, ip/ifconfig is implemented upside-down requiring a > >link/dev to exist for an address to be defined, in effect containing layer > >3 inside layer 2, when an address should be allowed to be defined w/o a > >link/dev much like an app is allowed to be defined w/o an address. > > [Removed lkml from CC list] > > You can add multiple virtual IP addresses to physical interfaces. It > makes no sense to have an IP without any association to an interface > in my opinion. Often, when you have multiple interfaces, you most > definately > want different IPs associated specifically with particular interfaces. > Think about redundant paths, routers, firewalls, and such. The association between IP addresses and links is already a bit murky. Reference the arp_announce sysctl for what I mean. I recall Dave M. emphasizing on at least one occassion that IP addresses belong to the _box_, not to the link. I think Al B.'s idea merits some consideration. I definitely think we blur the distinctions between L2 and L3 a bit too much in places. Of course, patches would be helpful... John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Ben Greear wrote: > Al Boldi wrote: > > Here specifically, ip/ifconfig is implemented upside-down requiring a > > link/dev to exist for an address to be defined, in effect containing > > layer 3 inside layer 2, when an address should be allowed to be defined > > w/o a link/dev much like an app is allowed to be defined w/o an address. > > You can add multiple virtual IP addresses to physical interfaces. It > makes no sense to have an IP without any association to an interface > in my opinion. Often, when you have multiple interfaces, you most > definately want different IPs associated specifically with particular > interfaces. Think about redundant paths, routers, firewalls, and such. This proposal does not reduce the current features, but instead attempts to remove certain dependencies to aid scalability, usability, and flexibility. Can you explain why these dependencies are necessary? > If you do see a benefit to your proposal, please describe how you would > use it, and why you cannot do this thing with today's code. Does not my previous post answer this question? > Philosophical musings about the 'proper' way to do things without concrete > examples is unlikely to get you very far :) I am only trying to be honest about it; no philosophical musings meant. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Al Boldi wrote: Here specifically, ip/ifconfig is implemented upside-down requiring a link/dev to exist for an address to be defined, in effect containing layer 3 inside layer 2, when an address should be allowed to be defined w/o a link/dev much like an app is allowed to be defined w/o an address. [Removed lkml from CC list] You can add multiple virtual IP addresses to physical interfaces. It makes no sense to have an IP without any association to an interface in my opinion. Often, when you have multiple interfaces, you most definately want different IPs associated specifically with particular interfaces. Think about redundant paths, routers, firewalls, and such. If you do see a benefit to your proposal, please describe how you would use it, and why you cannot do this thing with today's code. Philosophical musings about the 'proper' way to do things without concrete examples is unlikely to get you very far :) Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Pekka Savola wrote: > Al Boldi wrote: > > Consider this new approach for better address management: > > 1. Allow the definition of an address pool > > 2. Relate links to addresses > > 3. Implement to make things backward-compatible. > > > > The obvious benefit here, would be the transparent ability for apps to > > bind to addresses, regardless of the link existence. > > > That's called 'the loopback address', right? :) Jan-Benedict Glaw wrote: > # echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind > > and/or bind to address 0 (aka 0.0.0.0) instead of a given IP address. Ben Greear wrote: > > Another benefit includes the ability to scale the link level > > transparently, regardless of the application bind state. > > Can you do this with the current code by using scripts/whatever to move > virtual IPs around the interfaces? Maybe, but wouldn't that be a workaround? linux-os \(Dick Johnson\) wrote: > It really doesn't have anything to do with the kernel. Maybe I shouldn't have cc'd kernel. Marc Singer wrote: > It might make sense to allow the address to exist without a link in > order to allow a local port listener to continue to accept connections > even though the network moved to another link, e.g. wireless to > wired. Then again, perhaps, this shouldn't matter. > > What does Mr. Boldi propose? Jesper Juhl wrote: > I'm only guessing since I'm not entirely sure what Mr. Boldi means, > but my guess is that he's proposing that an app can bind to an IP > address without that address being assigned to any currently available > interface and then later if that IP does get assigned to an interface > the app will start recieving traffic then. Also possibly allowing the > address to be removed from one interface and then later assigned to > another one without apps noticing. > I don't know /if/ that is what was meant, but that's how I read it. Yes! And much more... One reason why linux is great is because it's flexible. But flexibility sometimes leads you to fulfill requirements in a workaround fashion. Things get worse when you start building on these workarounds. GNU/OpenSource is prone to such a development. What I propose is to stop and think always; identify the problem and provide for a _scalable_ solution. Procrastinating using workarounds may make your development cycle seem faster, when in fact you are inhibiting it. Here specifically, ip/ifconfig is implemented upside-down requiring a link/dev to exist for an address to be defined, in effect containing layer 3 inside layer 2, when an address should be allowed to be defined w/o a link/dev much like an app is allowed to be defined w/o an address. Thanks for all your comments! -- Al - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Al Boldi wrote: The current ip / ifconfig configuration is arcane and inflexible. The reason being, that they are based on design principles inherited from the last century. In a GNU/OpenSource environment, OpenMinds should not inhibit themselves achieving new design-goals to enable a flexible non-redundant configuration. Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to associate the address to a link instead of the other way around. Consider this new approach for better address management: 1. Allow the definition of an address pool 2. Relate links to addresses 3. Implement to make things backward-compatible. The obvious benefit here, would be the transparent ability for apps to bind to addresses, regardless of the link existence. Another benefit includes the ability to scale the link level transparently, regardless of the application bind state. And there may be many other benefits... (i.e. 100% OSI compliance) -- 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/ Just what we need, another broken utility without backward compatibility. Make certain you preserve the existing commands so the whole planet isn't broken as a result. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
On 12/2/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: > > On Fri, 2 Dec 2005, Al Boldi wrote: > > > The current ip / ifconfig configuration is arcane and inflexible. The > > reason > > being, that they are based on design principles inherited from the last > > century. > > > > In a GNU/OpenSource environment, OpenMinds should not inhibit themselves > > achieving new design-goals to enable a flexible non-redundant configuration. > > > > Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to > > associate the address to a link instead of the other way around. > > > > Consider this new approach for better address management: > > 1. Allow the definition of an address pool > > 2. Relate links to addresses > > 3. Implement to make things backward-compatible. > > > > The obvious benefit here, would be the transparent ability for apps to bind > > to addresses, regardless of the link existence. > > > > A link needs to exist for it to have an address. > I'm only guessing since I'm not entirely sure what Mr. Boldi means, but my guess is that he's proposing that an app can bind to an IP address without that address being assigned to any currently available interface and then later if that IP does get assigned to an interface the app will start recieving traffic then. Also possibly allowing the address to be removed from one interface and then later assigned to another one without apps noticing. I don't know /if/ that is what was meant, but that's how I read it. > > Another benefit includes the ability to scale the link level transparently, > > regardless of the application bind state. > > > > That doesn't make any sense. Multiple applications can bind to the > same address. Then can't bind to the same port because they won't > get all their data. > > > And there may be many other benefits... (i.e. 100% OSI compliance) > > > What does Open Source Initiative have to do with this at all??? > You are just spewing stuff out. > I'm believe Mr. Boldi is refering to OSI as in Open Systems Interconnection (http://en.wikipedia.org/wiki/OSI_model), not as in Open Source Initiative. > > -- > > Al > > Also, how does this involve the kernel? The interface to the kernel > for hardware configuration is via ioctl(). For logic, sockets. > > If the user-level tools suck, then they should be fixed. It > really doesn't have anything to do with the kernel. > > Cheers, > Dick Johnson > [snip] > > Thank you. > -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
On Fri, 2 Dec 2005, Al Boldi wrote: > The current ip / ifconfig configuration is arcane and inflexible. The reason > being, that they are based on design principles inherited from the last > century. > > In a GNU/OpenSource environment, OpenMinds should not inhibit themselves > achieving new design-goals to enable a flexible non-redundant configuration. > > Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to > associate the address to a link instead of the other way around. > > Consider this new approach for better address management: > 1. Allow the definition of an address pool > 2. Relate links to addresses > 3. Implement to make things backward-compatible. > > The obvious benefit here, would be the transparent ability for apps to bind > to addresses, regardless of the link existence. > A link needs to exist for it to have an address. > Another benefit includes the ability to scale the link level transparently, > regardless of the application bind state. > That doesn't make any sense. Multiple applications can bind to the same address. Then can't bind to the same port because they won't get all their data. > And there may be many other benefits... (i.e. 100% OSI compliance) > What does Open Source Initiative have to do with this at all??? You are just spewing stuff out. > -- > Al Also, how does this involve the kernel? The interface to the kernel for hardware configuration is via ioctl(). For logic, sockets. If the user-level tools suck, then they should be fixed. It really doesn't have anything to do with the kernel. Cheers, Dick Johnson Penguin : Linux version 2.6.13.4 on an i686 machine (5589.44 BogoMips). Warning : 98.36% of all statistics are fiction. . The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
Al Boldi wrote: The current ip / ifconfig configuration is arcane and inflexible. The reason being, that they are based on design principles inherited from the last century. In a GNU/OpenSource environment, OpenMinds should not inhibit themselves achieving new design-goals to enable a flexible non-redundant configuration. Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to associate the address to a link instead of the other way around. Consider this new approach for better address management: 1. Allow the definition of an address pool 2. Relate links to addresses 3. Implement to make things backward-compatible. The obvious benefit here, would be the transparent ability for apps to bind to addresses, regardless of the link existence. Another benefit includes the ability to scale the link level transparently, regardless of the application bind state. Can you do this with the current code by using scripts/whatever to move virtual IPs around the interfaces? I guess I don't really understand what you are proposing... Ben And there may be many other benefits... (i.e. 100% OSI compliance) -- 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/ -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
On Fri, 2 Dec 2005, Al Boldi wrote: Consider this new approach for better address management: 1. Allow the definition of an address pool 2. Relate links to addresses 3. Implement to make things backward-compatible. The obvious benefit here, would be the transparent ability for apps to bind to addresses, regardless of the link existence. That's called 'the loopback address', right? :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] ip / ifconfig redesign
The current ip / ifconfig configuration is arcane and inflexible. The reason being, that they are based on design principles inherited from the last century. In a GNU/OpenSource environment, OpenMinds should not inhibit themselves achieving new design-goals to enable a flexible non-redundant configuration. Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to associate the address to a link instead of the other way around. Consider this new approach for better address management: 1. Allow the definition of an address pool 2. Relate links to addresses 3. Implement to make things backward-compatible. The obvious benefit here, would be the transparent ability for apps to bind to addresses, regardless of the link existence. Another benefit includes the ability to scale the link level transparently, regardless of the application bind state. And there may be many other benefits... (i.e. 100% OSI compliance) -- Al - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
