idnits 2.17.1 draft-jiang-6man-addr-registration-req-02.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 date (March 4, 2011) is 4792 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-07) exists of draft-ietf-dhc-secure-dhcpv6-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Jiang 2 Internet Draft Huawei Technologies Co., Ltd 3 Intended status: Standards Track G. Chen 4 Expires: September 7, 2011 China Mobile 5 March 4, 2011 7 Requirements for Addresses Registration 8 draft-jiang-6man-addr-registration-req-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted 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). Note that other groups may also distribute working 17 documents as Internet-Drafts. The list of current Internet-Drafts is 18 at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 7, 2011. 27 Copyright Notice 29 Copyright (c) 2011 IETF Trust and the persons identified as the 30 document authors. All rights reserved. 32 This document is subject to BCP 78 and the IETF Trust's Legal 33 Provisions Relating to IETF Documents 34 (http://trustee.ietf.org/license-info) in effect on the date of 35 publication of this document. Please review these documents 36 carefully, as they describe your rights and restrictions with respect 37 to this document. Code Components extracted from this document must 38 include Simplified BSD License text as described in Section 4.e of 39 the Trust Legal Provisions and are provided without warranty as 40 described in the Simplified BSD License. 42 Abstract 44 In the IPv6 address allocation scenarios, node self-generated 45 addresses are notionally conflicted with the network managed address 46 architecture. These addresses need to be registered in the networking 47 management plate for the purposes of central address administration. 48 This document discusses the requirements of address registration and 49 analyzes the possible solutions. 51 Table of Contents 53 1. Introduction & Requirements.................................3 54 2. Terminology.................................................3 55 3. Potential Solutions.........................................4 56 3.1. Generic Address Registration Procedure.................4 57 3.2. Propagating the Registration Request...................4 58 3.3. Address Registration Server and Protocol...............5 59 3.3.1. Using DHCPv6 and DHCPv6 server....................5 60 3.3.2. Defining a new address Registration Protocol......5 61 4. Security Considerations.....................................6 62 5. IANA Considerations.........................................6 63 6. Change Log [RFC Editor please remove].......................6 64 7. Acknowledgments.............................................6 65 8. References..................................................7 66 8.1. Normative References...................................7 67 8.2. Informative References.................................7 68 Author's Addresses.............................................8 70 1. Introduction & Requirements 72 In the IPv6 address allocation scenarios, node self-generated 73 addresses, such as addresses in IPv6 Stateless Address Configuration 74 [RFC4862, RFC4941] scenario and Cryptographically Generated Addresses 75 (CGA, [RFC3972]), is notionally conflicted with the network managed 76 address architecture, such as DHCPv6-managed network or network with 77 Access Control List, in which addresses are assigned and managed by 78 the network management plate. 80 The current IPv4 address allocation mode in DHCPv4-managed network is 81 that the DHCPv4 server assigns addresses. Many operators of 82 enterprise networks and similarly tightly administered networks have 83 expressed the desire to hold on to this model when moving to IPv6, 84 because they don't want to have hosts end up with essentially random 85 IPv6 addresses. However, the notion that a server assigns an address 86 is for the most part incompatible with IPv6 stateless configuration. 88 A useful way to give network administrators most of what they want, 89 while at the same time retaining compatibility with normal stateless 90 configuration would be: if the self-generated IPv6 addresses are 91 used, they may need to be registered in and granted by the networking 92 management plate. The node may be required to perform this 93 registration since only granted IPv6 addresses are allowed to be used 94 to access the network. 96 This document discusses the requirements of address registration and 97 analyzes the possible solutions. Dynamic Host Configuration Protocol 98 for IPv6 (DHCPv6) and Router Advertisement may be extended to 99 propagate the address registration request from network management to 100 nodes. A DHCPv6 server may play the address registration server with 101 newly defined DHCPv6 options. However, this may conflict with the 102 original DHCP notion. A new set of protocol may have to be defined 103 for the address registration purpose. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC2119 [RFC2119]. 111 3. Potential Solutions 113 3.1. Generic Address Registration Procedure 115 By current default, the nodes with self-generated addresses do not 116 register their addresses to any network devices. However, this may 117 result that the network may reject the access request from these 118 devices. 120 As showed in below Figure 1, in the generic address registration 121 procedure, the network management plate should firstly propagate the 122 request of registering self-generated addresses. By received such 123 requests, a node using the self-generated address should send an 124 address registration message to the network management. The network 125 management should check whether the requested address is accepted, 126 for example, performing a Duplicated Address Detect or checking the 127 address does not use the Reserved IPv6 Interface Identifiers 128 [RFC5453]. If the requested address is accepted by the network 129 management, it is registered in the address manage database, which 130 may be used by other network functions, such as DNS or ACL. An 131 acknowledgement is sent to the node, granting the usage of this 132 address. If the requested address is not accepted by the network 133 management, a rejected acknowledgement is sent to the node to 134 indicate that it must generate a new address. 136 +--------------------+ +---------+ 137 | Network Management | | Node | 138 +--------------------+ +---------+ 139 | | 140 | Request Node to register addr | 141 |----------------------------------------->| 142 | | 143 |Send self-generation addr for registration| 144 |<-----------------------------------------| 145 register | | 146 the addr |Reply granting or rejected acknowledgment | 147 |----------------------------------------->| 149 Figure 1: address registration procedure 151 3.2. Propagating the Registration Request 153 In order to indicate or force the nodes with self-generated addresses 154 to register their addresses and the appointed address registration 155 server, a new request option needs to be defined. 157 There are more than one mechanisms in which configuration parameters 158 could be pushed to the end hosts. The address registration request 159 option can be carried in Router Advertisement. In the DHCPv6 managed 160 network, it can also be carried in DHCPv6 messages. 162 By receiving attendant of the address registration request option, a 163 node MUST register its self-generated addresses, if there are any, to 164 the appointed registration server. The option may be defined to 165 include the default/enforced address registration server. 167 3.3. Address Registration Server and Protocol 169 In order to manage the address, an address registration server is 170 needed with the support a set of address registration protocol. 172 The server should hold all registered addresses. It also needs to 173 check whether the addresses meet the network address management 174 policy, also performing a Duplicated Address Detect or checking the 175 address does not use the Reserved IPv6 Interface Identifiers 176 [RFC5453], etc. Its address data may be used by other network 177 functions, such as DNS or ACL. 179 A set of address registration protocol need to at least support a 180 basic information exchange: the node sends its address to the server 181 and an acknowledgement is sent to the node. 183 3.3.1. Using DHCPv6 and DHCPv6 server 185 The current DHCPv6 protocol can be reused as the address registration 186 protocol while a DHCPv6 serve plays as address registration server. 188 The current DHCPv6 specification allows for a host to communicate a 189 set of "preferred" addresses to the server by listing these addresses 190 in IA options [RFC3315]. In order to response to registration 191 requests, an acknowledgement DHCPv6 option should be defined. It is 192 used to indicate whether the registration of an IPv6 address is 193 accepted. 195 3.3.2. Defining a new address Registration Protocol 197 However, the address registration procedure using DHC protocol may 198 conflict with the initial notional of DHC protocol. The DHC protocol 199 was originally designed to push configuration information from the 200 network management side to the hosts while the address registration 201 procedure is collecting information from hosts to the network 202 management side. 204 A new set of address registration protocol may be defined. 206 [Author notes for IETF discussion:] Any other existing protocol may 207 be used for address registration purposes? 209 4. Security Considerations 211 An attacker may use a faked address registration request option to 212 indicate hosts reports their address to a malicious server and 213 collect the user information. These attacks may be prevented by using 214 secure protocols, in Neighbor Discovery protocol case, Secure 215 Neighbor Discovery (SEND, [RFC3971]); in DHCP case, Secure DHCP 216 [I-D.ietf-dhc-secure-dhcpv6]; or other additional security 217 mechanisms. 219 An attacker could generate IPv6 address registration requests in 220 order to exhaust the server resources (or to impact on any other 221 operation that depend on the registration of the address). 223 In the use case of DHCPv6, the address registration procedure is as 224 vulnerable as all other mechanisms based on DHCPv6 to DOS attacks to 225 the server. Proper use of DHCPv6 autoconfiguration facilities 226 [RFC3315], such as AUTH option or Secure DHCP [I-D.jiang-dhc-secure- 227 dhcpv6] can prevent these threats. 229 5. IANA Considerations 231 There is no IANA considerations. 233 6. Change Log [RFC Editor please remove] 235 draft-jiang-6man-addr-registration-req-00, original version, 2010-03- 236 01 238 draft-jiang-6man-addr-registration-req-01, minor update, 2010-08-27 240 draft-jiang-6man-addr-registration-req-02, minor update, 2010-03-04 242 7. Acknowledgments 244 The authors would like to thank Cao Wei, Huawei for been involved in 245 the early requirement identification and early discussion. 247 8. References 249 8.1. Normative References 251 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 252 Requirement Levels", RFC2119, March 1997. 254 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and 255 M. Carne, "Dynamic Host Configure Protocol for IPv6", 256 RFC3315, July 2003. 258 [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor 259 Discovery (SEND) ", RFC 3971, March 2005. 261 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 262 March 2005. 264 [RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless 265 Address Autoconfiguration", RFC4862, September 2007. 267 [RFC4941] T. Narten, R. Draves and S. Krishnan, "Privacy Extensions 268 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 269 September 2007. 271 [RFC5453] S. Krishnan, "Reserved IPv6 Interface Identifiers", RFC 272 4543, February 2009. 274 8.2. Informative References 276 [I-D.ietf-dhc-secure-dhcpv6] 277 S. Jiang and S. Shen "Secure DHCPv6 Using CGAs", draft- 278 ietf-dhc-secure-dhcpv6-02 (work in progress), December, 279 2010. 281 Author's Addresses 283 Sheng Jiang 284 Huawei Technologies Co., Ltd 285 Huawei Building, No.3 Xinxi Rd., 286 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 287 P.R. China 288 Email: jiangsheng@huawei.com 290 Gang Chen 291 China Mobile 292 53A,Xibianmennei Ave., 293 Xuanwu District, 294 Beijing 100053 295 China 296 Email: phdgang@gmail.com