Seems like the protocol associated with the 'O' bit should be RFC 3736; there is no particular advantage to using the 4 message exchange of RFC 3315 for "other configuration information". The only potential advantage would be if there is ever a need for "other configuration information" that needs atateful assignment; we've never found a need for such assignment in DHCPv4.
Although exactly where prefix delegation falls is a little unclear...
- Ralph
At 12:42 AM 5/11/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
(changing the subject)
>>>>> On Sat, 08 May 2004 23:39:20 +0900, >>>>> JINMEI Tatuya <[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.
> Before going to further details, please let me clarify one thing about > RFC3736 (you should have meant RFC3736 by "RFC 3376" BTW).
> In my understanding, RFC3736 defines a certain class of implementation > that is a subset of RFC3315, even though RFC3736 is basically a > "guideline". Specifically, RFC3736 defines the implementation class > in its Section 5.
> So, there can be four types of servers and clients:
> A. servers that conform to RFC3315. (These servers also conform to > RFC3736) > B. clients that conform to RFC3315 (These servers also conform to ^^^^^^^should be "clients" > RFC3736) > C. servers that only conform to RFC3736 (and do not implement the rest > of RFC3315) > D. clients that only conform to RFC3736 (and do not implement the rest > of RFC3315)
> Is the above understanding correct?
No responses...so, assuming the understanding is correct, I believe the best protocol for the O flag is the subset of RFC3315 as defined in RFC3736 (aka "stateless DHCPv6"). The rationale is as follows:
As long as we need to care about type D clients (which do not support full RFC3315), servers must be configured to enable RFC3736, whether they can also support full RFC3315 or not.
But then, I don't see the reason for leaving flexibility by specifying a larger set (i.e., RFC3315) as the protocol for the O flag.
If we specify RFC3736 as the protocol,
- type A servers will be configured to act as RFC3736 servers (they may also act as full RFC3315 servers, but that doesn't matter here). - type B clients will perform RFC3736 to get the "other" configuration information, as a subset of their full ability. - type C servers will simply act as RFC3736 servers - type D clients will simply act as RFC3736 clients
On the other hand, if we just specify RFC3315 as the protocol, we'll be bothered about combination issues. In the following discussion, I'll call other configuration by request/reply exchanges "stateful other configuration".
- type A servers will at least need to be configured to enable RFC3736, as explained above. They may or may not enable the rest of RFC3315. - type B clients may perform RFC3736 only, stateful other configuration only, or both. + if the client only tries RFC3736, it will be happy, since type A servers should act as RFC3736 servers (type C servers can of course serve for the client). + if the client only tries stateful other configuration, the configuration will fail when type A servers do not enable stateful other configuration or there are only type C servers. + if the client tries both RFC3736 and stateful other configuration, what happens depends on the ordering. If it first tries RFC3736 or performs both concurrently, it will be happy. If it first tries stateful other configuration, the client can see a long delay before the configuration completes when type A servers do not enable stateful other configuration or there are only type C servers. - type C servers will simply act as RFC3736 servers. If there are type B clients that do not try RFC3736, the servers cannot serve for the clients. - type D clients will simply act as RFC3736 clients. The clients will be happy, since type A servers should act as RFC3736 servers (type C servers can of course serve for the client).
As shown above, a type B client can easily get stuck unless it is very carefully configured; to be able to configure itself in all the possible scenarios, the client will need to perform RFC3736 only, tries RFC3736 first (which should succeed), or tries both RFC3736 and stateful other configuration concurrently (at least the former should succeed). Then, why can't we simply specify RFC3736 as the protocol?
Meanwhile, leaving the flexibility may make sense if it has a clear advantage comparing to specify RFC3736 clearly. Regarding other configuration information, however, I don't see such an advantage that outweighs the complexity shown above.
Comments?
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 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
