[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-daniel-ipv6-ra-mo-flags) 00 01

Network Working Group                                       S. Park, Ed.
Internet-Draft                                       SAMSUNG Electronics
Expires: September 24, 2005                               S. Madanapalli
                                                             Samsung ISO
                                                               T. Jinmei
                                                                 Toshiba
                                                          March 26, 2005


      Considerations on M and O Flags of IPv6 Router Advertisement
                   draft-ietf-ipv6-ra-mo-flags-01.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 September 24, 2005.

Copyright Notice

   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.





Park, Ed., et al.      Expires September 24, 2005               [Page 1]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


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

























Park, Ed., et al.      Expires September 24, 2005               [Page 2]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


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.

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



Park, Ed., et al.      Expires September 24, 2005               [Page 3]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


   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.

   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.

      [RFC3736] gives guidelines for implementing the parts of [RFC3315]
      required for the configuration information, for clients, servers
      and relay agents, although [RFC3736] has no additional impact on
      relay agents.  Also, [RFC3736] does not describe procedures or a
      distinct protocol.  It is intended to describe that part of the
      protocol that a server or a client must implement if all it
      intends to support is the configuration information.

4.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

5.  IPv6 Host Variables

   This document newly introduces two host variables to indicate whether
   or not configuration information (including addresses) can be
   configured using DHCPv6.  The implicit concept of these variables
   defined in this document is the same as that of "ManagedFlag" and
   "OtherConfigFlag", which were described in [RFC2462] and then removed
   from [I-D.ietf-ipv6-rfc2462bis].  We deliberately use different
   variable names in this document to avoid confusion with the removed
   names.



Park, Ed., et al.      Expires September 24, 2005               [Page 4]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


   A host maintains the following variables on a per-interface basis:

   o  M-Flag :

      Copied from the M flag field of the most recently received Router
      Advertisement message.  This variable indicates whether or not
      address can be configured using Host Configuration Behaviour.  It
      starts out in a FALSE state.  On receipt of a valid Router
      Advertisement, a host copies the value of the advertisement's M
      flag into M-Flag.

      Default: FALSE

   o  O-Flag :

      Copied from the O flag field of the most recently received Router
      Advertisement message.  This variable indicates whether or not
      configuration information (excluding addresses) can be obtained
      using Information Configuration Behaviour.  It starts out in a
      FALSE state.  On receipt of a valid Router Advertisement, a host
      copies the value of the advertisement's O flag into O-Flag.

      Default: FALSE

6.  DHCPv6 Policy Variables

   This document introduces two administrator policy variables regarding
   DHCPv6, M-Policy and O-Policy, corresponding to Host Configuration
   Behaviour and Information Configuration Behaviour.  These policy
   variables will be used by the administrator for controlling the
   invocation of DHCPv6.

6.1  Dependency Between the Configuraton Behaviours

   Prior to introducing specific policies, we note an important
   dependency between the two Configuraton Behaviours.  If we invoke
   Host Configuration Behaviour for address autoconfiguration (along
   with other configuration information), we basically should not invoke
   Information Configuration Behaviour since the former can provide
   other configuration information as well.

   For simplicity, however, we will describe the policies and the
   corresponding variables for the M and O flags separately.  Host's
   behaviour, with taking into account of the dependency, will be
   described in Section 7.






Park, Ed., et al.      Expires September 24, 2005               [Page 5]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


6.2  M-Policy

   This policy variable takes three values as described below.

   o  Policy 1 :

      The host should invoke Host Configuration Behaviour for address
      autoconfiguration (along with other configuration information)
      regardless of the content of received Router Advertisement
      messages or the existence of Router Advertisement messages.

   o  Policy 2 :

      The host should invoke Host Configuration Behaviour for address
      autoconfiguration (along with other configuration information) if
      and only if it sees a Router Advertisement changing the M-Flag
      from FALSE to TRUE.

   o  Policy 3 :

      The host should not invoke Host Configuration Behaviour for
      address autoconfiguration (along with other configuration
      information) regardless of the content of received Router
      Advertisement messages or the existence of Router Advertisement
      messages.

6.3  O-Policy

   This policy variable takes three values as described below.

   o  Policy 1 :

      The host should invoke Information Configuration Behaviour for
      getting other configuration information regardless of the content
      of received Router Advertisement messages or the existence of
      Router Advertisement messages.

   o  Policy 2 :

      The host should invoke Information Configuration Behaviour for
      getting other configuration information if and only if it sees a
      Router Advertisement changing the O-Flag from FALSE to TRUE.

   o  Policy 3 :

      The host should not invoke Information Configuration Behaviour for
      getting other configuration information regardless of the content
      of received Router Advertisement messages or the existence of



