How do I keep an inet6 address from being added to an interface?

[Dennis Ferguson]

Hello,

I want to configure an interface up without any protocol addresses
being added to (or protocols enabled on) the interface. I see,
however, that the act of typing `ifconfig rtk0 up' results in
an ipv6 address being added to the interface, which I assume
also enables ipv6 protocol processing. How do I make it stop
doing that?

Thanks,
Dennis Ferguson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthew Mondor]

On Wed, 5 May 2010 10:10:43 -0700

Post by Dennis Ferguson
Hello,
I want to configure an interface up without any protocol addresses
being added to (or protocols enabled on) the interface. I see,
however, that the act of typing `ifconfig rtk0 up' results in
an ipv6 address being added to the interface, which I assume
also enables ipv6 protocol processing. How do I make it stop
doing that?

Hmm after looking at sysctl(8) net.inet6 stubs and in6_ifattach.c there
seems to be no option that I see for that in netbsd-5. It's part of
the ipv6 standard that interfaces have an automatic link-local address,
and that address can only be used on the local network, but I guess
that it could be legitimate for some administrator to not want a
link-local address configured.

However, it is possible to disable listening to router advertisements
using net.inet6.ip6.accept_rtadv = 0 and to prevent a v6 socket from
accepting v4 to v6 mapping using net.inet6.ip6.v6only = 1.

Also, have you tried removing the link-local address using ifconfig?
If that works, that address is supposed to remain the same for that
interface, so a script could do it easily once you know the address to
remove.

[der Mouse]

Post by Matthew Mondor
However, it is possible to disable listening to router advertisements
using net.inet6.ip6.accept_rtadv = 0

...though that affects the whole system and thus might be suitable in
this case.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Matthew Mondor
Hmm after looking at sysctl(8) net.inet6 stubs and in6_ifattach.c there
seems to be no option that I see for that in netbsd-5. It's part of
the ipv6 standard that interfaces have an automatic link-local address,
and that address can only be used on the local network, but I guess
that it could be legitimate for some administrator to not want a
link-local address configured.

It may be part of the IPv6 standard that an interface used for
IPv6 needs a link-local address, but it isn't part of any standard
that every interface in the box needs to run IPv6 (or IPv4, or Appletalk,
or anything in particular). I'd like to use this interface for
user-space protocol processing, so I'm trying to keep the packets
it receives out of the kernel.

Post by Matthew Mondor
However, it is possible to disable listening to router advertisements
using net.inet6.ip6.accept_rtadv = 0 and to prevent a v6 socket from
accepting v4 to v6 mapping using net.inet6.ip6.v6only = 1.

There is also a variable ip6_auto_linklocal which can be set to zero
(with the debugger rather than sysctl) which keeps it from adding
addresses automatically, but doing this or any of the above also screws
up ipv6 on the other interface in the box where I was hoping to keep it
running.

Post by Matthew Mondor
Also, have you tried removing the link-local address using ifconfig?
If that works, that address is supposed to remain the same for that
interface, so a script could do it easily once you know the address to
remove.

I tried this, but ifconfig inet6 delete is disallowed for ipv6 (this
is documented on the manual page), while ifconfig -alias seems to produce
an error when trying to take off the last remaining address. There seems
to be no way to get it off once it is on there that I can find.

I think the fundamental problem is that BSD Unix networking has never
had a way to enable or disable protocols on an interface separate from
the act of adding and deleting the protocol's adresses to/from the interface.
For ipv6's magically added addresses there is no ipv6_enabled flag to look
at to tell when this is or isn't appropriate (this is also a bug for ipv4,
actually, since it forces all interfaces enabled for ipv4 to have addresses
even though point-to-point interfaces run just fine without them). It
would have been better if the ipv6 code had fixed this by adding explicit
protocol enable flags, however, rather than just forcing you to run
the protocol on every interface on the box if you want to run it on any
of them.

Dennis Ferguson
run ipv4 just fine without them)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Arnaud Lacombe]

Hi,

Post by Matthew Mondor
On Wed, 5 May 2010 10:10:43 -0700

Post by Dennis Ferguson
Hello,
I want to configure an interface up without any protocol addresses
being added to (or protocols enabled on) the interface.  I see,
however, that the act of typing `ifconfig rtk0 up' results in
an ipv6 address being added to the interface, which I assume
also enables ipv6 protocol processing.  How do I make it stop
doing that?

Hmm after looking at sysctl(8) net.inet6 stubs and in6_ifattach.c there
seems to be no option that I see for that in netbsd-5.  It's part of
the ipv6 standard that interfaces have an automatic link-local address,
and that address can only be used on the local network, but I guess
that it could be legitimate for some administrator to not want a
link-local address configured.

actually, there is a way, `ip6_auto_linklocal', but it is not made
public. Maybe could we expose it in the sysctl tree ?

