Internet Engineering Task Force H. Cha, Ed.
Internet-Draft SAMSUNG Electronics, Inc.
Intended status: Standards Track B. Volz
Expires: December 10, 2008 Cisco Systems, Inc.
June 8, 2008
Clarifying Handling of M & O Flags of IPv6 Router Advertisement
draft-cha-ipv6-ra-mo-00
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 10, 2008.
Abstract
This document clarifies how clients are supposed to use the RA M & O
flags.
Cha & Volz Expires December 10, 2008 [Page 1]
Internet-Draft Handling of M & O Flags of IPv6 RA June 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. An Algorithm for the Management of Internal State Variables . . 4
5. The Revocation of DHCPv6 clients . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Cha & Volz Expires December 10, 2008 [Page 2]
Internet-Draft Handling of M & O Flags of IPv6 RA June 2008
1. Introduction
According to [RFC4861], the M flag indicates that addresses are
available via DHCPv6 and the O flag indicates that other
configuration information is available via DHCPv6. However, since
RFC 2462 which is deprecated by RFC4861 already specified how IPv6
host should handle flags values in the received RA messages, current
IPv6 stack and DHCPv6 client implementations have been developed
according to the specification. In [RFC 2462] 5.5.3, it is required
that a host should invoke the DHCPv6 client to request both address
and other information when received Router Advertisement message
change an internal state variable (ManagedFlag) from FALSE to TRUE
and the DHCPv6 client is not running. In addition, if the value of
the ManagedFlag changes from TRUE to FALSE, the host should continue
running the DHCPv6 client, i.e., the change in the value of the
ManagedFlag has no effect. However, the existing documents have the
operational problems described below.
Firstly, there is no method to revoke the operation of a DHCPv6
client invoked by IPv6 RA flags. When a network administrator
changes the addressing policy for the network, i.e to shutdown DHCPv6
servers or change stateful DHCPv6 servers into stateless, he/she can
not revoke operation of DHCPv6 clients by changing the configuration
of RA flags. The reason for this problem is that DHCPv6 clients
would keep searching for a server from which to to obtain stateful
address and other configuration information after all existing
bindings will expire.
Secondly, per-interface state variables regarding availability of the
DHCPv6 service cannot be maintained consistently in case that
inconsistent M & O flags are contained in RAs sent by different
routers. The reason of this problem is that these state variables
are copied from the M & O flag fields of the most recently received
Router Advertisement message respectively.
To address these problems, this document describes a handling scheme
of M & O flags in RA messages. which consists of an algorithm for the
management of internal state variables and options regarding how
these variables can be utilized to revoke DHCPv6 clients.
2. Requirements Language
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 RFC 2119 [RFC2119].
Cha & Volz Expires December 10, 2008 [Page 3]
Internet-Draft Handling of M & O Flags of IPv6 RA June 2008
3. Terminology
RA Router Advertisement. More information can be found in
[RFC4861].
M flag 1-bit "Managed address configuration" flag in RA message.
More information can be found in [RFC4861 ] section 4.2.
O flag 1-bit "Other configuration" flag in RA message. More
information can be found in [RFC4861] section 4.2.
ManagedFlag an internal state variable maintained on a per-interface
basis according to algorithms presented in section 4.
Possible values are TRUE and FALSE. The transition from
FALSE to TRUE have a stateful DHCPv6 client invoked and
reverse transition SHOULD have the DHCPv6 client revoked as
specified in section 5.
OtherConfigFlag an internal state variable maintained on a per-
interface basis according to algorithms presented in section
4. Possible values are TRUE and FALSE. The transition from
FALSE to TRUE have a stateless DHCPv6 client invoked and
reverse transition SHOULD have the DHCPv6 client revoked as
specified in section 5.
DHCPv6 related terminologies DHCPv6, client, server, binding, etc
can be found in [RFC3315] section 4.2
4. An Algorithm for the Management of Internal State Variables
We introduce an algorithm for the management of the internal state
variables as follows. In this algorithm, two timers (M-timer and
O-timer) are used, lifetimes of which is chosen to be 3 times of
MaxRtrAdvInterval in [RFC4861]. When an RA is received that has the
M flag set, ManagedFlag is set to TRUE and the M-timer is started or
restarted. When an RA is received that has the O flag set, the
OtherConfigFlag is set to TRUE and O-timer is strarted or restarted.
If the M-timer goes off, the ManagedFlag is set to FALSE. If the
O-timer goes off, OtherConfigFlag is set to FALSE. Thus, once
ManagedFlag or OtherConfigFlag is set to TRUE, it can only be changed
into FALSE after no RA is received with the bit set within lifetime
of timers. Thus, state variables can be managed consistently even
when a host is connected to multiple routers sending conflicting RA
messages, because the RA messages with the bit set will overrule the
ones with the bit clear.
As an optional feature in the above algorithm, M & O flags in
Cha & Volz Expires December 10, 2008 [Page 4]
Internet-Draft Handling of M & O Flags of IPv6 RA June 2008
received RA with source address may be kept track of. Through this
feature, following benefits can be optained:
i. Faster Transition of State Variables
ManagedFlag or OtherConfigFlag can be set to FALSE as soon as
number of valid RA with the corresponding flag set is reduced
to zero.
ii. Router Information
The ability for hosts to identify routers which invoke and
continue the operations of DHCPv6 clients may be helpful to
fix mis-configuration of routers or detect malicious routers.
5. The Revocation of DHCPv6 clients
In this section, we introduce several suggestions regarding how state
variables can be utilized to control the operation of a DHCPv6
client. As RFC 2462 5.5.3 specifies, a DHCPv6 client is invoked when
a state variable is changed from FALSE to TRUE and the DHCPv6 client
is not already running. As for the transition (negative transition)
of state variables from TRUE to FALSE , there are many possible
implementational choices which can be classified into two types.
O1 To let a DHCPv6 client determine whether the client should keep
its operation or not depending on state variables.
For example, whenever the DHCPv6 client sends a Solicit or
Inforamtion-Request, it may check whether to continue doing
DHCPv6 based on the ManagedFlag or OtherConfigFlag. In this
option, the existing bindings will go through their normal
lifecycle regardless of negative transition of the ManagedFlag
and the client exit after all of the leases have expired. Thus,
a potential benefit from this choice is for existing transport
layer sessions to be preserved even while routers send RA
messages with flags mistakenly cleared.
O2 To let a negative transition revoke operation of DHCPv6 clients
immediately.
The negative transition of the ManagedFlag makes a DHCPv6 client
stop its stateful operation, thereby all bindings are released.
A negative transition of the OtherConfigFlag make a DHCPv6 client
stop its stateless operation.
Cha & Volz Expires December 10, 2008 [Page 5]
Internet-Draft Handling of M & O Flags of IPv6 RA June 2008
6. IANA Considerations
This document includes no request to IANA.
7. Security Considerations
As [RA-MO], Handling schemes in M & O flags from RAs in this document
could expedite denial of service attacks by allowing a host to
trigger invalid DHCP exchanges with the M or O flag set in a
malicious Router Advertisement and with illegitimate DHCPv6 servers.
Authenticated DHCPv6 and/or [RFC3971] (SEcure Neighbor Discovery) can
be used to protect the attack. This document introduces no
additional security risks.
8. References
8.1. Normative References
[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.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RA-MO] Park, S., Madanapalli, S., and T. Jinmei, "Considerations
on M and O Flags of IPv6 Router Advertisement",
draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress)",
March 2005.
Cha & Volz Expires December 10, 2008 [Page 6]
Internet-Draft Handling of M & O Flags of IPv6 RA June 2008
8.2. Informative References
[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.
Authors' Addresses
Hyunwook Joseph Cha (editor)
SAMSUNG Electronics, Inc.
416, Maetan-3dong, Yeongtong-Gu
Suwon, Korea
Phone: +82-31-279-3804
Email: hyunwook.cha@samsung.com
Bernie Volz
Cisco Systems, Inc
1414 Massachusetts Ave.
Boxborough, MA 01719,
USA
Phone: +1-978-936-0382
Email: volz@cisco.com
Cha & Volz Expires December 10, 2008 [Page 7]
Internet-Draft Handling of M & O Flags of IPv6 RA June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Cha & Volz Expires December 10, 2008 [Page 8]