gmane.os.netbsd.devel.network

Re: PATCH to only announce RTM_NEWADDR once IPv6 DAD completes

Greg Troxel — 2013-05-15T17:06:24

Roy Marples <roy< at >marples.name> writes:


Not specifically.  I just meant that there is a correctness notion that
goes something like

   an address is in the kernel and not tentative
     if and only if
   a NEWADDR without a matching DELADDR has been received

so that a watcher that does bookeeping is guaranteed to have the right
state.  Right now I think that rule works, except for the 'not
tentative'.

If it's always the case that it's a one-way trip from tentative to
non-tentative to removed, then there are probably no issues.

Re: PATCH to only announce RTM_NEWADDR once IPv6 DAD completes

Roy Marples — 2013-05-15T16:59:41

As the kernel (currently) doesn't set the tentative bit before sending 
RTM_NEWADDR I don't see
how this helps solve the initial issue as I doubt any userland 
application currently checks for the tentative flag.

I could be wrong though.

Roy

Re: PATCH to only announce RTM_NEWADDR once IPv6 DAD completes

Christos Zoulas — 2013-05-15T13:15:55

In article <b18662cb2f9eb1c8b4ede6b6b31e9235< at >mail.marples.name>,
Roy Marples  <roy< at >marples.name> wrote:

Doesn't the tentative bit get passed in the rtm message? Why not pass
the full information to userland and let it do what it wishes?

christos

Re: PATCH to only announce RTM_NEWADDR once IPv6 DAD completes

Roy Marples — 2013-05-15T12:06:54

You mean what happens when a conflict is detected?
I'm not sure that generating DELADDR is the right thing to do as it 
does exist within the kernel.
Maybe a new message, RTM_DUPADDR? That suffers from the same possible 
crash for badly written programs though.

Roy

Re: PATCH to only announce RTM_NEWADDR once IPv6 DAD completes

Greg Troxel — 2013-05-15T11:07:53

It seems like this behavior should be documented in a man page
somewhere, probably route(4).  The change seems sensible, but it opens
up a question of what the invariant is.  I think it's something like

  all configured addresses which are not tentative have had a NEWADDR
  sent (that has not been withdrawn by a DELADDR).

Basically, I'd like a spec of how to take a stream of NEW/DEL and a set
of current addresses and say if the behavior is right.  I don't mean to
suggest that you've done anything that breaks what the spec ought to be,
but it feels tricky.

PATCH to only announce RTM_NEWADDR once IPv6 DAD completes

Roy Marples — 2013-05-15T08:24:24

Hi List

Old discussion references:
http://mail-index4.netbsd.org/tech-net/2012/10/19/msg003676.html
http://mail-index.netbsd.org/current-users/2010/05/12/msg013334.html
http://mail-index.netbsd.org/current-users/2010/05/25/msg013529.html
http://mail-index.netbsd.org/tech-net/2010/05/25/msg002094.html

I agree with the latest proposal and attach a patch for review to 
address it.
I've been testing this with a new dhcpcd build which listens for 
RTM_NEWADDR or a duplicate NA message and reacts accordingly.
This is important as not only daemons fail to bind with a tentative 
address from a RTM_NEWADDR message, but one shot things normally run 
after successful address configuration, such as ntpdate also fail.

Although dhcpcd does have it's own DAD engine, it's not RFC 
conformation (no kernel allows it to be), so getting kernels to 
correctly announce RTM_NEWADDR when the address is ready does at least 
allow userland applications such as dhcpcd to take advantage of the 
kernel DAD.

Comments are welcome, pro

Re: Patch to implement SIOCGIFINDEX

Matt Thomas — 2013-04-22T16:53:01

On Apr 22, 2013, at 9:47 AM, Christos Zoulas <christos< at >astron.com> wrote:


Might want a SIOCGIFNAME too since you could use it to get an interface's
name by its index (you can open an interface by if<index> where is the
decimal index; like if1, if29, etc.).

Re: Patch to implement SIOCGIFINDEX

Christos Zoulas — 2013-04-22T16:47:33

In article <5174AC05.3030504< at >chocot.jp>,
Masaru OKI  <masaru+oki< at >chocot.jp> wrote:

Someone else asked for it too, so I guess it is kind of popular...

christos

Re: Patch to implement SIOCGIFINDEX

Masaru OKI — 2013-04-22T03:18:29

FreeBSD already has SIOCGIFINDEX, and if_nametoindex(3) uses it.
it is useful, i think.

(2013/04/02 8:13), Ty Sarna wrote:

Re: net.inet6.ip6.v6only

Greg Troxel — 2013-04-18T15:42:04

Edgar Fuß <ef< at >math.uni-bonn.de> writes:


man ip6(4)
search for IPV6_V6ONLY

Re: net.inet6.ip6.v6only

Edgar Fuß — 2013-04-18T15:39:03

How?

Re: net.inet6.ip6.v6only

Joerg Sonnenberger — 2013-04-18T15:30:08

