idnits 2.17.00 (12 Aug 2021) /tmp/idnits45235/draft-cha-ipv6-ra-mo-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 302. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 113 has weird spacing: '...gedFlag an in...' == Line 120 has weird spacing: '...figFlag an in...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 8, 2008) is 5088 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2462' is mentioned on line 64, but not defined ** Obsolete undefined reference: RFC 2462 (Obsoleted by RFC 4862) == Unused Reference: 'RFC2461' is defined on line 214, but no explicit reference was found in the text == Unused Reference: 'RFC2462' is defined on line 218, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 228, but no explicit reference was found in the text == Unused Reference: 'RFC3736' is defined on line 242, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Possible downref: Normative reference to a draft: ref. 'RA-MO' -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Cha, Ed. 3 Internet-Draft SAMSUNG Electronics, Inc. 4 Intended status: Standards Track B. Volz 5 Expires: December 10, 2008 Cisco Systems, Inc. 6 June 8, 2008 8 Clarifying Handling of M & O Flags of IPv6 Router Advertisement 9 draft-cha-ipv6-ra-mo-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 10, 2008. 36 Abstract 38 This document clarifies how clients are supposed to use the RA M & O 39 flags. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 45 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 4. An Algorithm for the Management of Internal State Variables . . 4 47 5. The Revocation of DHCPv6 clients . . . . . . . . . . . . . . . 5 48 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 49 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 50 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 52 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 54 Intellectual Property and Copyright Statements . . . . . . . . . . 8 56 1. Introduction 58 According to [RFC4861], the M flag indicates that addresses are 59 available via DHCPv6 and the O flag indicates that other 60 configuration information is available via DHCPv6. However, since 61 RFC 2462 which is deprecated by RFC4861 already specified how IPv6 62 host should handle flags values in the received RA messages, current 63 IPv6 stack and DHCPv6 client implementations have been developed 64 according to the specification. In [RFC 2462] 5.5.3, it is required 65 that a host should invoke the DHCPv6 client to request both address 66 and other information when received Router Advertisement message 67 change an internal state variable (ManagedFlag) from FALSE to TRUE 68 and the DHCPv6 client is not running. In addition, if the value of 69 the ManagedFlag changes from TRUE to FALSE, the host should continue 70 running the DHCPv6 client, i.e., the change in the value of the 71 ManagedFlag has no effect. However, the existing documents have the 72 operational problems described below. 74 Firstly, there is no method to revoke the operation of a DHCPv6 75 client invoked by IPv6 RA flags. When a network administrator 76 changes the addressing policy for the network, i.e to shutdown DHCPv6 77 servers or change stateful DHCPv6 servers into stateless, he/she can 78 not revoke operation of DHCPv6 clients by changing the configuration 79 of RA flags. The reason for this problem is that DHCPv6 clients 80 would keep searching for a server from which to to obtain stateful 81 address and other configuration information after all existing 82 bindings will expire. 84 Secondly, per-interface state variables regarding availability of the 85 DHCPv6 service cannot be maintained consistently in case that 86 inconsistent M & O flags are contained in RAs sent by different 87 routers. The reason of this problem is that these state variables 88 are copied from the M & O flag fields of the most recently received 89 Router Advertisement message respectively. 91 To address these problems, this document describes a handling scheme 92 of M & O flags in RA messages. which consists of an algorithm for the 93 management of internal state variables and options regarding how 94 these variables can be utilized to revoke DHCPv6 clients. 96 2. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 3. Terminology 104 RA Router Advertisement. More information can be found in 105 [RFC4861]. 107 M flag 1-bit "Managed address configuration" flag in RA message. 108 More information can be found in [RFC4861 ] section 4.2. 110 O flag 1-bit "Other configuration" flag in RA message. More 111 information can be found in [RFC4861] section 4.2. 113 ManagedFlag an internal state variable maintained on a per-interface 114 basis according to algorithms presented in section 4. 115 Possible values are TRUE and FALSE. The transition from 116 FALSE to TRUE have a stateful DHCPv6 client invoked and 117 reverse transition SHOULD have the DHCPv6 client revoked as 118 specified in section 5. 120 OtherConfigFlag an internal state variable maintained on a per- 121 interface basis according to algorithms presented in section 122 4. Possible values are TRUE and FALSE. The transition from 123 FALSE to TRUE have a stateless DHCPv6 client invoked and 124 reverse transition SHOULD have the DHCPv6 client revoked as 125 specified in section 5. 127 DHCPv6 related terminologies DHCPv6, client, server, binding, etc 128 can be found in [RFC3315] section 4.2 130 4. An Algorithm for the Management of Internal State Variables 132 We introduce an algorithm for the management of the internal state 133 variables as follows. In this algorithm, two timers (M-timer and 134 O-timer) are used, lifetimes of which is chosen to be 3 times of 135 MaxRtrAdvInterval in [RFC4861]. When an RA is received that has the 136 M flag set, ManagedFlag is set to TRUE and the M-timer is started or 137 restarted. When an RA is received that has the O flag set, the 138 OtherConfigFlag is set to TRUE and O-timer is strarted or restarted. 139 If the M-timer goes off, the ManagedFlag is set to FALSE. If the 140 O-timer goes off, OtherConfigFlag is set to FALSE. Thus, once 141 ManagedFlag or OtherConfigFlag is set to TRUE, it can only be changed 142 into FALSE after no RA is received with the bit set within lifetime 143 of timers. Thus, state variables can be managed consistently even 144 when a host is connected to multiple routers sending conflicting RA 145 messages, because the RA messages with the bit set will overrule the 146 ones with the bit clear. 148 As an optional feature in the above algorithm, M & O flags in 149 received RA with source address may be kept track of. Through this 150 feature, following benefits can be optained: 152 i. Faster Transition of State Variables 153 ManagedFlag or OtherConfigFlag can be set to FALSE as soon as 154 number of valid RA with the corresponding flag set is reduced 155 to zero. 157 ii. Router Information 158 The ability for hosts to identify routers which invoke and 159 continue the operations of DHCPv6 clients may be helpful to 160 fix mis-configuration of routers or detect malicious routers. 162 5. The Revocation of DHCPv6 clients 164 In this section, we introduce several suggestions regarding how state 165 variables can be utilized to control the operation of a DHCPv6 166 client. As RFC 2462 5.5.3 specifies, a DHCPv6 client is invoked when 167 a state variable is changed from FALSE to TRUE and the DHCPv6 client 168 is not already running. As for the transition (negative transition) 169 of state variables from TRUE to FALSE , there are many possible 170 implementational choices which can be classified into two types. 172 O1 To let a DHCPv6 client determine whether the client should keep 173 its operation or not depending on state variables. 175 For example, whenever the DHCPv6 client sends a Solicit or 176 Inforamtion-Request, it may check whether to continue doing 177 DHCPv6 based on the ManagedFlag or OtherConfigFlag. In this 178 option, the existing bindings will go through their normal 179 lifecycle regardless of negative transition of the ManagedFlag 180 and the client exit after all of the leases have expired. Thus, 181 a potential benefit from this choice is for existing transport 182 layer sessions to be preserved even while routers send RA 183 messages with flags mistakenly cleared. 185 O2 To let a negative transition revoke operation of DHCPv6 clients 186 immediately. 188 The negative transition of the ManagedFlag makes a DHCPv6 client 189 stop its stateful operation, thereby all bindings are released. 190 A negative transition of the OtherConfigFlag make a DHCPv6 client 191 stop its stateless operation. 193 6. IANA Considerations 195 This document includes no request to IANA. 197 7. Security Considerations 199 As [RA-MO], Handling schemes in M & O flags from RAs in this document 200 could expedite denial of service attacks by allowing a host to 201 trigger invalid DHCP exchanges with the M or O flag set in a 202 malicious Router Advertisement and with illegitimate DHCPv6 servers. 203 Authenticated DHCPv6 and/or [RFC3971] (SEcure Neighbor Discovery) can 204 be used to protect the attack. This document introduces no 205 additional security risks. 207 8. References 209 8.1. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 215 Discovery for IP Version 6 (IPv6)", RFC 2461, 216 December 1998. 218 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 219 Autoconfiguration", RFC 2462, December 1998. 221 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 222 Neighbor Discovery (SEND)", RFC 3971, March 2005. 224 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 225 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 226 September 2007. 228 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 229 Address Autoconfiguration", RFC 4862, September 2007. 231 [RA-MO] Park, S., Madanapalli, S., and T. Jinmei, "Considerations 232 on M and O Flags of IPv6 Router Advertisement", 233 draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress)", 234 March 2005. 236 8.2. Informative References 238 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 239 and M. Carney, "Dynamic Host Configuration Protocol for 240 IPv6 (DHCPv6)", RFC 3315, July 2003. 242 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 243 (DHCP) Service for IPv6", RFC 3736, April 2004. 245 Authors' Addresses 247 Hyunwook Joseph Cha (editor) 248 SAMSUNG Electronics, Inc. 249 416, Maetan-3dong, Yeongtong-Gu 250 Suwon, Korea 252 Phone: +82-31-279-3804 253 Email: hyunwook.cha@samsung.com 255 Bernie Volz 256 Cisco Systems, Inc 257 1414 Massachusetts Ave. 258 Boxborough, MA 01719, 259 USA 261 Phone: +1-978-936-0382 262 Email: volz@cisco.com 264 Full Copyright Statement 266 Copyright (C) The IETF Trust (2008). 268 This document is subject to the rights, licenses and restrictions 269 contained in BCP 78, and except as set forth therein, the authors 270 retain all their rights. 272 This document and the information contained herein are provided on an 273 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 274 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 275 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 276 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 277 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 278 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 280 Intellectual Property 282 The IETF takes no position regarding the validity or scope of any 283 Intellectual Property Rights or other rights that might be claimed to 284 pertain to the implementation or use of the technology described in 285 this document or the extent to which any license under such rights 286 might or might not be available; nor does it represent that it has 287 made any independent effort to identify any such rights. Information 288 on the procedures with respect to rights in RFC documents can be 289 found in BCP 78 and BCP 79. 291 Copies of IPR disclosures made to the IETF Secretariat and any 292 assurances of licenses to be made available, or the result of an 293 attempt made to obtain a general license or permission for the use of 294 such proprietary rights by implementers or users of this 295 specification can be obtained from the IETF on-line IPR repository at 296 http://www.ietf.org/ipr. 298 The IETF invites any interested party to bring to its attention any 299 copyrights, patents or patent applications, or other proprietary 300 rights that may cover technology that may be required to implement 301 this standard. Please address the information to the IETF at 302 ietf-ipr@ietf.org.