Hi Stig,
I think that some of the ideas which you present are in accordance with some of the things I've been thinking about.
I'm not strictly tied to one (M=3315/O=3736 or M=Req,Renew.../O=Info Request) though. I think that there are issues to be worked out based on either course.
Stig Venaas wrote:
On Fri, Aug 13, 2004 at 02:28:46PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: [...]
Why? In this (i.e., the latter) scenario, does M=1/O=0 simply mean that (Solicit/Advertise/Request/Reply and)Rebind/Renew/Request is available but Information Request is not? Perhaps this is inconvenient, but I don't see why this combination is invalid.
I tried to say something about that in my previous mail. I think it should be invalid.
A DHCPv6 server should either be a server according to RFC 3315 in which case it must support all these messages, or it must support the subset listed in RFC 3736 (Information-Request/Reply). Is someone seriously suggesting the possibility of servers supporting only Solicit/Advertise/Request/Reply? I think that would be a bad idea. If server supports all of RFC 3315, it doesn't make sense to make clients only use part of the available functionality.
I also believe some DHCP clients may use both Request/Renew/Rebind and Information-Request. A client may initially do a Request to obtain an address and other infortmation. There might be reasons for a host to later ask for another option long before it needs to renew its addresses. In that case it might be reasonable for the client to do only an Information-Request.
If you define O to show whether information-request can be done or not, that's fine by me. It would then follow that M=1, O=0 is what you say, but I'm arguing that it doesn't make sense. I would prefer saying that this combination should not be used and ignored, or that when M is set, the O is ignored.
The M bit being set causing ignorance of O would be a valid way of describing M=RFC3315/O=RFC3736 which I'd be comfortable with.
It works since all RFC3736 hosts can support Information-Requests as described in RFC3315.
If M=Request/Renew/Rebind and O=Information Request, it may be hard to conceive of a situation where you'd only want to support Request/etc.
If it's a reasonable thing to do (prevent I-Rs), then perhaps a short example reason (a sentence) for this would be useful.
Actually I think the really best would be to combine M and O into a 2-bit value (2*M+O) so that you have values 0-3 where we define 0, 1 and 3, while the value 2 is reserved for future use. By definining M and O separately per the current proposal it's hard to use M=1, O=0 for something completely different in the future, it will probably end up not being used for anything.
I'd prefer not to redefine the fields into a combined value myself.
If we've got a belief that preventing Information-Requests is unhelpful, then it is sufficient to indicate M=1,O=0 is invalid and should not be used.
Reserving a single value in a 2-bit field for future use seems overkill when ND options are available and will not have backward compatability issues.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
