>>>>> On Wed, 28 Apr 2004 12:16:15 -0400,
>>>>> Ralph Droms <[EMAIL PROTECTED]> said:
> I think the O flag (if we keep it!) should simply specify DHCPv6, with no
> implication about the way in which DHCPv6 is used.
> "Stateless DHCPv6" is simply a way to use some of the messages from the full
> specification in RFC 3315. RFC 3376 is a guideline to the implementation of
> DHCPv6 that uses just Information-request/Reply messages. A client can
> choose to use the Request/Reply or the Information-request/Reply message
> exchange to obtain other configuration information without address assignment.
A quick question for clarification: do you mean a client can choose to
use the request/reply message exchange to obtain other configuration
information without address assignment (in addition to
information-request/reply exchange)? If so, I have several related
questions.
In this scenario, the client first sends a Solicit message.
RFC3315 says in 17.1.1 that
The client includes IA options for any IAs to which
it wants the server to assign addresses.
If the client does not want address assignment, is it okay for the
client to send a Solicit without including an IA option? It's not
clear to me, but this is probably okay (at least the RFC does not seem
to prohibit it).
Then, the server seems to take the following action according to
Section 17.2.2 of RFC3315:
If the server will not assign any addresses to any IAs in a
subsequent Request from the client, the server MUST send an Advertise
message to the client that includes only a Status Code option with
code NoAddrsAvail and a status message for the user, a Server
Identifier option with the server's DUID, and a Client Identifier
option with the client's DUID.
And the client will ignore the Advertise message because in Section
17.1.3 the RFC says:
The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message to the
user.
and so the exchange should fail at this stage.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