- Arnaud

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven Bellovin]

Post by Arnaud Lacombe
Hi,

Post by Matthew Mondor
On Wed, 5 May 2010 10:10:43 -0700

Post by Dennis Ferguson
Hello,
I want to configure an interface up without any protocol addresses
being added to (or protocols enabled on) the interface. I see,
however, that the act of typing `ifconfig rtk0 up' results in
an ipv6 address being added to the interface, which I assume
also enables ipv6 protocol processing. How do I make it stop
doing that?

Hmm after looking at sysctl(8) net.inet6 stubs and in6_ifattach.c there
seems to be no option that I see for that in netbsd-5. It's part of
the ipv6 standard that interfaces have an automatic link-local address,
and that address can only be used on the local network, but I guess
that it could be legitimate for some administrator to not want a
link-local address configured.

actually, there is a way, `ip6_auto_linklocal', but it is not made
public. Maybe could we expose it in the sysctl tree ?

Does that work on per-interface?

I've often wanted such a feature: a way to ensure that NetBSD's kernel neither sends or acts on *any* packet received on certain interfaces.

--Steve Bellovin, http://www.cs.columbia.edu/~smb






--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Steven Bellovin
I've often wanted such a feature: a way to ensure that NetBSD's
kernel neither sends or acts on *any* packet received on certain
interfaces.

I added a handful of interface flags to 1.4T, and one of them was
BPFONLY; when set, packet reception short-circuits everything after
bpf. Not quite what you want, because it affects input only.

The most difficult part was finding (and fixing) everything that
treated interface flags as a 16-bit bitmask; I can't believe it would
be all that hard to add to -current.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Arnaud Lacombe]

Hi,

Post by Steven Bellovin

Post by Arnaud Lacombe
Hi,

Post by Matthew Mondor
On Wed, 5 May 2010 10:10:43 -0700

Post by Dennis Ferguson
Hello,
I want to configure an interface up without any protocol addresses
being added to (or protocols enabled on) the interface.  I see,
however, that the act of typing `ifconfig rtk0 up' results in
an ipv6 address being added to the interface, which I assume
also enables ipv6 protocol processing.  How do I make it stop
doing that?

Hmm after looking at sysctl(8) net.inet6 stubs and in6_ifattach.c there
seems to be no option that I see for that in netbsd-5.  It's part of
the ipv6 standard that interfaces have an automatic link-local address,
and that address can only be used on the local network, but I guess
that it could be legitimate for some administrator to not want a
link-local address configured.

actually, there is a way, `ip6_auto_linklocal', but it is not made
public. Maybe could we expose it in the sysctl tree ?

Does that work on per-interface?
I've often wanted such a feature: a way to ensure that NetBSD's kernel neither sends or acts on *any* packet received on certain interfaces.

No, it is done when the interface is attached, so before any user
intervention is possible; if I'm not mistaken. This would make the
sysctl useless, so this would have to be a hardcoded default.

- Arnaud

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven Bellovin]

Post by der Mouse

Post by Steven Bellovin
I've often wanted such a feature: a way to ensure that NetBSD's
kernel neither sends or acts on *any* packet received on certain
interfaces.

I added a handful of interface flags to 1.4T, and one of them was
BPFONLY; when set, packet reception short-circuits everything after
bpf. Not quite what you want, because it affects input only.

Right, but certainly a good step. (Way back when, in the days of thick coax and 15-pin drop cables to transceiver bricks, I *really* wanted to be sure that a machine would *never* transmit. After staring at the kernel for a while, I decided to clip the transmit leads -- nothing else looked high-enough assurance.)

Post by der Mouse
The most difficult part was finding (and fixing) everything that
treated interface flags as a 16-bit bitmask; I can't believe it would
be all that hard to add to -current.
/~\ The ASCII Mouse
\ / Ribbon Campaign
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--Steve Bellovin, http://www.cs.columbia.edu/~smb






--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Steven Bellovin

Post by der Mouse
I added a handful of interface flags to 1.4T, and one of them was
BPFONLY; when set, packet reception short-circuits everything after
bpf. Not quite what you want, because it affects input only.

Right, but certainly a good step. (Way back when, in the days of
thick coax and 15-pin drop cables to transceiver bricks, I *really*
wanted to be sure that a machine would *never* transmit. After
staring at the kernel for a while, I decided to clip the transmit
leads -- nothing else looked high-enough assurance.)

Yeah. One of the regressions of the switch to twisted-pair.

Of course, I don't know the kernel you were using, but maybe you could
have done something to the output routine for the network interface in
question? That strikes me as being about as good as you're going to
get short of a hardware answer such as you ended up with.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Arnaud Lacombe
No, it is done when the interface is attached, so before any user
intervention is possible; if I'm not mistaken. This would make the
sysctl useless, so this would have to be a hardcoded default.

