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.
-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
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
John W. Linville wrote:
SNIP
Of course, patches would be helpful...
/sbin/ipadd address
#!/bin/sh
ip addr add $1 dev lo
/sbin/ipdel address
#!/bin/sh
ip addr del $1 dev lo
/sbin/ipactivate address device
#!/bin/sh
ip addr add $1 dev $2
/sbin/ipdeactivate address device
#!/bin/sh
ip addr del
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
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:
SNIP
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.
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:
SNIP
The association between IP addresses and links is already a bit murky.
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
