idnits 2.17.1 draft-daniel-ipv6-ra-mo-flags-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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 449. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 467), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 542 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 42 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 29 has weird spacing: '...ference mate...' == Line 446 has weird spacing: '... any copy...' == Line 447 has weird spacing: '...rietary righ...' == Line 448 has weird spacing: '...plement this...' == Line 465 has weird spacing: '...subject to t...' == (1 more instance...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC3637' is mentioned on line 307, but not defined ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. '2461bis' -- Possible downref: Non-RFC (?) normative reference: ref. '2462bis' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Daniel Park (ed.) 3 Internet-Draft Samsung Electronics. 4 July 11, 2004 S. Madanapalli 5 Radhakrishnan S 6 OLN Rao 7 Samsung ISO 8 Tatuya Jinmei 9 Toshiba 11 Consideration M and O Flags of IPv6 Router Advertisement 12 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance 19 with RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 10, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 This document clarifies the processing and behavior of the IPv6 47 Router Advertisement M and O flags and proposes a solution for 48 invoking the DHCPv6 based DHCPv6 administrator policy. 50 Table of Contents 52 1.0 Introduction................................................... 53 1.1 Terminology.................................................... 54 2.0 Background..................................................... 55 3.0 Requirements................................................... 56 4.0 DHCPv6 Policy Variable......................................... 57 4.1 Dependency between M & O Flags Corresponding Policy Variable... 58 4.2 M-Policy....................................................... 59 4.3 O-Policy....................................................... 60 5.0 Possible Scenarios............................................. 61 6.0 Transition of M & O flags...................................... 62 7.0 Conclusion..................................................... 63 8.0 Open Issues.................................................... 64 9.0 Security Considerations........................................ 65 10.0 IANA Considerations............................................ 66 11.0 References..................................................... 67 11.1 Normative References........................................... 68 11.2 Informative References......................................... 69 12.0 Acknowledgements............................................... 70 13.0 Authors' Addresses............................................. 72 1.0 Introduction 74 To configure host with network information such as IP address, DNS 75 server address and other configuration information several 76 mechanisms are proposed in the IETF. Particularly IPv6 stateless 77 address autoconfiguration [RFC2462] and Stateful/Stateless DHCPv6 78 [RFC3315]/[RFC3736] are widely used for configuring the network 79 information. 81 This document clarifies the processing and behavior of the IPv6 82 Router Advertisement (RA) M and O flags and specifically describes 83 the expected behavior and condition when the flag values under go 84 transition from ON (set) to OFF (unset) and vice versa. 86 This document defines an internal (conceptual) variable for DHCPv6 87 policy. The value of this variable in conjunction with the 88 "ManagedFlag" and the "OtherConfigFlag" of ND protocol [RFC2461] 89 will be used for invoking the DHCPv6 for autoconfiguration. 91 1.1 Terminology 93 o Stateful DHCPv6: Host can use Dynamic Host Configuration 94 Protocol for address autoconfiguration as 95 well as other information. The use of this 96 protocol is described in [RFC3315]. In this 97 document, this term is used in conjunction 98 with "M" flag. 100 o Stateless DHCPv6: Host can use Dynamic Host Configuration 101 Protocol for other configuration information 102 excluding address. The use of this protocol 103 is described in [RFC3736]. In this document, 104 this term is used in conjunction with "O" 105 flag. 107 2.0 Background 109 Currently, IPv6 WG is trying to mature both [RFC2461] and 110 [RFC2462] for the Draft Standard but the detailed consideration of 111 the M and O flags of IPv6 RA remains beyond scope of the basic 112 documents as [2462bis] 114 [2461bis] says: 116 M 1-bit "Managed address configuration" flag. When 117 set, it indicates Dynamic Host Configuration 118 Protocol [RFC3315] is available for address 119 autoconfiguration in addition to any addresses 120 autoconfigured using stateless address 121 autoconfiguration. More details of this flag is 122 described in [RFC2462]. 124 O 1-bit "Other stateful configuration" flag. When 125 set, it indicates a subset of DHCPv6 [RFC3736] is 126 available for autoconfiguration of other 127 (non-address) information. Examples of such 128 information are DNS-related information or 129 information on other servers within the network. 130 More details of this flag is described in 131 [RFC2462]. 133 [2462bis] says: 135 The details of how a host may use the M flags, including any use 136 of the "on" and "off" transitions for this flag, to control the 137 use of the stateful protocol for address assignment will be 138 described in a separate document. Similarly, the details of how a 139 host may use the O flags, including any use of the "on" and "off" 140 transitions for this flag, to control the use of the stateful 141 protocol for getting other configuration information will be 142 described in a separate document. 144 Particularly, both "ManagedFlag" and "OtherConfigFlag" which were 145 implementation-internal variables were removed during [2462bis] 146 work based on the WG consensus with ambiguous operational 147 experiences, thus new variables (or similar approaches) is 148 required to treat M/O flags of IPv6 RA on the host. 150 3.0 Requirements 152 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 153 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in 154 this document, are to be interpreted as described in [RFC2119] 156 4.0 DHCPv6 Policy Variable 158 This document introduces two internal (conceptual) variables for 159 the M-Policy and O-Policy, which correspond to the policy for the 160 "ManagedFlag" and the "OtherConfigFlag" of ND protocol [RFC2461] 161 will be used for controlling the DHCPv6 for autoconfiguration. 163 4.1 Dependency between M & O Flags Corresponding Policy Variable 165 Prior to introducing specific Policies, we note an important 166 dependency between these flags corresponding Policy Variable as 167 follows, 169 If we invoke Stateful DHCPv6 [RFC3315] for address 170 autoconfiguration, we basically SHOULD NOT invoke Stateless DHCPv6 171 [RFC3736] since [RFC3315] can provide other configuration 172 information as well, as described in [RFC2462]. 174 4.2 M-Policy 176 This policy variable takes three values as described below, 178 Policy 1: The host SHOULD invoke Stateful DHCPv6 for address 179 autoconfiguration regardless of the content of receiving RAs or 180 the existence of RAs. 182 Policy 2: The host SHOULD invoke Stateful DHCPv6 for address 183 autoconfiguration (along with other configuration information) 184 if and only if it sees an RA changing the M bit from unset to set. 186 Policy 3: The host SHOULD NOT invoke Stateful DHCPv6 for address 187 autoconfiguration regardless of the content of receiving RAs or 188 the existence of RAs. 190 4.3 O-Policy 192 This policy variable takes three values as described below, 194 Policy 1: The host SHOULD invoke Stateless DHCPv6 for getting 195 other configuration information regardless of the content of 196 receiving RAs or the existence of RAs. 198 Policy 2: The host SHOULD invoke Stateless DHCPv6 for getting 199 other configuration information if and only if it sees an RA 200 changing the O bit from unset to set. 202 Policy 3: The host SHOULD NOT invoke Stateless DHCPv6 for 203 getting other configuration information regardless of the 204 content of receiving RAs or the existence of RAs. 206 5.0 Possible Scenarios 208 M/O flags indicate whether the Stateful/Stateless DHCPv6 protocol 209 services are available, but they should not be used as triggers to 210 invoke the Stateful/Stateless DHCPv6 autoconfiguration protocols. 211 However, these flags in conjunction with the policy configured may 212 trigger the Stateful/Stateless DHCPv6 Protocol for automatic 213 configuration of the IPv6 address and the other information. 215 The following sections describe different scenarios for policies 216 described in Section 4.0. 218 Case: M=OFF and O=OFF 220 Scenario 1: If M-Policy is 1 222 The host invokes Stateful DHCPv6 for address autoconfiguration and 223 does not invoke Stateless DHCPv6 regardless of O-Policy. 225 Scenario 2: If M-Policy is 2 or 3 227 If O-Policy is 1, the host invokes Stateless DHCPv6 for other 228 configuration information. 230 Case: M=OFF and O=ON 232 Scenario 3: If M-Policy is 1 234 The host does not invoke Stateless DHCPv6 regardless of O-Policy. 236 Scenario 4: If M-Policy is 2 or 3 238 If O-Policy is 1 or 2, the host invoke Stateless DHCPv6 for other 239 configuration information. 241 Case: M=ON and O=OFF 243 Scenario 5: If M-Policy is 1 or 2 245 The host invokes DHCPv6 and does not invoke Stateless DHCPv6 246 regardless of O-Policy. 248 Scenario 6: If M-Policy is 3 250 If O-Policy is 1, the host invokes Stateless DHCPv6. 252 Case: M=ON and O=ON 254 Scenario 7: If M-Policy is 1 or 2 256 The host invokes Stateful DHCPv6 and does not invoke Stateless 257 DHCPv6 regardless of O-Policy. 259 Scenario 8: If M-Policy is 3 261 If O-Policy is 1 or 2, the host invokes Stateless DHCPv6. 263 6.0 Transition of M & O flags 265 The transition of the M/O flags from OFF to ON just indicates 266 that the network provides configuration information through 267 DHCPv6. This SHOULD NOT be treated as a trigger to invoke 268 DHCPv6 unless the policy dictates. 270 The transition of the M/O flags from ON to OFF does not mean 271 anything. 273 As long as the host resides in a same single network and the 274 behavior of the host should not be changed with this transition. 275 The host is not expected to store the M and O flags in 276 non-volatile memory. The host should reset these flags depending 277 on the information received in RAs when the host is rebooting. 278 Also the host SHOULD reset these flags when it moves to a 279 different network. (See Issue(1) of Section 8.0.) 281 7.0 Conclusion 283 To clarify the meaning of M/O flags of IPv6 RA, this document 284 proposes a DHCPv6 Policy variable on the host that implements 285 Stateful/Stateless DHCPv6 service for invoking DHCPv6 in 286 conjunction with M/O flags of RA. This variable is controlled by 287 administrator under a certain level of requirement. 289 Generally, both Stateful/Stateless DHCPv6 and IPv6 stateless 290 address autoconfiguration may be used simultaneously. However if 291 we invoke Stateful DHCPv6 [RFC3315] for address autoconfiguration, 292 we SHOULD NOT invoke Stateless DHCPv6 [RFC3736] since [RFC3315] 293 can provide other configuration information, like Stateless DHCPv6 294 service as described in Section 4.1. 296 [RFC3736] is just a subset of full DHCPv6. So, a host 297 implementing [RFC3315] can do both or either Stateful DHCPv6 for 298 configuring the IPv6 address and Stateless DHCPv6 for the other 299 information. A host implementing only [RFC3736] can only do 300 Stateless DHCPv6. 302 Finally, this document eventually define the default value(s) of 303 the policy(s) as below, 305 If the node implementes [RFC3315], the default value of M-Policy 306 is 2. If the node does not implement [RFC3315], the default (and 307 only) policy value is 3. When assuming [RFC3637] will be 308 implemented much wider that [RFC3315] in terms of other 309 configuration information, the default value of O-Policy is either 310 1 or 2. Perhaps value 1 is better since this service might be 311 crucial for the node (i.e., there may be no alternative to get the 312 other configuration information.) 314 Now, above conclusion of the default value remains one of open 315 issues since this is surely a controversial issue. (See Issue(2) 316 of Section 8.0.) 318 8.0 Open Issues 320 (1) Issue that was never clarified in [RFC 2461]/[RFC2462] is 321 when does a node ever reset itself once the DHCPv6 flag goes ON. 322 Does it do this on a roboot ? Does it do this when it has moved 323 to a new network ? and how does it detect this ? 325 (2) Issue on the default value(s) of the policy(s) as described in 326 Section 7.0. 328 9.0 Security Considerations 330 The concepts in this document do not significantly alter the 331 security considerations for DHCPv6 and ND Protocol. However, use 332 of these policies with variables could expedite denial of service 333 attacks by allowing a mischievous host to trigger DHCP exchanges 334 from the abnormal M/O flags set. Authenticated DHCPv6 and [SEND] 335 (SEcure Neighbor Discovery) can be used to protect the malicious 336 attack. 338 We can consider another aspect of security beside using SEND. 339 Maybe at lease sending a (log) message to the colsole/user saying 340 that you are receiving a suspicious O flag set of RA when no 341 previous RA on the same link had the O flag set, or when when 342 receiving a suspicious configuration information (particularly DNS 343 server address) if you had one before as the result of a previous 344 O flag set and you are receiving a new one as a result of a new O 345 flag set. 347 The attack is very malicious as it may be very difficult to detect 348 if we do not implement neither SEND nor the avove suggestion of 349 the real router. 351 10.0 IANA Considerations 353 This document has no considerations for IANA. 355 11.0 References 357 11.1 Normative References 359 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, March 1997. 362 [RFC2462] S. Thomson, T. Narten, "IPv6 Stateless Address 363 Autoconfiguration", RFC 2462, December 1998. 365 [RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery 366 for IP version 6", December 1998. 368 [2461bis] T. Narten, E. Nordmark, W. Simpson, H. Soliman, T. 369 Jinmei, "Neighbor Discovery for IP version 6", Internet Draft, 370 February 2004. 372 [2462bis] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless 373 Address Autoconfiguration", Internet Draft, June 2004. 375 [RFC3315] R. Droms, et. al., Dynamic Host Configuration Protocol 376 for IPv6, RFC 3315, July 2003. 378 [RFC3736] R. Droms, "Stateless DHCP Service for IPv6", RFC 3736, 379 April 2004. 381 11.2 Informative References 383 [SEND] J. Arkko et al, "SEcure Neighbor Discovery", Internet- 384 Draft, April 2004. 386 12.0 Acknowledgements 388 The approach of this document was from the RFC2461/RFC2462, so 389 authors would appreciate authors of these RFC and editor of RFC 390 2461bis/RFC2462bis. Also many thanks are IPv6 Working Group 391 guys due to their valuable discussion on this thread in the 392 mailing list. Specially thanks to Bernie Volz of Cisco for his 393 lots of valuable work on this document. 395 Alain Durand of Sun Microsystems indicated an attack changing 396 the M/O flag to ON with a rogue Stateful/Stateless DHCPv6 server 397 and kindly introduced a log message as a useful method to detect 398 a suspicious operation. 400 13.0 Authors' Addresses 402 Soohong Daniel Park (Editor) 403 Email:soohong.park@samsung.com 404 Samsung Electronics, 405 Korea 407 Syam Madanapalli 408 Email:syam@Samsung.com 409 Samsung India Software Operations, 410 India 412 Radhakrishnan S. 413 Email:rkrishnan.s@samsung.com 414 Samsung India Software Operations, 415 India 417 O.L.N. Rao 418 Email: OLNRao@samsung.com 419 Samsung India Software Operation, 420 India 422 Tatuya Jinmei 423 Email:jinmei@isl.rnc.toshiba.co.jp 424 Toshiba Corporation, 425 Japan 427 Intellectual Property Statement 429 The IETF takes no position regarding the validity or scope of any 430 Intellectual Property Rights or other rights that might be claimed 431 to pertain to the implementation or use of the technology 432 described in this document or the extent to which any license 433 under such rights might or might not be available; nor does it 434 represent that it has made any independent effort to identify any 435 such rights. Information on the IETF's procedures with respect to 436 rights in IETF Documents can be found in BCP 78 and BCP 79. 438 Copies of IPR disclosures made to the IETF Secretariat and any 439 assurances of licenses to be made available, or the result of an 440 attempt made to obtain a general license or permission for the use 441 of such proprietary rights by implementers or users of this 442 specification can be obtained from the IETF on-line IPR repository 443 at http://www.ietf.org/ipr. 445 The IETF invites any interested party to bring to its attention 446 any copyrights, patents or patent applications, or other 447 proprietary rights that may cover technology that may be 448 required to implement this standard. Please address the 449 information to the IETF at ietf-ipr@ietf.org. 451 Disclaimer of Validity 453 This document and the information contained herein are provided on 454 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 455 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 456 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 457 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 458 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 459 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 460 PARTICULAR PURPOSE. 462 Copyright Statement 464 Copyright (C) The Internet Society (2004). This document is 465 subject to the rights, licenses and restrictions contained in 466 BCP 78, and except as set forth therein, the authors retain all 467 their rights. 469 Acknowledgment 471 Funding for the RFC Editor function is currently provided by the 472 Internet Society.