idnits 2.17.1 draft-ietf-dhc-addr-registration-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 date (May 8, 2012) is 4372 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: November 8, 2012 China Mobile 5 May 8, 2012 7 A Generic IPv6 Addresses Registration Solution 8 Using DHCPv6 9 draft-ietf-dhc-addr-registration-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on November 8, 2012. 28 Copyright Notice 30 Copyright (c) 2012 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 In the IPv6 address allocation scenarios, host self-generated 46 addresses are notionally conflicted with the network managed address 47 architecture. These addresses need to be registered in the networking 48 management plate for the purposes of central address administration. 49 This document introduces a generic address registration solution 50 using DHCPv6, and defines one new ND option and one new DHCPv6 option 51 in order to propagate the solicitations of registering self-generated 52 addresses. The registration procedure reuses the existing IA_NA in 53 the DHCPv6 protocol. 55 Table of Contents 57 1. Introduction & Requirements .................................. 3 58 2. Terminology .................................................. 3 59 3. Overview of Generic Address Registration Solution ............ 3 60 4. Propagating the Address Registration Solicitation ............ 4 61 4.1. ND Address Registration Solicitation Option ............. 5 62 4.2. DHCPv6 Address Registration Solicitation Option ......... 7 63 5. DHCPv6 Address Registration Procedure ........................ 7 64 5.1. DHCPv6 Address Registration Request ..................... 7 65 5.2. DHCPv6 Address Registration Acknowledge ................. 8 66 6. Security Considerations ...................................... 8 67 7. IANA Considerations .......................................... 9 68 8. Acknowledgments .............................................. 9 69 9. References ................................................... 9 70 9.1. Normative References .................................... 9 71 9.2. Informative References ................................. 10 72 Author's Addresses ............................................. 10 74 1. Introduction & Requirements 76 In the IPv6 address allocation scenarios, there are many host self- 77 generated addresses, such as addresses in IPv6 Stateless Address 78 Configuration [RFC4862, RFC4941] scenario and Cryptographically 79 Generated Addresses (CGA, [RFC3972]), and etc. These addresses are 80 notionally conflicted with the network managed address architecture, 81 such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6, 82 [RFC3315]) managed network or network with Access Control List. 84 Many operators of enterprise networks and similarly tightly 85 administered networks have expressed the desire to be at least aware 86 the hosts' addresses when moving to IPv6. Furthermore, they may want 87 to stop the usage of some hosts' addresses for various reasons. 89 A useful way to give network administrators most of what they want, 90 while at the same time retaining compatibility with normal stateless 91 configuration would be: if the self-generated IPv6 addresses are 92 used, they may need to be registered in the networking management 93 plate. The host may be required to perform this registration since 94 only registered IPv6 addresses may access the network resources in 95 some scenarios. 97 In order to fulfill the abovementioned practice, this document 98 introduces a new Neighbor Discovery (ND) option and a new DHCPv6 99 option to propagate the address registration solicitation from 100 network management to hosts. DHCPv6 protocol is suitable to perform 101 the address registration procedure while the address registration 102 server may play by a DHCPv6 server or a stand-alone server. The 103 existing IA_NA in the DHCPv6 protocol is reused for the registration 104 procedure. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC2119 [RFC2119]. 112 3. Overview of Generic Address Registration Solution 114 By current default, the hosts with self-generated addresses do not 115 register their addresses to any network devices. However, this may 116 result that the network may reject the access request from these 117 devices if the address registration is requested. 119 As showed in below Figure 1, in the generic address registration 120 solution, proposed by this document, the network management plate 121 firstly propagates the solicitations of registering self-generated 122 addresses, by messages from either local router (step 1a in Figure 1) 123 or DHCPv6 server (step 1b in Figure 1). 125 By received such solicitations, a host using the self-generated 126 address SHOULD send an address registration request message to the 127 address registration server (step 2 in Figure 1). The address 128 registration server may be acted by a DHCPv6 server. By received the 129 address registration request, the address registration server records 130 the requested address in the address database, which MAY be used by 131 other network functions, such as DNS or ACL, etc. The address 132 registration server should also assign lifetimes for the requested 133 address. An acknowledgement is sent back to the host with the 134 assigned lifetimes (step 3 in Figure 1). 136 +--------+ +------------+ +---------------+ 137 | Host | |Local Router| |Addr-Reg Server| 138 +--------+ +------------+ +---------------+ 139 | | | 140 |Addr Register Solicitation(1a)| | 141 |<-----------------------------| | 142 | | 143 | Addr Register Solicitation(1b) | 144 |<------------------------------------------------| 145 | | 146 |Send self-generation addr registration request(2)| 147 |------------------------------------------------>| 148 | |Register 149 | Reply acknowledgment with assigned lifetimes(3) |the addr 150 |<------------------------------------------------| 152 Figure 1: address registration procedure 154 By received the acknowledgement, the host can use the registered 155 address. It SHOULD use the assigned preferred and valid lifetime for 156 the corresponded address. 158 4. Propagating the Address Registration Solicitation 160 In order to indicate or force the hosts with self-generated addresses 161 to register their addresses and the appointed address registration 162 server, new solicitation options need to be defined. 164 There are more than one mechanism in which configuration parameters 165 could be pushed to the end hosts. The address registration 166 solicitation option can be carried in Router Advertisement (RA) 167 message, which is broadcasted by local routers. In the DHCPv6 managed 168 network, it can also be carried in DHCPv6 messages. 170 More precisely it defines one new ND option and one new DHCPv6 option 171 that convey a Fully Qualified Domain Name (FQDN, as per Section 3.1 172 of [RFC1035]) of address registration(s). In order to make use of 173 these options, this document assumes appropriate name resolution 174 means (see Section 6.1.1 of [RFC1123]) are available on the host 175 client. The use of the FQDN may benefit for load-balancing purposes. 177 By receiving the address registration solicitation option(s), a host 178 SHOULD register its self-generated addresses, if there are any, to 179 the appointed registration server. The solicitation options may 180 include the IPv6 address(es) of address registration server. 182 In principle, hosts must receive a prefix from either RA message 183 [RFC4861] or DHCPv6 message [I-D.ietf-dhc-host-gen-id] so that they 184 can generate an IPv6 address by themselves. The Address Registration 185 Solicitation options could be propagated together with prefix 186 assignment information. 188 4.1. ND Address Registration Solicitation Option 190 The ND Address Registration Solicitation Option allows routers to 191 propagate the solicitation for hosts to register their self-generated 192 address. This option also carries a domain name of the appointed 193 address registration server. This option SHOULD be propagated 194 together with ND Prefix Information Option, Section 4.6.2, [RFC4861]. 195 That is also applied to the case of Neighbor Discovery Proxies 196 [RFC4389]. The format of the ND Address Registration Solicitation 197 Option is described as follows: 199 0 1 2 3 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | Pad Length | Reserved | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | | 205 . Domain Name . 206 . (Address Registration Server) . 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 . Padding . 211 . . 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Fields: 217 Type (TBA1) 219 Length The length of the option in units of 8 octets, 220 including the Type and Length fields. The value 0 221 is invalid. The receiver MUST discard a message 222 that contains this value. 224 Pad Length The number of padding octets beyond the end of the 225 Domain Name field but within the length specified 226 by the Length field. 228 Reserved Padding bits. It is for future use also. The value 229 MUST be initialized to zero by the sender, and MUST 230 be ignored by the receiver. 232 Domain Name A fully qualified domain name of the appointed 233 address registration server. The domain name is 234 encoded as specified in Section 8 of [RFC3315]. Any 235 possible future updates to Section 8 of the Section 236 8 of [RFC3315] also apply to this option. 238 Padding: A variable-length field making the option length a 239 multiple of 8, containing as many octets as 240 specified in the Pad Length field. Padding octets 241 MUST be set to zero by senders and ignored by 242 receivers. 244 4.2. DHCPv6 Address Registration Solicitation Option 246 The DHCPv6 Address Registration Solicitation Option allows DHCPv6 247 server to propagate the solicitation for hosts to register their 248 self-generated address. This option also carries a domain name of the 249 appointed address registration server. This option SHOULD be 250 propagated together with DHCPv6 Prefix Information Option, Section 5, 251 [I-D.ietf-dhc-host-gen-id]. The format of the DHCPv6 Address 252 Registration Solicitation Option is described as follows: 254 0 1 2 3 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | OPTION_Addr_Reg_Solicitation | option-len | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 . Domain Name . 261 . (Address Registration Server) . 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 option-code OPTION_Addr_Reg_Solicitation (TBA2). 267 option-len Length of this option in octets (option-code and 268 option-len are not included). 270 Domain Name A fully qualified domain name of the appointed 271 address registration server. The domain name is 272 encoded as specified in Section 8 of [RFC3315]. Any 273 possible future updates to Section 8 of the Section 274 8 of [RFC3315] also apply to this option. 276 5. DHCPv6 Address Registration Procedure 278 The current DHCPv6 protocol is reused as the address registration 279 protocol while a DHCPv6 serve plays as address registration server. 280 Identity Association for Non-temporary Addresses (IA_NA) [RFC3315] is 281 reused in order to fulfill the address registration interactions. 283 5.1. DHCPv6 Address Registration Request 285 The host with self-generated address(es) sends a DHCPv6 Request 286 message to the appointed address registration server, which may be a 287 DHCPv6 server. 289 The DHCPv6 Request message SHOULD contain at least one IA_NA option. 290 The IA_NA option SHOULD contain at least one IA Address option. The 291 host SHOULD set the T1 and T2 fields in any IA_NA options, and the 292 preferred-lifetime and valid-lifetime fields in the IA Address 293 options to 0. 295 By received, the address registration server MUST register the 296 requested address in its address database, which MAY be used by other 297 network functions, such as DNS or ACL, etc. The address registration 298 server SHOULD also assign the lifetimes for these registered 299 addresses. 301 The address database contains both the self-generated addresses and 302 the DHCPv6 assigned addresses. They MAY be marked different in the 303 database. 305 5.2. DHCPv6 Address Registration Acknowledge 307 The address registration server sends a Reply message as the response 308 to registration requests. 310 The DHCPv6 Reply message SHOULD contain at least one IA_NA option. 311 The IA_NA option SHOULD contain at least one IA Address option. The 312 server SHOULD set the T1 and T2 fields in any IA_NA options, and the 313 preferred-lifetime and valid-lifetime fields in the IA Address 314 options following the rules defined in Section 22 in [RFC3315]. 316 By received the acknowledgement from the server, the host can use the 317 registered address to access the network. It SHOULD use the values in 318 the preferred and valid lifetime fields for the preferred and valid 319 lifetimes of the address. 321 Note: the host MAY continue to use expired address, such as Locators 322 as Upper-Layer Identifiers (ULID) in Shim6 protocol [RFC5533], etc.; 323 but the network MAY refuse the network access from such addresses. 325 6. Security Considerations 327 An attacker may use a faked address registration request option to 328 indicate hosts reports their address to a malicious server and 329 collect the user information. Or, an attacker may register a faked 330 address to spoof the networking management plate. In either cases, 331 these attacks may be prevented by using Secure Neighbor Discovery 332 (SEND, [RFC3971]) if RA Address Registration Request Option is used, 333 or AUTH option [RFC3315] or Secure DHCPv6 334 [I-D.ietf-dhc-secure-dhcpv6] if DHCPv6 Address Registration Request 335 Option is used. 337 7. IANA Considerations 339 This document defines a new Neighbor Discovery [RFC4861] option, 340 which MUST be assigned Option Type values within the option numbering 341 space for Neighbor Discovery Option Type: 343 The Address Registration Solicitation Option (TBA1), described in 344 Section 4.1. 346 This document defines one new DHCPv6 [RFC3315] option, which MUST be 347 assigned Option Type values within the option numbering space for 348 DHCPv6 options: 350 The OPTION_Addr_Reg_Solicitation (TBA2), described in 351 Section 4.2; 353 8. Acknowledgments 355 The authors would like to thank Ralph Dorm, Ted Lemon, Bernie Volz 356 and other member of DHC WG for valuable comments. 358 9. References 360 9.1. Normative References 362 [RFC1035] Mockapetris, P., "Domain names - implementation and 363 specification", STD 13, RFC 1035, November 1987. 365 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 366 and Support", STD 3, RFC 1123, October 1989. 368 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 369 Requirement Levels", RFC2119, March 1997. 371 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and 372 M. Carne, "Dynamic Host Configure Protocol for IPv6", 373 RFC3315, July 2003. 375 [RFC3971] J. Arkko, J. Kempf, B. Zill, and P. Nikander, "SEcure 376 Neighbor Discovery (SEND)", RFC 3971, March 2005. 378 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 379 March 2005. 381 [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, 382 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 383 September 2007. 385 [RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless 386 Address Autoconfiguration", RFC4862, September 2007. 388 [RFC4941] T. Narten, R. Draves and S. Krishnan, "Privacy Extensions 389 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 390 September 2007. 392 [RFC5533] E. Nordmark, and M. Bagnulo, "Shim6: Level 3 Multihoming 393 Shim Protocol for IPv6", RFC 5533, June 2009. 395 9.2. Informative References 397 [RFC4389] D. Thaler, M. Talwar, and C. Patel, "Neighbor Discovery 398 Proxies (ND Proxy)", RFC4389, April 2006. 400 [I-D.ietf-dhc-secure-dhcpv6] 401 S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft- 402 ietf-dhc-secure-dhcpv6 (work in progress), December, 2011. 404 [I-D.ietf-dhc-host-gen-id] 405 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 406 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 407 November, 2011. 409 Author's Addresses 411 Sheng Jiang 412 Huawei Technologies Co., Ltd 413 Q14, Huawei Campus 414 No.156 Beiqing Road 415 Hai-Dian District, Beijing 100095 416 Email: jiangsheng@huawei.com 418 Gang Chen 419 China Mobile 420 53A, Xibianmennei Ave., Xuanwu District, Beijing 421 P.R. China 422 Phone: 86-13910710674 423 Email: phdgang@gmail.com