Just a few things that I think are potential factual errors or misreads that need clarifying.
On Tue, Oct 14, 2008 at 09:48:42AM +0200, Iljitsch van Beijnum wrote:
> It's not a question of "problematic yes/no". More multicasts means less
> performance for other stuff. Obviously ARP and ND already generate
> multicasts, as do various discovery systems such as netbios and multicast
> DNS.
Note that if you're concerned about Multicasts, a DHCPv6 client in
steady-state will, at the server's will, unicast its renewal messages
as well as receive unicast replies. DHCPv6 only requires multicast
to locate DHCPv6 servers. Once located, the servers may express
their will to receive further unicasts.
DHCPv6 clients are not required to perform DAD, as the address is
assigned by a central authority and the potential for conflict is
very low. So no spurious ND multicasts.
In the final analysis, there's far less required multicasts in a
DHCPv6-only design overall.
> Which there of course is and has been for
> a very long time in the form of the M/O bits.
This is potentially a factual misrepresentation depending on how you
read it; it could imply that on today's networks you can reliably
disable DHCPv6 client transmission by clearing the bits.
The truth as I am given to understand it is that client implementation
of the bits vary, in ways that can only be described as independent
and incompatible interpretations of IETF RFC's at best ("totally
broken" at worst).
Clearing the bits is not reliable among all DHCPv6 client
implementations. It is not a tool anyone can realistically
believe they possess today.
> Opening a raw socket and listening for RAs is also a possibility. It's not
> like sending out packets with the unspecified address is a standard call;
> DHCP implementations need to be close to the network anyway.
DHCPv6 has no such requirement thanks to link-local addressing. ISC's
DHCPv6 software suite uses standard sockets, no raw sockets. The
server and relay just have additional system calls to join the
appropriate multicast memberships.
Our DHCPv6 software has very little knowledge of the host OS's network
related software. Configuration is managed via shell-scripts written
by the system integrator (so no kernel methods are required to set
addresses on an interface, for example). Our software does poll
standard API's for MAC addresses to assign a DUID-LLT if one hadn't
been generated already; but even this is not a hard requirement of the
protocol, merely an implementation choice we made. The client is free
to allocate a DUID-EN, which need not be based on anything from the
host OS's network stack.
So, no such "closeness to the network" exists today, and I would
resist creating any. We found many DHCPv4 client implementations
that were notoriously distant from the host's network related
systems (unable to determine its own IPv4 addresses, unaware of which
'interface' might be used, and certainly incapable of determining its
MAC address, all of which leads to some very strange looking DHCPv4
packets), which suggests creating new forms of closeness is not
desirable for the long-term welfare of the protocol.
--
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
pgpjLDAFfZv3N.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
