--- 1/draft-ietf-ipv6-ra-mo-flags-00.txt 2006-02-05 00:03:11.000000000 +0100 +++ 2/draft-ietf-ipv6-ra-mo-flags-01.txt 2006-02-05 00:03:11.000000000 +0100 @@ -1,134 +1,147 @@ + Network Working Group S. Park, Ed. -Internet-Draft Samsung Electronics -Expires: May 15, 2005 S. Madanapalli +Internet-Draft SAMSUNG Electronics +Expires: September 24, 2005 S. Madanapalli Samsung ISO T. Jinmei Toshiba - November 16, 2004 + March 26, 2005 Considerations on M and O Flags of IPv6 Router Advertisement - draft-ietf-ipv6-ra-mo-flags-00.txt + draft-ietf-ipv6-ra-mo-flags-01.txt Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with + 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 May 15, 2005. + This Internet-Draft will expire on September 24, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document clarifies the processing and behaviour of a host for the M and O flags of IPv6 Router Advertisement and proposes a solution for invoking the DHCPv6 service based on administrator policy in conjunction with new host variables for the M and O flags. +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. IPv6 Host Variables . . . . . . . . . . . . . . . . . . . . . 4 + 6. DHCPv6 Policy Variables . . . . . . . . . . . . . . . . . . . 5 + 6.1 Dependency Between the Configuraton Behaviours . . . . . . 5 + 6.2 M-Policy . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 6.3 O-Policy . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Host Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8. Other Issues on State Transition of M-Flag and O-Flag . . . . 8 + 9. Router Advertisement Unavailability . . . . . . . . . . . . . 8 + 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 11. An Open Issue: Default Policy Values . . . . . . . . . . . . 9 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 9 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 + 15. Appendix A: Handling of M and O flags from multiple + routers . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 16.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 + 16.2 Informative References . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . 13 + 1. Introduction To configure a host with network information such as an IP address, DNS server addresses and other configuration information, several mechanisms are proposed in the IETF. In particular, IPv6 stateless address autoconfiguration [RFC2462] and Dynamic Host Configuration Protocol [RFC3315][RFC3736] will be widely used for configuring the network information. This document proposes two conceptual variables, called DHCPv6 Policy variables corresponding to the M and O flags of Router Advertisement. The values of these policy variables in conjuction with the values of the flags of Router Advertisement decide the host behaviour to invoke DHCPv6 services. These policy variables are controlled by the administrator under a certain level of requirement. 2. Background This section explains why this document appears in the IETF. - Currently, IPv6 WG is trying to make both [RFC2461] and [RFC2462] - mature for the Draft Standard but the detailed consideration of the M - and O flags of IPv6 Router Advertisement remains beyond scope of the - basic documents as described in [I-D.ietf-ipv6-rfc2462bis]. + So far, IPv6 WG has being tried to make both [RFC2461] and [RFC2462] + mature for the Draft Standard. While updating, the text regarding + the M and O flags were removed from [I-D.ietf-ipv6-rfc2462bis] + considering the maturity of implementations and operational + experiences. [I-D.ietf-ipv6-2461bis] says: o M : 1-bit "Managed address configuration" flag. When set, it indicates that Dynamic Host Configuration Protocol [DHCPv6] is available for address configuration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is further described in [ADDRCONF]. o O : - 1-bit "Other stateful configuration" flag. When set, it indicates - that [DHCPv6-lite] 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. The use of this flag for add is further described in - [ADDRCONF]. - - [Note: "for add" in the last sentence is probably a misspelling.] - - [I-D.ietf-ipv6-rfc2462bis] says: - - o The details of how a host may use the M flag, 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 flag, 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. + 1-bit "Other configuration" flag. When set, it indicates that + [DHCPv6lite] 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. In particular, both "ManagedFlag" and "OtherConfigFlag" which were - implementation-internal variables were removed during the + implementation-internal variables were also removed during the [I-D.ietf-ipv6-rfc2462bis] work based on the WG consensus with ambiguous operational experiences, and thus new variables (or similar approaches) are required to treat the M and O flags of IPv6 Router Advertisement on the host. 3. Terminology o Host Configuration Behaviour : A host can use DHCPv6 for address autoconfiguration as well as - other configuration information via - Solicit/Advertise/Request/Reply message exchanges or Solicit/Reply - message exchanges (if rapid commit is enabled) as described in - [RFC3315]. In this document, this term is used for host - configuration including address and other configuration - information in conjunction with the M flag. + other configuration information via Solicit/Advertise/Request/ + Reply message exchanges or Solicit/Reply message exchanges (if + rapid commit is enabled) as described in [RFC3315]. In this + document, this term is used for host configuration including + address and other configuration information in conjunction with + the M flag. o Information Configuration Behaviour : A host can use DHCPv6 to obtain configuration information parameters excluding addresses. For this operation, Information-request and Reply messages are used, also as described in [RFC3315]. In this document, this term is used for other configuration information excluding addresses in conjunction with the O flag. @@ -398,25 +411,26 @@ 14. Acknowledgements The approach of this document was from the RFC2461/RFC2462, so the authors would appreciate the authors of these RFCs and the editors of RFC2461bis/RFC2462bis. Also, many thanks go to IPv6 Working Group members for their valuable discussion on this thread in the mailing list. Especially to: Greg Daley, Pekka Savola, Ralph Droms, and Stig Venaas. Thanks to Bernie Volz of Cisco for his lots of valuable work on this document. Special thanks to Radakrishnan and OLN Rao of Samsung India Software Operations for their inputs from - implementation perspective. + implementation perspective. Thanks to Noh-Byung Park and Youngkeun + Kim for their supports on this work. - Alain Durand of Sun Microsystems indicated an attack changing the M - and O flags with a rogue DHCPv6 server and kindly introduced a log - message as an effective method to detect a suspicious operation. + Alain Durand indicated an attack changing the M and O flags with a + rogue DHCPv6 server and kindly introduced a log message as an + effective method to detect a suspicious operation. 15. Appendix A: Handling of M and O flags from multiple routers This document does not take a hard stance on what happens when a host has multiple routers and inconsistent information (different M and O flags configuration) is learned from different routers. The basic documents [RFC2461]/[RFC2462] already described "Configuration Consistency" and a host will simply handle inconsistent M and O flags of Router Advertisement in the same manner. @@ -433,40 +447,40 @@ consistency among Router Advertisement parameters from multiple routers in the same single link as described in Section 5.6 of [RFC2462]. The authors thus remain "Handling of M and O flags from multiple routers" out of scope of this document. 16. References 16.1 Normative References [I-D.ietf-ipv6-2461bis] - "Neighbor Discovery for IP version 6 (IPv6)", - draft-ietf-ipv6-2461bis-00 (work in progress), July 2004. + Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", + draft-ietf-ipv6-2461bis-02 (work in progress), February + 2005. [I-D.ietf-ipv6-rfc2462bis] Thomson, S., "IPv6 Stateless Address Autoconfiguration", - draft-ietf-ipv6-rfc2462bis-06 (work in progress), - September 2004. + draft-ietf-ipv6-rfc2462bis-07 (work in progress), December + 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and - M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. 16.2 Informative References [I-D.ietf-ipv6-node-requirements] Loughney, J., "IPv6 Node Requirements", @@ -474,28 +488,27 @@ August 2004. [I-D.ietf-send-ndopt] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 (work in progress), July 2004. Authors' Addresses Soohong Daniel Park, Ed. - Samsung Electronics - 416 Maetan-3dong, Yeongtong-gu - Suwon-si, Gyeonggi-do 442-742 + Mobile Platform Laboratory, SAMSNUG Electronics + 416 Maetan-3dong, Yeongtong-Gu + Suwon, Gyeonggi-Do 443-742 KOREA Phone: +82 31 200 4508 EMail: soohong.park@samsung.com - Syam Madanapalli Samsung India Software Operation J.P. Techno Park, 3/1 Millers Road, Bangalore 560-052 INDIA Phone: +91 80 51197777 EMail: syam@samsung.com Tatuya Jinmei @@ -536,18 +549,18 @@ 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 + Copyright (C) The Internet Society (2005). 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.