Park, Ed., et al.      Expires September 24, 2005               [Page 6]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


      Router Advertisement messages.

7.  Host Behaviour

   The M and O flags indicate whether Host Configuration/Information
   Configuration Behaviours are available, but typically they themselves
   should not be used as triggers to invoke DHCPv6 services.  However,
   these flags in conjunction with the policy configured may trigger
   DHCPv6 services for automatic configuration of the IPv6 address and
   the other information.

   The followings are specific host's behaviour based on the policy
   variables and the change of the host state variables.

   If M-Policy is 1, the host SHOULD invoke Host Configuration Behaviour
   for address and other configuration information, regardless of the
   change of the state variables.  The host SHOULD NOT invoke
   Information Configuration Behaviour regardless of O-Policy.  Note,
   however, that if the available DHCPv6 servers only provide the
   service for the Information Configuration Behaviour, the host will
   even not be able to configure other configuration parameters than
   addresses.  Thus, it is generally inadvisable to set M-Policy to 1,
   unless there is a particular reason to do so.

   If M-Policy is 2, the host SHOULD first wait for initial Router
   Advertisements.  If those advertisements make M-Flag change from
   FALSE to TRUE, the host SHOULD invoke Host Configuration Behaviour.
   In this case, the host SHOULD NOT invoke Information Configuration
   Behaviour regardless of O-Policy.  Otherwise, if O-Policy is 1 or the
   initial advertisements make O-Flag change from FALSE to TRUE with
   O-Policy being 2, the host SHOULD invoke Information Configuration
   Behaviour.  Even after initial advertisements, the host SHOULD invoke
   Host Configuration Behaviour whenever M-Flag changes from FALSE to
   TRUE, unless it has already started the behaviour.  If the host has
   invoked Information Configuration Behaviour by the time it invokes
   Host Configuration Behaviour, the host SHOULD NOT stop the running
   Information Configuration Behaviour.

   If M-Policy is 3, the host SHOULD NOT invoke Host Configuration
   Behaviour, regardless of the change of the state variables.  In this
   case, if O-Policy is 1, the host SHOULD immediately invoke
   Information Configuration Behaviour.  Otherwise, when O-Flag changes
   from FALSE to TRUE with O-Policy being 2, the host SHOULD invoke
   Information Configuration Behaviour, unless it has already started
   the behaviour.






Park, Ed., et al.      Expires September 24, 2005               [Page 7]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


8.  Other Issues on State Transition of M-Flag and O-Flag

   As long as a host resides in the same single network, the behaviour
   of the host SHOULD NOT be changed with the change of M-Flag or O-Flag
   from TRUE to FALSE.  The host is not expected to store M-Flag and
   O-Flag state in non-volatile memory.  When a host is rebooting (the
   state of variables starts with FALSE), the host SHOULD update these
   variables depending on the information received in Router
   Advertisement messages.  Also, the host SHOULD update these variables
   depending on the information received in Router Advertisement
   messages, when it moves to a different network and receives a new
   Router Advertisement including different prefix information.