While the name of the function suggests it runs when the
interface is attached I don't think it actually works
that way. If you boot a system without configuring the
interfaces, the interfaces are attached (obviously) but
there are no link local addresses on the interfaces.
Configuring the interface 'up' is the event which causes
the link local address to be added.

Never-the-less the flag is global, rather than per-interface,
so turning it off causes problems with interfaces where you
want the link local addresses, and it still does other ipv6
initialization work which looks suspicious to me even if it
doesn't add the addresses. Doing it better would require
per-interface protocol enables.

Dennis Ferguson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Dennis Ferguson
I tried this, but ifconfig inet6 delete is disallowed for ipv6 (this
is documented on the manual page), while ifconfig -alias seems to produce
an error when trying to take off the last remaining address. There seems
to be no way to get it off once it is on there that I can find.

I use this, which seems to work on NetBSD 5.

#!/bin/sh

# Copyright 2009 Coyote Point Systems, Inc. All rights reserved.

# Usage: stripv6 <if> removes the autoconfigured IPv6 address, if any,
# from network interface <if>, allowing it to be
# attached to an upper-layer interface such as an agr.
#
# Exit status: 0 if an address is removed, 1 elsewise.

autov6=$(ifconfig $1 \
| awk '/inet6 fe80/ { split($2, a, "%"); printf("%s", a[1]) }')

if [ -n "$autov6" ]; then
ifconfig $1 inet6 $autov6 -alias
exit 0
fi

exit 1


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Thor Lancelot Simon
ifconfig $1 inet6 $autov6 -alias

Thanks, that works for me too, now, with -current. I'm not
sure what I screwed up when I tried this first time.

Dennis Ferguson


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Dennis Ferguson
I think the fundamental problem is that BSD Unix networking has never
had a way to enable or disable protocols on an interface separate from
the act of adding and deleting the protocol's adresses to/from the interface.

Yes, together with the v6 auto link local notion.

Post by Dennis Ferguson
For ipv6's magically added addresses there is no ipv6_enabled flag to look
at to tell when this is or isn't appropriate (this is also a bug for ipv4,
actually, since it forces all interfaces enabled for ipv4 to have addresses
even though point-to-point interfaces run just fine without them). It
would have been better if the ipv6 code had fixed this by adding explicit
protocol enable flags, however, rather than just forcing you to run
the protocol on every interface on the box if you want to run it on any
of them.

It would seem reasonable to add per-interface protocol enable flags
(defaulting on probably) that you could unset prior to ifconfig up.
(That won't fix the v4 POINTOPOINT issue, but that seems not to be a big
deal right now.)

[Dennis Ferguson]

Post by Greg Troxel

Post by Dennis Ferguson
For ipv6's magically added addresses there is no ipv6_enabled flag to look
at to tell when this is or isn't appropriate (this is also a bug for ipv4,
actually, since it forces all interfaces enabled for ipv4 to have addresses
even though point-to-point interfaces run just fine without them). It
would have been better if the ipv6 code had fixed this by adding explicit
protocol enable flags, however, rather than just forcing you to run
the protocol on every interface on the box if you want to run it on any
of them.

It would seem reasonable to add per-interface protocol enable flags
(defaulting on probably) that you could unset prior to ifconfig up.
(That won't fix the v4 POINTOPOINT issue, but that seems not to be a big
deal right now.)

When I did this as part of a rewrite of the network stack in
support of large routers I added an extra layer of structure to
support this (and to provide a place to hang protocol-specific
per-interface data structure they required, rather than that
big, mostly unused, array in struct ifnet). That is, instead
of having an interface structure onto which were configured address
structures for various protocols, there was instead an interface
structure onto which was configured protocol family structures,
onto which was configured zero or more addresses for that protocol.
The kernel ignored incoming packets for protocols without a
corresponding family configured on the arrival interface, and had
no way of sending packets without a corresponding family configured,
so an interface with the hardware configured up but with no family
structures added was guaranteed to be silent and to ignore
everything which arrived (other than maybe giving it to bpf).
To configure a protocol you first configured it 'up', which
added the family structure, and then configured (or not)
addresses onto it.

To add protocol addresses (i.e. adding address structures to
the protocol family structure) required configuring the protocol
'up' first (to add the family structure). An unnumbered p2p
interface had the protocol configured 'up' (adding the family
structure) without bothering to add addresses. The act of adding
the ipv6 family structure is the thing which prompted ipv6 to
make up a link local address.

That's a long way of saying that you probably want to start with
all protocols configured off by default, since the act of configuring
them on is also the act you want to prompt the protocol to do
the protocol-specific things that need to be done for the interface
(like adding a link-local address, or maybe the per-interface data
structure needed for nd/arp). If you start with them 'on' then you
still have the problem of finding some event to make the protocol
to do the work which needs to be done to really turn them on.

Dennis Ferguson
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de