Having been reviewing the combined ICMPv6 drafts and following this thread, I would support Stig's ideas here.
The wording around 3315/3736 needs to be cleared up because a naive reader *would be* confused by the juxtaposition of 'stateful', 3736 and 3315 - but that has been done to death - Hopefully Jinmei-san will have a proposal for us.
A related point is exactly what 'other config' a host might expect to obtain. This has been deliberately left vague and I don't have a problem with that, but I think it would be useful to make it clear whether or not the stuff that may be in an RA but which isn't prefix info (and isn't the M and O flags!)is something that could be obtained from a DHCPv6 server (either statefully or statelessly). If it can or could be obtained from both RA and DHCP then some words should be added about how the two sources should be combined (related to the discussion on getting info from multiple routers). I appreciate that it is possible this was discussed a long time ago - in any case I think the position ought to be documented. This is probably another area where policy needs to be defined.
At least two or three of the values (MTU, Reachability Time and Restransmission Time) are useful/needed on links without routers (or without RAs).
Some of this may need to go into RFC2461bis rather than 2462bis.
I think it would also be helpful to reiterate in the protcol overview what is implied by the final sentence in 5.5 of 2462bis - that the default out-of-the-box settings MUST enable stateless autoconfiguration so that hosts are 'plug-and-play' by default as is intended by the design goals.
Regards,
Elwyn
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 13 August 2004 10:16
> To: JINMEI Tatuya / [EMAIL PROTECTED]@C#:H
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Stateful != M , Stateless != O
>
>
> 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.
>
> 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.
>
> Stig
>
> --------------------------------------------------------------------
> 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 --------------------------------------------------------------------
