Hi Jinmei,
This is a bit of a rant. Please accept my apologies. I'm quite concerned by the form of the document at the moment, although I think that the function needs to be available.
I think that the problems with the draft are not the policies themselves, but the distinction between
"Stateless DHCPv6" and "Stateful IPv6"
Where these are identified synonymously with 3315 (Stateful) and 3736 (Stateless).
The stateless DHCP RFC defines only Information-Request and Reply messages which require no server state, and therefore defines function which may be used when gathering information for use with the O flag.
The stateless RFC is aimed at SERVER implementers, though, and doesn't provide any new function description for hosts. This is important since a host doesn't know if their DHCP server is stateless or not.
The deployment of (only) a stateless server therefore precludes use of managed addressing, but deployment of a stateful server does not preclude its use for Information-Request messages from the host.
So really, in most places where there are descriptions of stateful and stateless service, this information is incorrect. In each of these cases, we're talking (once again) about managed addresses and Information-Requests (Other Config).
The M flag therefore maps to use of DHCPv6 Request,Renew,Rebind in order to attain or maintain an IPv6 address. Additional information may be passed with them which provides specific data such as for recursive DNS, etc.
The O flag maps to the use of DHCPv6 Information-Request to gather information without use of IAs.
We can actually use the terms in the DHCPv6 RFCs, since that's what we're trying to get working: DHCPv6 initiation based on RA.
If we follow this model,
the following are valid advertisement states for RAs:
M=on,O=on
Client: May use either Request/Renew/Rebind for
Managed Addressing or Information-Request
for Other Configuration.Server: Must have a stateful address server (RFC3315)
or relay to one. Also may have a Stateless server
(RFC3736) for Information-RequestsM=off,O=off
Client: May not use DHCPv6.
Server: There is likely to be no server on this network.
M=off,O=on
Client: May use Information-Request for Other
Configuration. Should not use DHCPv6 for
address assignment.Server: May have either a stateful (RFC3315) or
stateless (RFC3315) server.
M=on,O=off INVALID STATE!
This state is invalid, since we can't stop hosts from doing Information Requests, even if our server is required to be an RFC 3315 server.
Please be aware that I didn't mention policy. Policy is not essential to defining how the Flags need to be interpreted on hosts, nor how the servers are deployed.
Perhaps policy is useful in such a document, but in this case we need to make sure that the terminology attached to the policy is concrete and mandates usage of specific messages, in specific situations.
At this stage, I think that the policy section is OK except for the imprecise usage of the terms 'stateless' and 'stateful'.
JINMEI Tatuya / ???? wrote:
Hi, thanks for the prompt response.
On Thu, 05 Aug 2004 08:49:54 +0000 (GMT), Greg Daley <[EMAIL PROTECTED]> said:
I hope that there has been some clarifcation.
Yes, it helped, but I'm still not sure if I understand the entire point...
I hope that my description above helps to indicate the point, even if it's not agreed with.
I was concerned that M|O could be used to invoke DHCP information-requests
(rather than just O).
Are you saying that if the host receives an RA with the both M and O flags being set it could invoke both RFC3315 and RFC3736 with the proposed policy (or even could invoke RFC3736 only)? This is not correct: the draft says in section 5.0 that
Case: M=ON and O=ON
Scenario 7: If M-Policy is 1 or 2
The host invokes Stateful DHCPv6 and does not invoke Stateless DHCPv6 regardless of O-Policy.
In general, the proposed approach separately defines two policy variables (M and O) corresponding to the RA's M and O flags, respectively, but it also considers inter-relationship between the two policies / two flag values like this case.
Does this basic approach address your concern, or are you worrying about this approach itself?
No.
As above, the hosts don't implement stateful or stateless DHCPv6 (servers have the concept of state). They need to know which messages to send.
The draft as defined doesn't specify this precisely.
There are 2 issues:
"Stateful DHCP" Doesn't mean managed addressing (though it is required to achieve this).
"Stateless DHCP" isn't required for Information-Requests.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
