On Mon, Oct 13, 2008 at 01:17:38PM -0500, [EMAIL PROTECTED] wrote: > Just so I'm clear... when you say "ignore M/O and always run DHCPv6", does > that mean stateful or stateless DHCPv6? And of course, if it is "or", then > how is that determined without the M/O bits in the RA?
The general purpose answer is stateful, in terms of being simple to explain. But this is really "both." A DHCPv6 server will answer all Solicits, even if it has no addresses to provide, with an Advertise. The difference is in the status code in each IA. A client that has obtained, through extra-DHCPv6 means, a global address and has received Advertises with a status code other than Success can infer it should enter into stateless operation upon the conclusion of the current RT counter...there clearly is a DHCPv6 server which it could get configuration from, it just isn't "asking right". This is particularly true of clients with fixed manually- configured IPv6 addresses, they would go straight to stateless. But there are also contexts of clients that will consider the downgrade unacceptable, and will continue to Solicit regardless of Advertise content. It is, incredibly, contextually dependent. === RFC compliance Note that this suggestion is in stark contast to the current wording of RFC 3315, which directs that clients MUST ignore Advertises containing the status code 'NoAddrsAvail', the probable status code in the downgrade case...except to log them. I can't remember which section, but I remember wondering why we bother receiving packets just to ignore them. After doing all that work, it seems criminal not to log the message. This is later differentiated from the case where the global status code is Success (or non-present), and a subset of the client's IA's contain NoAddrsAvail status codes; in this case you do not ignore the message (but you might not select it). -- 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
pgpEhH7lZYmHL.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