An application that knows how to deal with mapped V4 addresses can
enable it explicitly for a socket.

Joerg

Re: net.inet6.ip6.v6only

Greg Troxel — 2013-04-18T14:36:04

Edgar Fuß <ef< at >math.uni-bonn.de> writes:


No, it's primarily (in practice anyway) about incoming connections.

My understanding is that there is optional support for mapped addresses,
where an incoming v4 connection will match a v6 socket and present a v6
address of the v4-mapped variety.


mapped addresses are confusing, which is a security issue.  Someone who
wishes to block v4 connections with an acl has to extend the acl to
cover the mapped addresses, and things like that.

 
If so, they are buggy.  Best practice is for programs to have a v4 and a
v6 socket and do things in parallel.  That's how almost everything works
now (apache, dovecot, postfix, ntpd, named, inetd/sshd are examples that
come to mind quickly).

net.inet6.ip6.v6only

Edgar Fuß — 2013-04-18T13:05:53

I have some questions on net.inet6.ip6.v6only.

First: What does it mean, exactly?
My best guess is "a socket created with a domain argument of PF_INET6 will not
conect() to a RFC 3493 v6-mapped v4 address".

Second: What's the rationale behind the default being 1?

Third: What's the drawback (or what are the security implications) of setting
the knob to 0, i.e. enabling mapped addresses? My impression is that neither
squid nor lighttpd will, on a host with non-local v6 adresses, work correctly
without because they (on a v6 host) will only create PF_INET6 sockets and then
try to connect to v6-mapped v4 adresses.

Re: Seeking opinion on where networking-related user space code should go

Matt Thomas — 2013-04-16T23:36:25

On Apr 16, 2013, at 4:35 PM, Beverly Schwartz <bschwart< at >bbn.com> wrote:


we use sysctl for getting the routing table and pcblists.

Re: Seeking opinion on where networking-related user space code should go

Beverly Schwartz — 2013-04-16T23:35:31

On Apr 16, 2013, at 7:28 PM, Matt Thomas <matt< at >3am-software.com> wrote:


sysctl isn't designed to dump huge amounts of data.  I can imagine it would be very annoying if when doing sysctl kern.mbuf, a deluge of data comes along.  I would be producing more data than what sysctl -a produces several times over.

netstat -m -v
sounds like a good option.

-Bev

Re: Seeking opinion on where networking-related user space code should go

Beverly Schwartz — 2013-04-16T23:38:45

On Apr 16, 2013, at 7:36 PM, Matt Thomas <matt< at >3am-software.com> wrote:


Could you point me to an example where this is done?  Thanks.

-Bev

Re: Seeking opinion on where networking-related user space code should go

Matt Thomas — 2013-04-16T23:28:09

On Apr 16, 2013, at 3:55 PM, Beverly Schwartz <bschwart< at >bbn.com> wrote:


sysctl kern.mbuf….

seems like netstat -m should display it if available.
maybe -m -v

Seeking opinion on where networking-related user space code should go

Beverly Schwartz — 2013-04-16T22:55:46

I have created a facility in the kernel for tracking mbuf clusters.  (Twice at BBN, we have successfully used this cluster tracking code to find mbuf cluster leaks.)

This facility can be compiled in the kernel by enabling the option MCL_DEBUG.

If MCL_DEBUG is enabled, then tracking data is kept for each mbuf cluster.  Examples of data kept:
When and where in the code the cluster was allocated.
When and where in the code the cluster was freed.
When and where the cluster was queued or dequeued.
When and where the cluster was passed from one protocol to another.

At each of these points, I note which CPU we're on, the LWP id, whether or not we have KERNEL_LOCK and/or softnet lock, if there was something anomalous.  Anomalies detected: cluster allocated twice without being freed in-between, cluster freed without being allocated, cluster unallocated when expected to be allocated, lock not held when expected to be held.

I have set up code in /proc for accessing the data, but it would be nice to have a user spac

Re: Increase tcp initial window

Christos Zoulas — 2013-04-07T18:03:07

In article <20130406100906.GA3213< at >wolfman.devio.us>,
Loganaden Velvindron  <loganaden< at >wolfman.devio.us> wrote:

As I mentioned before, this ship has sailed:

1.29         (thorpej  11-Dec-97):      { "init_win", CTLTYPE_INT }, \

We already allow setting the initial window to anything, but some people
cannot be bothered to read the source instead of arguing.

christos

Re: Bug in FAST_IPSEC

Christos Zoulas — 2013-04-05T20:55:48

In article <D0E89213-567B-402E-A0EE-9A0DFFE6D07A< at >bbn.com>,
Beverly Schwartz  <bschwart< at >bbn.com> wrote:

Hi Beverly,

I think you can answer both questions with experimentation. For 1,
you can try to move the lock and see if that has ill effects (with
LOCKDEBUG). For 2 you can replicate your test and not lock if ifp is
NULL. I am inclined to commit what you have now, because it fixes the
problem, and it does not matter too much for the future because all
the locking will need to be redone in the networking stack.

christos