[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-ipv6-ra-mo-flags

  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.

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