Network Working Group S. Daniel Park (ed.)
Internet-Draft Samsung Electronics.
July 11, 2004 S. Madanapalli
Radhakrishnan S
OLN Rao
Samsung ISO
Tatuya Jinmei
Toshiba
Consideration M and O Flags of IPv6 Router Advertisement
<draft-daniel-ipv6-ra-mo-flags-00.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document clarifies the processing and behavior of the IPv6
Router Advertisement M and O flags and proposes a solution for
invoking the DHCPv6 based DHCPv6 administrator policy.
Table of Contents
1.0 Introduction...................................................
1.1 Terminology....................................................
2.0 Background.....................................................
3.0 Requirements...................................................
4.0 DHCPv6 Policy Variable.........................................
4.1 Dependency between M & O Flags Corresponding Policy Variable...
4.2 M-Policy.......................................................
4.3 O-Policy.......................................................
5.0 Possible Scenarios.............................................
6.0 Transition of M & O flags......................................
7.0 Conclusion.....................................................
8.0 Open Issues....................................................
9.0 Security Considerations........................................
10.0 IANA Considerations............................................
11.0 References.....................................................
11.1 Normative References...........................................
11.2 Informative References.........................................
12.0 Acknowledgements...............................................
13.0 Authors' Addresses.............................................
1.0 Introduction
To configure host with network information such as IP address, DNS
server address and other configuration information several
mechanisms are proposed in the IETF. Particularly IPv6 stateless
address autoconfiguration [RFC2462] and Stateful/Stateless DHCPv6
[RFC3315]/[RFC3736] are widely used for configuring the network
information.
This document clarifies the processing and behavior of the IPv6
Router Advertisement (RA) M and O flags and specifically describes
the expected behavior and condition when the flag values under go
transition from ON (set) to OFF (unset) and vice versa.
This document defines an internal (conceptual) variable for DHCPv6
policy. The value of this variable in conjunction with the
"ManagedFlag" and the "OtherConfigFlag" of ND protocol [RFC2461]
will be used for invoking the DHCPv6 for autoconfiguration.
1.1 Terminology
o Stateful DHCPv6: Host can use Dynamic Host Configuration
Protocol for address autoconfiguration as
well as other information. The use of this
protocol is described in [RFC3315]. In this
document, this term is used in conjunction
with "M" flag.
o Stateless DHCPv6: Host can use Dynamic Host Configuration
Protocol for other configuration information
excluding address. The use of this protocol
is described in [RFC3736]. In this document,
this term is used in conjunction with "O"
flag.
2.0 Background
Currently, IPv6 WG is trying to mature both [RFC2461] and
[RFC2462] for the Draft Standard but the detailed consideration of
the M and O flags of IPv6 RA remains beyond scope of the basic
documents as [2462bis]
[2461bis] says:
M 1-bit "Managed address configuration" flag. When
set, it indicates Dynamic Host Configuration
Protocol [RFC3315] is available for address
autoconfiguration in addition to any addresses
autoconfigured using stateless address
autoconfiguration. More details of this flag is
described in [RFC2462].
O 1-bit "Other stateful configuration" flag. When
set, it indicates a subset of DHCPv6 [RFC3736] is
available for autoconfiguration of other
(non-address) information. Examples of such
information are DNS-related information or
information on other servers within the network.
More details of this flag is described in
[RFC2462].
[2462bis] says:
The details of how a host may use the M flags, including any use
of the "on" and "off" transitions for this flag, to control the
use of the stateful protocol for address assignment will be
described in a separate document. Similarly, the details of how a
host may use the O flags, including any use of the "on" and "off"
transitions for this flag, to control the use of the stateful
protocol for getting other configuration information will be
described in a separate document.
Particularly, both "ManagedFlag" and "OtherConfigFlag" which were
implementation-internal variables were removed during [2462bis]
work based on the WG consensus with ambiguous operational
experiences, thus new variables (or similar approaches) is
required to treat M/O flags of IPv6 RA on the host.
3.0 Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
this document, are to be interpreted as described in [RFC2119]
4.0 DHCPv6 Policy Variable
This document introduces two internal (conceptual) variables for
the M-Policy and O-Policy, which correspond to the policy for the
"ManagedFlag" and the "OtherConfigFlag" of ND protocol [RFC2461]
will be used for controlling the DHCPv6 for autoconfiguration.
4.1 Dependency between M & O Flags Corresponding Policy Variable
Prior to introducing specific Policies, we note an important
dependency between these flags corresponding Policy Variable as
follows,
If we invoke Stateful DHCPv6 [RFC3315] for address
autoconfiguration, we basically SHOULD NOT invoke Stateless DHCPv6
[RFC3736] since [RFC3315] can provide other configuration
information as well, as described in [RFC2462].
4.2 M-Policy
This policy variable takes three values as described below,
Policy 1: The host SHOULD invoke Stateful DHCPv6 for address
autoconfiguration regardless of the content of receiving RAs or
the existence of RAs.
Policy 2: The host SHOULD invoke Stateful DHCPv6 for address
autoconfiguration (along with other configuration information)
if and only if it sees an RA changing the M bit from unset to set.
Policy 3: The host SHOULD NOT invoke Stateful DHCPv6 for address
autoconfiguration regardless of the content of receiving RAs or
the existence of RAs.
4.3 O-Policy
This policy variable takes three values as described below,
Policy 1: The host SHOULD invoke Stateless DHCPv6 for getting
other configuration information regardless of the content of
receiving RAs or the existence of RAs.
Policy 2: The host SHOULD invoke Stateless DHCPv6 for getting
other configuration information if and only if it sees an RA
changing the O bit from unset to set.
Policy 3: The host SHOULD NOT invoke Stateless DHCPv6 for
getting other configuration information regardless of the
content of receiving RAs or the existence of RAs.
5.0 Possible Scenarios
M/O flags indicate whether the Stateful/Stateless DHCPv6 protocol
services are available, but they should not be used as triggers to
invoke the Stateful/Stateless DHCPv6 autoconfiguration protocols.
However, these flags in conjunction with the policy configured may
trigger the Stateful/Stateless DHCPv6 Protocol for automatic
configuration of the IPv6 address and the other information.
The following sections describe different scenarios for policies
described in Section 4.0.
Case: M=OFF and O=OFF
Scenario 1: If M-Policy is 1
The host invokes Stateful DHCPv6 for address autoconfiguration and
does not invoke Stateless DHCPv6 regardless of O-Policy.
Scenario 2: If M-Policy is 2 or 3
If O-Policy is 1, the host invokes Stateless DHCPv6 for other
configuration information.
Case: M=OFF and O=ON
Scenario 3: If M-Policy is 1
The host does not invoke Stateless DHCPv6 regardless of O-Policy.
Scenario 4: If M-Policy is 2 or 3
If O-Policy is 1 or 2, the host invoke Stateless DHCPv6 for other
configuration information.
Case: M=ON and O=OFF
Scenario 5: If M-Policy is 1 or 2
The host invokes DHCPv6 and does not invoke Stateless DHCPv6
regardless of O-Policy.
Scenario 6: If M-Policy is 3
If O-Policy is 1, the host invokes Stateless DHCPv6.
Case: M=ON and O=ON
Scenario 7: If M-Policy is 1 or 2
The host invokes Stateful DHCPv6 and does not invoke Stateless
DHCPv6 regardless of O-Policy.
Scenario 8: If M-Policy is 3
If O-Policy is 1 or 2, the host invokes Stateless DHCPv6.
6.0 Transition of M & O flags
The transition of the M/O flags from OFF to ON just indicates
that the network provides configuration information through
DHCPv6. This SHOULD NOT be treated as a trigger to invoke
DHCPv6 unless the policy dictates.
The transition of the M/O flags from ON to OFF does not mean
anything.
As long as the host resides in a same single network and the
behavior of the host should not be changed with this transition.
The host is not expected to store the M and O flags in
non-volatile memory. The host should reset these flags depending
on the information received in RAs when the host is rebooting.
Also the host SHOULD reset these flags when it moves to a
different network. (See Issue(1) of Section 8.0.)
7.0 Conclusion
To clarify the meaning of M/O flags of IPv6 RA, this document
proposes a DHCPv6 Policy variable on the host that implements
Stateful/Stateless DHCPv6 service for invoking DHCPv6 in
conjunction with M/O flags of RA. This variable is controlled by
administrator under a certain level of requirement.
Generally, both Stateful/Stateless DHCPv6 and IPv6 stateless
address autoconfiguration may be used simultaneously. However if
we invoke Stateful DHCPv6 [RFC3315] for address autoconfiguration,
we SHOULD NOT invoke Stateless DHCPv6 [RFC3736] since [RFC3315]
can provide other configuration information, like Stateless DHCPv6
service as described in Section 4.1.
[RFC3736] is just a subset of full DHCPv6. So, a host
implementing [RFC3315] can do both or either Stateful DHCPv6 for
configuring the IPv6 address and Stateless DHCPv6 for the other
information. A host implementing only [RFC3736] can only do
Stateless DHCPv6.
Finally, this document eventually define the default value(s) of
the policy(s) as below,
If the node implementes [RFC3315], the default value of M-Policy
is 2. If the node does not implement [RFC3315], the default (and
only) policy value is 3. When assuming [RFC3637] will be
implemented much wider that [RFC3315] in terms of other
configuration information, the default value of O-Policy is either
1 or 2. Perhaps value 1 is better since this service might be
crucial for the node (i.e., there may be no alternative to get the
other configuration information.)
Now, above conclusion of the default value remains one of open
issues since this is surely a controversial issue. (See Issue(2)
of Section 8.0.)
8.0 Open Issues
(1) Issue that was never clarified in [RFC 2461]/[RFC2462] is
when does a node ever reset itself once the DHCPv6 flag goes ON.
Does it do this on a roboot ? Does it do this when it has moved
to a new network ? and how does it detect this ?
(2) Issue on the default value(s) of the policy(s) as described in
Section 7.0.
9.0 Security Considerations
The concepts in this document do not significantly alter the
security considerations for DHCPv6 and ND Protocol. However, use
of these policies with variables could expedite denial of service
attacks by allowing a mischievous host to trigger DHCP exchanges
from the abnormal M/O flags set. Authenticated DHCPv6 and [SEND]
(SEcure Neighbor Discovery) can be used to protect the malicious
attack.
We can consider another aspect of security beside using SEND.
Maybe at lease sending a (log) message to the colsole/user saying
that you are receiving a suspicious O flag set of RA when no
previous RA on the same link had the O flag set, or when when
receiving a suspicious configuration information (particularly DNS
server address) if you had one before as the result of a previous
O flag set and you are receiving a new one as a result of a new O
flag set.
The attack is very malicious as it may be very difficult to detect
if we do not implement neither SEND nor the avove suggestion of
the real router.
10.0 IANA Considerations
This document has no considerations for IANA.
11.0 References
11.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2462] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery
for IP version 6", December 1998.
[2461bis] T. Narten, E. Nordmark, W. Simpson, H. Soliman, T.
Jinmei, "Neighbor Discovery for IP version 6", Internet Draft,
February 2004.
[2462bis] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", Internet Draft, June 2004.
[RFC3315] R. Droms, et. al., Dynamic Host Configuration Protocol
for IPv6, RFC 3315, July 2003.
[RFC3736] R. Droms, "Stateless DHCP Service for IPv6", RFC 3736,
April 2004.
11.2 Informative References
[SEND] J. Arkko et al, "SEcure Neighbor Discovery", Internet-
Draft, April 2004.
12.0 Acknowledgements
The approach of this document was from the RFC2461/RFC2462, so
authors would appreciate authors of these RFC and editor of RFC
2461bis/RFC2462bis. Also many thanks are IPv6 Working Group
guys due to their valuable discussion on this thread in the
mailing list. Specially thanks to Bernie Volz of Cisco for his
lots of valuable work on this document.
Alain Durand of Sun Microsystems indicated an attack changing
the M/O flag to ON with a rogue Stateful/Stateless DHCPv6 server
and kindly introduced a log message as a useful method to detect
a suspicious operation.
13.0 Authors' Addresses
Soohong Daniel Park (Editor)
Email:soohong.park@samsung.com
Samsung Electronics,
Korea
Syam Madanapalli
Email:syam@Samsung.com
Samsung India Software Operations,
India
Radhakrishnan S.
Email:rkrishnan.s@samsung.com
Samsung India Software Operations,
India
O.L.N. Rao
Email: OLNRao@samsung.com
Samsung India Software Operation,
India
Tatuya Jinmei
Email:jinmei@isl.rnc.toshiba.co.jp
Toshiba Corporation,
Japan
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the IETF's procedures with respect to
rights in IETF Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.