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
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 Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
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
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.
On Fri, 2005-12-02 22:53:19 +0300, Al Boldi <[email protected]> wrote:
> The obvious benefit here, would be the transparent ability for apps to bind
> to addresses, regardless of the link existence.
# 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.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
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
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
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
On Fri, 2005-12-02 14:34:08 -0800, Jeff Haran <[email protected]> wrote:
> > > The obvious benefit here, would be the transparent ability
> > for apps to bind
> > > to addresses, regardless of the link existence.
> >
> > # 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.
> kchan :root> ip addr show
> 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/16 scope host lo
> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:05:1e:35:00:49 brd ff:ff:ff:ff:ff:ff
> inet 10.32.246.19/20 brd 10.32.255.255 scope global eth0
> inet 10.32.246.16/20 brd 10.32.255.255 scope global secondary eth0:1
> 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:05:1e:35:00:4a brd ff:ff:ff:ff:ff:ff
> inet 10.0.0.6/24 brd 10.255.255.255 scope global eth1
> 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:05:1e:35:00:4b brd ff:ff:ff:ff:ff:ff
> inet 127.1.16.16/24 brd 127.255.255.255 scope global eth2
> 6: fc0: <BROADCAST,UP> mtu 2024 qdisc pfifo_fast qlen 100
> link/ieee802 00:05:1e:35:00:49 brd ff:ff:ff:ff:ff:ff
> inet 2.3.4.6/24 brd 2.3.4.255 scope global fc0
> kchan :root> ip addr add 4.5.6.7
> Not enough information: "dev" argument is required.
> kchan :root>
We were talking about apps binding to a non-local address. That is,
some locally running server binds to any address that is not yet there
(anything except 0.0.0.0, 127.0.0.1, 10.32.246.19, 109.32.246.16,
10.0.0.6, 127.1.16.16, 2.3.4.6). So we're talking about two different
subjects...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Jan-Benedict Glaw <[email protected]> writes:
> On Fri, 2005-12-02 22:53:19 +0300, Al Boldi <[email protected]> wrote:
>
>> The obvious benefit here, would be the transparent ability for apps to bind
>> to addresses, regardless of the link existence.
>
> # 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.
Or equally:
int opt = 1;
setsockopt(fd, IPFREEBIND, &opt, sizeof(opt));
in your application.
It's cool the backwards compatibility is so good no one even
noticed it was implemented :)
And from the kernel source as to why this behaviour is not
the default.
/* Not specified by any standard per-se, however it breaks too
* many applications when removed. It is unfortunate since
* allowing applications to make a non-local bind solves
* several problems with systems using dynamic addressing.
* (ie. your servers still start up even if your ISDN link
* is temporarily down)
*/
Eric
-----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-----
In article <[email protected]> you 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.
The things you want to change need to be changed in kernel space, btw.
Gruss
Bernd
ifconfig maintainer
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