9.  Router Advertisement Unavailability

   It is possible that the host does not see any Router Advertisements.
   Originally, [RFC2462] requested that the host in this case must
   invoke the stateful configuration protocol (i.e., [RFC3315] in
   today's interpretation).  In addition,
   [I-D.ietf-ipv6-node-requirements] says that in the absence of a
   router, the IPv6 nodes that use DHCP for address assignment MUST
   initiate DHCP to obtain IPv6 addresses and other configuration
   information.

   Based on these prior documents, this document introduces the
   following rule: if no Router Advertisement appears, a host SHOULD
   initiate Host Configuration Behaviour using [RFC3315] to get both
   address and configuration information as if the node receives a
   Router Advertisement with the M flag being ON and the O flag being
   OFF.  This rule is almost as the same as what the prior documents
   specified, except that the host can still choose not to initiate Host
   Configuration Behaviour if its M-policy is 3.

10.  Conclusion

   To clarify the meaning of the M and O flags of IPv6 Router
   Advertisement, this document has proposed DHCPv6 Policy variables on
   the host in conjunction with host state variables corresponding to
   the M and O flags of Router Advertisement for invoking the DHCPv6
   Services.  The Policy variables are controlled by the administrator
   under a certain level of requirement.

   Generally, both Host Configuration/Information Configuration
   Behaviours and IPv6 stateless address autoconfiguration may be used
   simultaneously.  On the other hand, if we invoke Host Configuration
   Behaviour for address autoconfiguration, we should basically not
   invoke Information Configuration Behaviour since the former service
   can provide other configuration information also.



Park, Ed., et al.      Expires September 24, 2005               [Page 8]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


   [RFC3736] is just a subset of the full DHCPv6 service.  Thus, a host
   implementing [RFC3315] can do both or either Host Configuration
   Behaviour for configuring the IPv6 address and Information
   Configuration Behaviour for the other information.  A host
   implementing only [RFC3736] can only do Information Configuration
   Behaviour.

11.  An Open Issue: Default Policy Values

   Once we agree on the basic concept described in this document, we
   will then have to decide the appropriate default values of the policy
   variables.

   The followings are some initial considerations on the default values
   at the moment.  If the node implements Host Configuration Behaviour
   using [RFC3315], the default value of M-Policy should be 2.  If the
   node does not implement Host Configuration Behaviour using [RFC3315],
   the default (and only) value of M-policy should be 3.  Assuming
   Information Configuration Behaviour only using [RFC3736] will be
   implemented much wider than the full set of [RFC3315] in terms of
   other configuration information, the default value of O-Policy should
   be either 1 or 2.  Value 1 is presumably better since this service
   can be crucial for the node (i.e., there may be no alternative to get
   the other configuration information.)

12.  Security Considerations

   The concepts in this document do not significantly alter the security
   considerations for DHCPv6 and Neighbor Discovery Protocol.  However,
   the use of the proposed policies with variables could expedite denial
   of service attacks by allowing a mischievous host to trigger invalid
   DHCP exchanges with the M or O flag being ON in a malicious Router
   Advertisement and with illegitimate DHCPv6 servers.  Authenticated
   DHCPv6 and/or [I-D.ietf-send-ndopt] (SEcure Neighbor Discovery, SEND)
   can be used to protect the attack.

   Even though the threat is only effective from an on-link attacker, it
   can be significant without a strong security mechanism like SEND,
   since the attack takes place in the process of autoconfiguration, and
   it may be difficult for the user to detect the attack.  Thus, it is
   generally advisable to log the change of M-Flag or O-Flag from FALSE
   to TRUE.  In addition, it might be useful to log an event that
   information provided through DHCPv6 is different form the information
   of the same type that the host previously received through DHCPv6.

13.  IANA Considerations

   This document has no consideration for IANA.



Park, Ed., et al.      Expires September 24, 2005               [Page 9]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


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.  Thanks to Noh-Byung Park and Youngkeun
   Kim for their supports on this work.

   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.

   If the host frequently receives inconsistent M and O flags of Router
   Advertisement (e.g., in a mobile environment for supporting fast
   movement detection), it may need complex consideration on an
   erroneous case.  However, this case is not closely related to this
   document; rather, it is a general issue on the inconsistent Router
   Advertisement parameters from multiple routers.  In fact, other
   configuration parameters such as the MTU size and the hop limit are
   also possible to be inconsistent in different Router Advertisements.

   In the end, it is administrator's responsibility to ensure the
   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]
              Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
              draft-ietf-ipv6-2461bis-02 (work in progress), February



Park, Ed., et al.      Expires September 24, 2005              [Page 10]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


              2005.

   [I-D.ietf-ipv6-rfc2462bis]
              Thomson, S., "IPv6 Stateless Address Autoconfiguration",
              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",
              draft-ietf-ipv6-node-requirements-11 (work in progress),
              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.
   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




Park, Ed., et al.      Expires September 24, 2005              [Page 11]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


   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
   Toshiba Corporation
   1 Komukai Toshiba-cho, Saiwai-ku
   Kawasaki-shi, Kanagawa  212-8582
   JAPAN

   Phone: +81 44 549 2230
   EMail: jinmei@isl.rdc.toshiba.co.jp

































Park, Ed., et al.      Expires September 24, 2005              [Page 12]


Internet-Draft          M and O Flags of IPv6 RA              March 2005


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 procedures with respect to rights in RFC 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 (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.




Park, Ed., et al.      Expires September 24, 2005              [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/