idnits 2.17.1 draft-liu-ipv6-renum-conflicts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2011) is 4789 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: 'RFC1900' is mentioned on line 83, but not defined == Missing Reference: 'RFC2119' is mentioned on line 181, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT B.Liu 3 Intended Status: Standard Track S.Jiang 4 Expires: September 8, 2011 Huawei Technologies Co., Ltd 5 March 7, 2011 7 SLAAC/DHCPv6 conflicts diagnostic during site renumbering 8 draft-liu-ipv6-renum-conflicts-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright and License Notice 33 Copyright (c) 2011 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Abstract 48 While an IPv6 site is being renumbered, both DHCPv6 and ND may be 49 used to reconfigure the host addresses. This may cause potential 50 address configuration conflicts during renumbering procedure. The 51 issue mainly include two situations: a) Address configuration method 52 conflict, which means a host receives a new prefix comes from another 53 address configuration protocol. b) Address prefix conflict, a host 54 receives both DHCPv6 and ND address configuration messages which 55 assign different address prefixes. This documents analyzes the 56 conflict issues and proposes a conflict report mechanism for hosts to 57 report the conflicts to DHCPv6 servers. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 IPv6 renumbering . . . . . . . . . . . . . . . . . . . . . 3 63 1.2 DHCPv6/ND address configuration conflict . . . . . . . . . 3 64 2 Terminolog . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3 Conflict Report Mechanism . . . . . . . . . . . . . . . . . . . 5 66 3.1 Host behavior . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2 Conflict Report Trigger . . . . . . . . . . . . . . . . . . 5 68 3.3 DHCPv6 Reconfiguration Conflict Options . . . . . . . . . . 6 69 3.4 Report processing by DHCPv6 server . . . . . . . . . . . . 6 70 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 72 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 73 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7.1 Normative References . . . . . . . . . . . . . . . . . . . 7 75 7.2 Informative References . . . . . . . . . . . . . . . . . . 7 76 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1 Introduction 80 1.1 IPv6 renumbering 82 "Renumbering" is an event of changing in IP addressing information 83 associated with a host or subnet [RFC1900]. [RFC5887] and 84 [I-D.chown-v6ops-renumber-thinkabout] described numerous reasons why 85 such sites might need to renumber in a planned fashion, for example, 86 change of site topology, change of service provider etc. 88 [RFC4192] provided a general procedure of renumbering in an IPv6 89 network, which is achieved by changing address prefix. Before the old 90 prefix is withdrawn, the hosts are assigned a new prefix. Both the 91 old and the new prefixes may be usable till the new prefix is stable 92 in the site systems, such as DNS, ACL .etc. Then the old prefix will 93 be withdrawn. The transition periods are variable according to 94 different network management settings. 96 [RFC4192] also mentioned several methods to reconfigure addresses 97 while renumbering: 99 o Stateful address configuration through Dynamic Host 100 Configuration Protocol for IPv6 (DHCPv6) protocol [RFC3315] 102 o Stateless address configuration through Neighbor Discovery 103 Protocol[RFC4861] (SLAAC) [RFC4862] 105 o Manual configuration 107 This document focuses on the address reconfiguration problem and 108 there is a specific issue of IPv6 site renumbering described as the 109 following. 111 1.2 DHCPv6/ND address configuration conflict 113 Both of the DHCPv6 and ND protocols have IP address configuration 114 function. They are suitable for different scenarios respectively. 115 During renumbering, the SLAAC-configured hosts can reconfigure IP 116 addresses by receiving ND Router Advertisement (RA) messages 117 containing new prefix information. The DHCPv6-configured hosts can 118 reconfigure addresses by initialing RENEW sessions when the current 119 addresses' lease time is expired or receiving the reconfiguration 120 messages initialed by the DHCPv6 servers. 122 But DHCPv6 and ND address configuration may overlap and cause 123 conflict on a host. The issue includes two situations: 125 - A DHCPv6-configured host receives RA messages containing new 126 prefix 128 Ideally, hosts in a DHCPv6-managed network should not receive any ND 129 address configuration messages to avoid potential confusion. But some 130 factors may cause this happen. For example, a sub-net of a DHCPv6- 131 managed network may be mis-configured to use SLAAC for address 132 configuration; or a DHCPv6-managed network contains hosts (some 133 specific types of Apple Mac computers, e.g.) that don't support 134 DHCPv6 as the default so that SLAAC will be used along with DHCPv6 as 135 a necessary supplement. 137 There are no standards specifying what approach should be taken by a 138 DHCPv6-configured host when it receives RA messages containing new 139 prefix. It depends on the operation system of the host and cannot be 140 predicted or controlled by the network. If the host accepts the new 141 prefix in RA, it may violet the DHCPv6-managed policies. But if it 142 ignores the RA messages and there are no DHCPv6 reconfiguration 143 messages received either, the renumbering would fail. What is worse, 144 the host may even receive both the RA messages and DHCP-v6 145 reconfiguration messages and finds the prefixes in the two protocols 146 are different. This means serious network configuration error 147 occurring. 149 - A SLAAC-configured finds DHCPv6 is in use 151 [RFC5887] and [I-D.jiang-ipv6-site-renum-guideline] mentioned RA 152 message of ND protocol contains a "Managed Configuration" flag to 153 indicate DHCPv6 is in use. But it is unspecified what behavior should 154 be taken when the host receives RA messages with "M" set to 1. The 155 gap of standard will cause ambiguous host behavior because it depends 156 on the operation system of the host. 158 The host may start a DHCPv6 session and receives the DHCPv6 address 159 configuration. It is also possible that the host finds the DHCPv6 160 assigned prefix is different from the prefix in the RA messages, 161 which means there is a serious network configuration error. 163 Another possibility is that the host may receive no response from any 164 DHCPv6 servers, which means the DHCPv6 service is not available and 165 the "Managed Configuration" flag was mis-configured. 167 These potential conflicts described above need to be addressed. This 168 document proposes a report mechanism for hosts to report the 169 conflicts to DHCPv6 servers. (The mis-configured "Managed 170 Configuration" flag issue described above is not addressed in this 171 document because there are no DHCPv6 servers available in that 172 circumstance. Whether it needs to report the conflict to routers or 173 some other servers such as network management systems needs further 174 study.) 176 2 Terminolog 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119 [RFC2119]. 182 3 Conflict Report Mechanism 184 As analyzed above, while renumbering, hosts received address 185 configuration messages (either ND or DHCP protocol messages), if the 186 messages conflict with existing/previous configuration mechanism, 187 hosts report address configuration policy conflict information to the 188 network. And then they accept the address configuration indication 189 from the network. 191 The conflicts can be outlined as two types: 193 - Prefix conflict, which means prefixes in DHCPv6 and ND messages 194 are different. 196 - Address configuration method conflict, which means a host 197 receives a new prefix comes from another address configuration 198 protocol. 200 There are several approaches of the mechanism as the following 201 clauses. 203 3.1 Host behavior 205 For the DHCPv6-configured hosts, it assumes that they will monitor 206 the RA messages after being configured by DHCPv6. 208 For the SLAAC-configured hosts, it assumes that the hosts initially 209 explored the DHCPv6 servers based on having already chosen DHCPv6 as 210 high priority of address configuration protocol when it finds the 211 "Managed Configuration" flag is set. 213 3.2 Conflict Report Trigger 215 Rules for the hosts to trigger conflict reports are as the following: 217 - Prefix conflict trigger, a host will trigger the report when it 218 finds the prefixes are different in DHCPv6 and ND messages. 220 - Address configuration method conflict trigger, a DHCPv6-managed 221 host receives a new prefix comes from RA messages. 223 3.3 DHCPv6 Reconfiguration Conflict Options 225 New DHCPv6 options could be defined respectively for the clients to 226 report conflicts to servers and for servers to response according to 227 analysis of the reported conflict details. 229 - Option_ReconfigConflict_Report 231 It is possible to include this option into the renew message. The 232 content of the option could be: 234 a) New available address prefix (prefix in RA e.g.). 235 b) Serious error of prefix conflict. 237 - Option_ReconfigConflict_Response 239 DHCPv6 server could response as the following possibilities 240 according to information got from the option: 242 a) Directly assigns new addresses to the hosts who report 243 conflicts. 244 b) Indicates hosts to make SLAAC according to RA messages 245 received. 246 c) Report the prefixes conflict to network management system. 248 3.4 Report processing by DHCPv6 server 250 When a DHCPv6 server receives the conflict reports, it should analyze 251 the report and decides whether to forward the report to relative 252 network management systems or indicate what approach should be taken 253 to the hosts through DHCPv6 messages defined in section 3.3, however, 254 the analysis processing of DHCPv6 servers is not in the scope of this 255 memo. 257 4 Security Considerations 259 This document doesn't provide additional security considerations for 260 IPv6 site renumbering more than [RFC5887], [RFC4192] and other 261 relative documents. 263 For the conflict report mechanism, there is a potential threat that 264 any malicious host can fake conflict reports to DHCPv6 servers which 265 may disturb the network manager when the report is prefix conflict, 266 however, it cannot directly break the availability of the network. 268 5 IANA Considerations 270 This document requests IANA to assign new DHCPv6 option number.(TBD) 272 6 Acknowledgements 274 This document inherits various previous work. Thanks for Brian 275 Carpenter, Randall Atkinson, Hannu Flinck, Fred Baker, Eliot Lear, 276 Ralph Droms, Tim J. Chown, Mark K. Thompson, Alan Ford, and Stig 277 Venaas. 279 7 References 281 7.1 Normative References 283 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., 284 and M. Carney, "Dynamic Host Configuration Protocol for 285 IPv6(DHCPv6)", RFC 3315, July 2003. 287 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 288 Soliman,"Neighbor Discovery for IP version 6 (IPv6)", RFC 289 4861,September 2007. 290 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 291 Address Autoconfiguration", RFC 4862, September 2007. 293 7.2 Informative References 295 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck,"Renumbering 296 Still Needs Work", RFC 5887, May 2010. 298 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 299 Renumbering an IPv6 Network without a Flag Day", RFC 300 4192, September 2005. 302 [I-D.jiang-ipv6-site-renum-guideline] 303 Jiang, S., and Liu B., "IPv6 Site Renumbering Guidelines 304 and Further Works", working in progress. 306 [I-D.chown-v6ops-renumber-thinkabout] 307 Chown, T., and Thompson, M., "Things to think about when 308 Renumbering an IPv6 network", September 2006. 310 Author's Addresses 312 Bing Liu 313 Huawei Technologies Co., Ltd 314 Huawei Building, No.3 Xinxi Rd., 315 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 316 P.R. China 317 Email: leo.liubing@huawei.com 319 Sheng Jiang 320 Huawei Technologies Co., Ltd 321 Huawei Building, No.3 Xinxi Rd., 322 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 323 P.R. China 324 Email: jiangsheng@huawei.com