idnits 2.17.1 draft-jiang-dhc-addr-registration-04.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 (Feb 27, 2012) is 4442 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: August 29, 2012 China Mobile 5 Feb 27, 2012 7 A Generic IPv6 Addresses Registration Solution 8 Using DHCPv6 9 draft-jiang-dhc-addr-registration-04.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 August 29, 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 ......... 6 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 .......................................... 8 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 mechanisms 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 The format of the ND Address Registration Solicitation Option is 196 described as follows: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | Pad Length | Reserved | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | 204 . Domain Name . 205 . (Address Registration Server) . 206 | | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 . Padding . 210 . . 211 | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Fields: 215 Type (TBA1) 217 Length The length of the option in units of 8 octets, 218 including the Type and Length fields. The value 0 219 is invalid. The receiver MUST discard a message 220 that contains this value. 222 Pad Length The number of padding octets beyond the end of the 223 Domain Name field but within the length specified 224 by the Length field. 226 Reserved Padding bits. It is for future use also. The value 227 MUST be initialized to zero by the sender, and MUST 228 be ignored by the receiver. 230 Domain Name A fully qualified domain name of the appointed 231 address registration server. The domain name is 232 encoded as specified in Section 8 of [RFC3315]. Any 233 possible future updates to Section 8 of the Section 234 8 of [RFC3315] also apply to this option. 236 Padding: A variable-length field making the option length a 237 multiple of 8, containing as many octets as 238 specified in the Pad Length field. Padding octets 239 MUST be set to zero by senders and ignored by 240 receivers. 242 4.2. DHCPv6 Address Registration Solicitation Option 244 The DHCPv6 Address Registration Solicitation Option allows DHCPv6 245 server to propagate the solicitation for hosts to register their 246 self-generated address. This option also carries a domain name of the 247 appointed address registration server. This option SHOULD be 248 propagated together with DHCPv6 Prefix Information Option, Section 5, 249 [I-D.ietf-dhc-host-gen-id]. The format of the DHCPv6 Address 250 Registration Solicitation Option is described as follows: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | OPTION_Addr_Reg_Solicitation | option-len | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 . Domain Name . 259 . (Address Registration Server) . 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 option-code OPTION_Addr_Reg_Solicitation (TBA2). 265 option-len Length of this option in octets (option-code and 266 option-len are not included). 268 Domain Name A fully qualified domain name of the appointed 269 address registration server. The domain name is 270 encoded as specified in Section 8 of [RFC3315]. Any 271 possible future updates to Section 8 of the Section 272 8 of [RFC3315] also apply to this option. 274 5. DHCPv6 Address Registration Procedure 276 The current DHCPv6 protocol is reused as the address registration 277 protocol while a DHCPv6 serve plays as address registration server. 278 Identity Association for Non-temporary Addresses (IA_NA) [RFC3315] is 279 reused in order to fulfill the address registration interactions. 281 5.1. DHCPv6 Address Registration Request 283 The host with self-generated address(es) sends a DHCPv6 Request 284 message to the appointed address registration server, which may be a 285 DHCPv6 server. 287 The DHCPv6 Request message SHOULD contain at least one IA_NA option. 288 The IA_NA option SHOULD contain at least one IA Address option. The 289 host SHOULD set the T1 and T2 fields in any IA_NA options, and the 290 preferred-lifetime and valid-lifetime fields in the IA Address 291 options to 0. 293 By received, the address registration server MUST register the 294 requested address in its address database, which MAY be used by other 295 network functions, such as DNS or ACL, etc. The address registration 296 server SHOULD also assign the lifetimes for these registered 297 addresses. 299 The address database contains both the self-generated addresses and 300 the DHCPv6 assigned addresses. They MAY be marked different in the 301 database. 303 5.2. DHCPv6 Address Registration Acknowledge 305 The address registration server sends a Reply message as the response 306 to registration requests. 308 The DHCPv6 Reply message SHOULD contain at least one IA_NA option. 309 The IA_NA option SHOULD contain at least one IA Address option. The 310 server SHOULD set the T1 and T2 fields in any IA_NA options, and the 311 preferred-lifetime and valid-lifetime fields in the IA Address 312 options following the rules defined in Section 22 in [RFC3315]. 314 By received the acknowledgement from the server, the host can use the 315 registered address to access the network. It SHOULD use the values in 316 the preferred and valid lifetime fields for the preferred and valid 317 lifetimes of the address. 319 Note: the host MAY continue to use expired address, such as Locators 320 as Upper-Layer Identifiers (ULID) in Shim6 protocol [RFC5533], etc.; 321 but the network MAY refuse the network access from such addresses. 323 6. Security Considerations 325 An attacker may use a faked address registration request option to 326 indicate hosts reports their address to a malicious server and 327 collect the user information. These attacks may be prevented by using 328 Secure Neighbor Discovery (SEND, [RFC3971]) if RA Address 329 Registration Request Option is used, or AUTH option [RFC3315] or 330 Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] if DHCPv6 Address 331 Registration Request Option is used. 333 7. IANA Considerations 335 This document defines a new Neighbor Discovery [RFC4861] option, 336 which MUST be assigned Option Type values within the option numbering 337 space for Neighbor Discovery Option Type: 339 The Address Registration Solicitation Option (TBA1), described in 340 Section 4.1. 342 This document defines one new DHCPv6 [RFC3315] option, which MUST be 343 assigned Option Type values within the option numbering space for 344 DHCPv6 options: 346 The OPTION_Addr_Reg_Solicitation (TBA2), described in 347 Section 4.2; 349 8. Acknowledgments 351 The authors would like to thank Ralph Dorm, Ted Lemon, Bernie Volz 352 and other member of DHC WG for valuable comments. 354 9. References 356 9.1. Normative References 358 [RFC1035] Mockapetris, P., "Domain names - implementation and 359 specification", STD 13, RFC 1035, November 1987. 361 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 362 and Support", STD 3, RFC 1123, October 1989. 364 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 365 Requirement Levels", RFC2119, March 1997. 367 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and 368 M. Carne, "Dynamic Host Configure Protocol for IPv6", 369 RFC3315, July 2003. 371 [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor 372 Discovery (SEND) ", RFC 3971, March 2005. 374 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 375 March 2005. 377 [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, 378 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 379 September 2007 381 [RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless 382 Address Autoconfiguration", RFC4862, September 2007. 384 [RFC4941] T. Narten, R. Draves and S. Krishnan, "Privacy Extensions 385 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 386 September 2007. 388 [RFC5533] E. Nordmark, and M. Bagnulo, "Shim6: Level 3 Multihoming 389 Shim Protocol for IPv6", RFC 5533, June 2009. 391 9.2. Informative References 393 [I-D.ietf-dhc-secure-dhcpv6] 394 S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft- 395 ietf-dhc-secure-dhcpv6 (work in progress), December, 2011. 397 [I-D.ietf-dhc-host-gen-id] 398 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 399 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 400 November, 2011. 402 Author's Addresses 404 Sheng Jiang 405 Huawei Technologies Co., Ltd 406 Q14, Huawei Campus 407 No.156 Beiqing Road 408 Hai-Dian District, Beijing 100095 409 Phone: 86-10-82882681 410 Email: jiangsheng@huawei.com 412 Gang Chen 413 China Mobile 414 53A, Xibianmennei Ave., Xuanwu District, Beijing 415 P.R. China 416 Phone: 86-13910710674 417 Email: phdgang@gmail.com