Roy Marples
2011-12-15 03:56:37 UTC
Hi List
I've finished an initial implementation of RFC6106 for the RDNSS and
DNSSL options within dhcpcd. This is only available right now from my
git repository (git clone git://roy.marples.name/dhcpcd.git)
I would really like feedback as it if it works for you, any deviations
from the spec and the full 9 yards. It's been tested on NetBSD-current
as of a few days ago and Ubuntu 10.04 LTS.
Notes:
dhcpcd will issue an RA solicitation ASAP. Should we try and wait until
a local IPv6 address has been configured?
DHCP allows the same option more than once if the option length
overflows. I cannot see this in the spec, thus it's not implemented.
Infact, it's actually hard to do as we option match the data to expire
the lifetime if applicable.
dhcpcd does only expires the whole RA on the router lifetime and
individual options when expiry is present.
dhcpcd does not re-request, it relies on the router to thump adverts
down at regular intervals once configured.
When the interface is "stopped" or the carrier is lost, dhcpcd will
discard all RA's received and configure for this. The rational is that
dhcpcd has behaved like this for years before IPv6 and I see no reason
why IPv6 should be special in this regard.
dhcpcd relies on the kernel to configure the address, lifetime and
routes. Patches are welcome to move this from the kernel into dhcpcd
*only* so that dhcpcd can control route preference with default routes
sa per user configuration. Something that the kernel cannot presently
do.
Devils Advocate: should the kernel be taught about interface metrics,
thus eliminating this need?
openresolv (resolvconf in NetBSD) support dnsmasq. The dnsmasq
subscriber has an error where it tries to translate all domains forwards
as ipv4 when dbus is configured. If you use IPv6 RA with RDNSS or DNSSL
alongside dhcpcd and resolvconf, then please update to the one found at
the git repo:
git clone git://roy.marples.name/openresolv.git
Comments on the above are very much welcome
Thanks
Roy
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
I've finished an initial implementation of RFC6106 for the RDNSS and
DNSSL options within dhcpcd. This is only available right now from my
git repository (git clone git://roy.marples.name/dhcpcd.git)
I would really like feedback as it if it works for you, any deviations
from the spec and the full 9 yards. It's been tested on NetBSD-current
as of a few days ago and Ubuntu 10.04 LTS.
Notes:
dhcpcd will issue an RA solicitation ASAP. Should we try and wait until
a local IPv6 address has been configured?
DHCP allows the same option more than once if the option length
overflows. I cannot see this in the spec, thus it's not implemented.
Infact, it's actually hard to do as we option match the data to expire
the lifetime if applicable.
dhcpcd does only expires the whole RA on the router lifetime and
individual options when expiry is present.
dhcpcd does not re-request, it relies on the router to thump adverts
down at regular intervals once configured.
When the interface is "stopped" or the carrier is lost, dhcpcd will
discard all RA's received and configure for this. The rational is that
dhcpcd has behaved like this for years before IPv6 and I see no reason
why IPv6 should be special in this regard.
dhcpcd relies on the kernel to configure the address, lifetime and
routes. Patches are welcome to move this from the kernel into dhcpcd
*only* so that dhcpcd can control route preference with default routes
sa per user configuration. Something that the kernel cannot presently
do.
Devils Advocate: should the kernel be taught about interface metrics,
thus eliminating this need?
openresolv (resolvconf in NetBSD) support dnsmasq. The dnsmasq
subscriber has an error where it tries to translate all domains forwards
as ipv4 when dbus is configured. If you use IPv6 RA with RDNSS or DNSSL
alongside dhcpcd and resolvconf, then please update to the one found at
the git repo:
git clone git://roy.marples.name/openresolv.git
Comments on the above are very much welcome
Thanks
Roy
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de