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 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.