> On Tue, 11 May 2004 09:40:45 +0200,
> Stig Venaas <[EMAIL PROTECTED]> said:
>> Yes, your original analysis is correct...
>>
>> 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
> On Mon, 10 May 2004 12:39:53 -0400,
> Ralph Droms <[EMAIL PROTECTED]> said:
> Yes, your original analysis is correct...
> 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 c
I wouldn't rule this out completely. I think normally RFC 3736 will be
the reasonable thing to do. But if client for some reason wants some
stateful info it could still try to use RFC 3315 I think.
The problem is that if a clients tries stateful DHCPv6 by sending an IA
option with the request whil
On Mon, May 10, 2004 at 12:39:53PM -0400, Ralph Droms wrote:
> Yes, your original analysis is correct...
>
> 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
10, 2004 10:19 AM
> To: Ralph Droms; JINMEI Tatuya /
> Cc: [EMAIL PROTECTED]
> Subject: RE: the protocol for the O flag
>
> Prefix delegation is a somewhat different animal than your average DHCP
> lookup. It only makes sense in routers, not hosts. In fa
> Subject: Re: the protocol for the O flag
>
> Yes, your original analysis is correct...
>
> 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 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 R
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 d
