Hello, David.
A few comments are inserted.
2008/10/23 David W. Hankins <[EMAIL PROTECTED]>:
> 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.
>
What if DHCPv6 servers do not exist? AFAIK, in this thread, the cost
of unnecessary multicast DHCPv6 messages which may be prevented
through M&O bits are being discussed.
> 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.
>
This does not comply with RFC4862. See section 5.4.
5.4. Duplicate Address Detection
Duplicate Address Detection MUST be performed on all unicast
addresses prior to assigning them to an interface, regardless of
whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration, with the following exceptions:
AFAIK, IPv6 stack in OS kernel does not provide special interface for
address configuration by DHCPv6 client. This means that manual
configuration using shell command like "ifconfig ..." or CLI command
like "ipv6 address ...." and autoconfiguration through DHCPv6 are not
distingushable, so DAD is performed per configured address. This is
right and robust way as the RFC says. As you know very well, DHCPv6
has a Decline message to deal wih duplicate addresses.
> 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.
>
According to RFC2461/2462, there is no implication for what you are saying.
> 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.
>
Right. As I presented last 71st IETF dhc meeting, Vista does not
comply with the RFCs in that client send Release messsages to
invalidate bindins in server and remove obtained addresses when it
receive RA with M flag set to 0 (I am not sure that this is latest
behavior.) However, this may be not the case of many other
implementations. Since both current and old specifications do not deal
with the transition of bits, we believe that clear docuement should be
published addressing known issues in our draft.
Joseph
>> 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
>
> _______________________________________________
> dhcwg mailing list
> [EMAIL PROTECTED]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
