PATCH to only announce RTM_NEWADDR once IPv6 DAD completes

[Roy Marples]

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, probably comitting it over the weekend with
hopefully a new dhcpcd shortly afterwards.

Thanks

Roy

[Greg Troxel]

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.

[Roy Marples]

Post by Greg Troxel
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.

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



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

[Christos Zoulas]

Post by Roy Marples

Post by Greg Troxel
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.

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.

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


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

[Roy Marples]

Post by Christos Zoulas

Post by Roy Marples

Post by Greg Troxel
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.

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.

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?

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

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

[Roy Marples]

Post by Christos Zoulas

Post by Roy Marples
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.

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?

This is now what my latest patch does.
Userland is responsible for checking the flags.

Thanks

Roy

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

[Christos Zoulas]

Post by Roy Marples

Post by Christos Zoulas

Post by Roy Marples
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.

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?

This is now what my latest patch does.
Userland is responsible for checking the flags.

Greate, thanks!

christos


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

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.

[Roy Marples]

Post by Greg Troxel

Post by Roy Marples
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.

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.

Well, with this new patch there should be no issues.
I have also extended the patch slightly - we now issue a RTM_NEWADDR on
each flag change except when we add a new address marked tentative
or the flag changes to tentative. In this case we report the result of
the DAD. This mirrors Linux behavior which seems to work quite well.

Comments welcome.

If someone can suggest text to route(4) that would be nice to as I'm
suffering from writers block!

Thanks

Roy