Hello, James
> If the point is to somehow "save resources" by turning off DHCP when
> not wanted, isn't that really more of a client implementation issue
> than it is a protocol issue? The existing M/O bits only suggest when
> starting DHCP might be good. It's up to implementations to determine
> whether to start it, and if so when to quit.
Right. This is closer to my point.
However, by looking the below text, I am not clear that usage of M/O flags is
removed because it is not a protocol issue but an implementational one.
<from RFC4862>
Removed the text regarding the M and O flags, considering the
maturity of implementations and operational experiences.
ManagedFlag and OtherConfigFlag were removed accordingly. (Note
that this change does not mean the use of these flags is
deprecated.)
</RFC4862>
<from RFC4861>
M 1-bit "Managed address configuration" flag. When
set, it indicates that addresses are available via
Dynamic Host Configuration Protocol [DHCPv6].
If the M flag is set, the O flag is redundant and
can be ignored because DHCPv6 will return all
available configuration information.
O 1-bit "Other configuration" flag. When set, it
indicates that other configuration information is
available via DHCPv6. Examples of such information
are DNS-related information or information on other
servers within the network.
Note: If neither M nor O flags are set, this indicates that no
information is available via DHCPv6.
</RFC4861>
What I am wondering is what is the design rationale behind M and O bits. Why
should DHCPv6 clients be controlled/instructed/guided by RA messages?
I guess that there might be more than resource saving. DHCPv6 protocol provides
address(and prefixes) and additional configuration parameters like DNS servers,
etc. However, it does not provide default gateway and prefix length, which may
be givne by only RA. IMHO, this design decision shows that stateful address
configuration though DHCPv6 should be integrated with RA (an IPv6 core
protocol) and controlled/instructed/guided by RA messages as stateless address
autoconfiguration is.
As long as current architecture(or situation) is supported, I still believe
that our draft has value to provide a right guidance on the usage of M/O flags
to implementors.
Joseph
------- Original Message -------
Sender : James Carlson<[EMAIL PROTECTED]>
Date : 2008-10-08 21:06 (GMT+09:00)
Title : Re: Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"
HYUN WOOK CHA writes:
> As I presented last IETF 6MAN meeting, our draft aims to provide automatic
> revocation of DHCPv6 clients in case that invocation of clients can be done
> in accordance with the RFC2462. Thus, requirement of our security model is
> that we should not intoduce additional threats to the existing specification
> and implementations. Since per-interface state variables are managed through
> timer based algorithm proposed in the draft, illegal RA messages can not stop
> clients as long as legal RA messages advertise the availability of DHCPv6
> service. Also, we proposed two options when state variables are invalidated:
> 1) DHCPv6 client may refer state variables to decide whether it should keep
> its operation or not only after all bindings(leases) expires. 2) DHCPv6
> client may be stopped immediately at the transition of variables from 1 to 0.
> With the first option, client can keep its operation even if state variables
> will be changed to 0 since legal RA messages are absent within lifetimes by!
an
Why is all this new machinery necessary?
If the point is to force all of the DHCPv6 clients with existing
leases to give them up, then the existing Reconfigure message would do
the trick, and would avoid creating new security issues to analyze,
and avoid a new dependence on the weird M/O bits that many of us would
like to see deprecated.
If the point is to somehow "save resources" by turning off DHCP when
not wanted, isn't that really more of a client implementation issue
than it is a protocol issue? The existing M/O bits only suggest when
starting DHCP might be good. It's up to implementations to determine
whether to start it, and if so when to quit.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
