Brian - I think this thread reasonably supports the conclusion that
the text in the RFCs does not clearly capture the consensus reached of
the IETF. In my opinion, some sort of additional information is
needed because I've gotten questions on exactly this issue. I think
the problem can be resolved with a couple of sentences (as I wrote
earlier); e.g.:
* Add a new Note after the description of the M/O flags in Section 4.2
of RFC 4861:
Note: The DHCPv6 client behavior in response to the receipt of M and
O flags is unspecified.
* Add a sentence to the clarification in RFC 4862:
o 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.) *The DHCPv6 client
behavior in response to the receipt of M and O flags is
unspecified.*
* Change the following sentence from Section 3 of RFC 4861:
For example, routers can specify whether hosts should use DHCPv6 and/
or autonomous (stateless)
address configuration.
to:
For example, routers can specify whether DHCPv6 services are
available for address configuration and other
configuration information.
Now, it's not clear that simply clarifying the earlier consensus is
sufficient, because leaving the DHCPv6 client behavior in response to
the M/O flags unspecified may not provide enough information for
implementors. But, I think additional clarification to implementors
is a separate discussion...
- Ralph
On Oct 13, 2008, at Oct 13, 2008,9:26 AM, Brian Haberman wrote:
Bernie,
Bernie Volz (volz) wrote:
It would seem quite dangerous to enable/disable DHCPv6 clients
arbitrarily based on bit settings in un-protected RA messages.
This support already exists with the definition of the M & O bits.
Setting these in an RA means "run DHCPv6". As Joseph pointed out, the
I don't interpret the specification that way. If the M and/or O bit
are set in the RA, it is an indication that the service *exists*.
The spec does not indicate what the client does with that knowledge.
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.
draft defines a mechanism to stop DHCPv6 if *NO* RAs have the M&O
bits
set. If you have multiple RAs, some "valid" which say run DHCPv6 and
other RAs which are "rogue" that say don't run DHCPv6, the run ones
win.
So, given this, I can't see how this adds any security issues that
don't
already exist (ie, to cause DHCPv6 to be run). If DHCPv6 is not
requested by valid RAs, all rogue RAs can do is cause DHCPv6 to be
run.
If DHCPv6 is requested by valid RAs, rouge RAs can't stop DHCPv6.
- Bernie
-----Original Message-----
From: HYUN WOOK CHA [mailto:[EMAIL PROTECTED] Sent:
Tuesday, October 07, 2008 8:41 PM
To: Brian Haberman
Cc: Ted Lemon; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ipv6@ietf.org;
Bernie
Volz (volz)
Subject: Re: Re: Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt"
Hello, Brian.
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
any reasons.
It would seem quite dangerous to enable/disable DHCPv6 clients
arbitrarily based on bit settings in un-protected RA messages.
I agree with your point. We do not have any security methods and just
consider using the SEND. Regards, Joseph
------- Original Message -------
Sender : Brian Haberman<[EMAIL PROTECTED]> Date :
2008-10-08 04:20 (GMT+09:00)
Title : Re: Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt"
Joseph,
Do you have a particular security model in mind for giving
Router Advertisements the power to control software functionality
on each node?
It would seem quite dangerous to enable/disable DHCPv6 clients
arbitrarily based on bit settings in un-protected RA messages.
Regards,
Brian
HYUN WOOK CHA wrote:
Hello, Ted.
That's correct. I believe that the ability to stop DHCP clients
using
M/O bits in RA is required once they were invoked by M/O bits in RA.
Joseph
------- Original Message ------- Sender : Ted
Lemon<[EMAIL PROTECTED]> Date : 2008-09-30 09:36 (GMT+09:00)
Title : Re: Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt"
Joseph, to summarize, it sounds like you believe that the ability to
stop DHCP clients broadcasting on a link is a requirement. And you
therefore think that deprecating the M&O bits is not the right
answer. Is that correct?
-------------------------------------------------------------------- IETF
IPv6 working group mailing list ipv6@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
dhcwg mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/dhcwg
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
