[RFC] ip / ifconfig redesign

[RFC] ip / ifconfig redesign

[Al Boldi]

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

Re: [RFC] ip / ifconfig redesign

[Pekka Savola]

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

Re: [RFC] ip / ifconfig redesign

[Ben Greear]

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


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFC] ip / ifconfig redesign

[linux-os (Dick Johnson)]

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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: [RFC] ip / ifconfig redesign

[Jesper Juhl]

On 12/2/05, linux-os (Dick Johnson) <linux-os@analogic.com> 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 <jesper.juhl@gmail.com>
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

Re: [RFC] ip / ifconfig redesign

[Stefan Smietanowski]

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

Re: [RFC] ip / ifconfig redesign

[Jeff V. Merkey]

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

Re: [RFC] ip / ifconfig redesign

[Al Boldi]

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

Re: [RFC] ip / ifconfig redesign

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFC] ip / ifconfig redesign

[Al Boldi]

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

Re: [RFC] ip / ifconfig redesign

[John W. Linville]

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
linville@tuxdriver.com

Re: [RFC] ip / ifconfig redesign

[Jeroen Massar]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

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 $1 dev $2

There are your 'patches'. Add -6's to places for IPv6 versions.

Greets,
 Jeroen



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]

Re: [RFC] ip / ifconfig redesign

[Marc Singer]

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.

Re: [RFC] ip / ifconfig redesign

[Jeroen Massar]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]

Re: [RFC] ip / ifconfig redesign

[Marc Singer]

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

Re: [RFC] ip / ifconfig redesign

[John Heffner]

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

Re: [RFC] ip / ifconfig redesign

[Rick Jones]

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

Re: [RFC] ip / ifconfig redesign

[John Heffner]

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

Re: [RFC] ip / ifconfig redesign

[Rick Jones]

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

Re: [RFC] ip / ifconfig redesign

[John Heffner]

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

Re: [RFC] ip / ifconfig redesign

[Marc Singer]

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.

Re: [RFC] ip / ifconfig redesign

[Jeroen Massar]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]

Re: [RFC] ip / ifconfig redesign

[John Heffner]

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

Re: [RFC] ip / ifconfig redesign

[Jeroen Massar]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]

Re: [RFC] ip / ifconfig redesign

[Marc Singer]

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.

Re: [RFC] ip / ifconfig redesign

[Ben Greear]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFC] ip / ifconfig redesign

[John W. Linville]

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
linville@tuxdriver.com

Re: [RFC] ip / ifconfig redesign

[Marc Singer]

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.

Re: [RFC] ip / ifconfig redesign

[Al Boldi]

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

Re: [RFC] ip / ifconfig redesign

[Al Boldi]

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