idnits 2.17.1 draft-sun-softwire-lw4over6-radext-01.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([I-D.ietf-softwire-lw4over6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the BNG does not receive the lw4o6_binding attribute in the Access-Accept message and there is the unified server in BNG is not configured to allocate the port-set by itself, the unified SHOULD not response and the tunnel can not be established. -- The document date (March 4, 2014) is 3705 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: 'RFC2865' is mentioned on line 240, but not defined == Missing Reference: 'I-D.zhou-dime-4over6-provisioning' is mentioned on line 176, but not defined == Missing Reference: 'RFC3315' is mentioned on line 201, but not defined ** Obsolete undefined reference: RFC 3315 (Obsoleted by RFC 8415) == Missing Reference: 'I-D.ietf-softwire-map-dhcp' is mentioned on line 202, but not defined == Missing Reference: 'RFC6158' is mentioned on line 260, but not defined == Missing Reference: 'RFC6929' is mentioned on line 261, but not defined == Unused Reference: 'RFC3484' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC6334' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC6887' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC6333' is defined on line 397, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-00 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-00 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Xie 3 Internet-Draft Q. Sun 4 Intended status: Standards Track China Telecom 5 Expires: September 5, 2014 Q. Sun 6 Tsinghua University 7 C. Zhou 8 Huawei Technologies 9 T. Tsou 10 Huawei Technologies (USA) 11 Z. Liu 12 Tsinghua University 13 March 4, 2014 15 Radius Extension for Lightweight 4over6 16 draft-sun-softwire-lw4over6-radext-01 18 Abstract 20 lightweight 4over6(lw4over6) [I-D.ietf-softwire-lw4over6] is an 21 extension to DS-Lite in which the amount of state maintained in 22 lwAFTR has been reduced to per-subscriber-level. The lwB4 needs to 23 be provisioned with the public IPv4 address and port set it is 24 allowed to use. The DHCPv4 over DHCPv6 Transport [I.D-ietf-dhc- 25 dhcpv4-over-dhcpv6] and Dynamic Host Configuration Protocol (DHCP) 26 Option for Port Set [I.D-sun-dhc-port-set-option] can be used for 27 lwB4 to provison with the public IPv4 address and port set. 29 However, in many networks, the configuration information may be 30 stored in Authentication Authorization and Accounting (AAA) servers 31 while user configuration is mainly from Broadband Network Gateway 32 (BNG). This document defines a Remote Authentication Dial In User 33 Service (RADIUS) attribute that carries lightweight 4over6 34 configuration information from AAA server to BNG. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 5, 2014. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Lightweight 4over6 configuration process with RADIUS . . . . 3 73 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. lw4o6_binding Attribute . . . . . . . . . . . . . . . . . 6 75 5. Table of attributes . . . . . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 9.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 Lightweight 4over6 (lw4over6) [I-D.ietf-softwire-lw4over6] defines a 87 model for providing IPv4 access over an IPv6 network in which the 88 Network Address Translation (NAT) function is performed by the 89 Customer-Premises Equipment (CPE) instead of being centralized on a 90 Carrier-Grade NAT (CGN). Lightweight 4over6 features keeping per- 91 subscriber binding state in the service provider's network. This 92 per-subscriber binding state is assigned by the provisioning system 93 and should be synchronized between lwAFTRs. In lw4over6, there are 94 multiple mechanisms to provision an lwB4 with the binding state, 95 including [I.D-ietf-dhc-dhcpv4-over-dhcpv6], [I-D.ietf-softwire-map- 96 dhcp] , or [I-D.ietf-pcp-port-set], etc. 98 In many networks, user configuration information may be managed by 99 AAA (Authentication, Authorization, and Accounting) servers. Current 100 AAA servers communicate using the Remote Authentication Dial In User 101 Service (RADIUS) [RFC2865] protocol. In a fixed line broadband 102 network, the Broadband Network Gateways (BNGs) act as the access 103 gateway of users. For lw4over6 case, the BNGs are assumed to embed a 104 DHCPv4-over-DHCPv6 server function which allows them to locally 105 handle any DHCPv4-over-DHCPv6 requests issued by hosts. The 106 operators may per-configure subscriber's binding state in AAA server 107 which then passes the information to a BNG and in turn populates the 108 mapping of the subscribe. 110 This document defines a new RADIUS attribute that can be used in 111 lightweight 4over6 to carry subscriber's binding state. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 Terminology defined in [I-D.ietf-softwire-lw4over6] is used 120 extensively in this document. 122 3. Lightweight 4over6 configuration process with RADIUS 124 The below Figure 1 illustrates how the RADIUS protocol and DHCPv4 125 -over-DHCPv6 cooperate to provide lwB4 with the binding state. 127 lwB4 BNG lwAFTR AAA 128 | | Server 129 |--PPP LCP Config-Request---->| | | 130 | | | | 131 |<--PPP LCP Config-ACK ------| | | 132 |--PPP IPv6CP Config-Request->| | | 133 |<-PPP IPv6CP Config-ACK ----| | | 134 |-------DHCPv6 Solicit------->| | | 135 |<------DHCPv6 Advertisement--| | | 136 |-------DHCPv6 Request------->| | | 137 |<------DHCPv6 Reply----------| | | 138 | | | | 139 |--------DHCPv4-QUERY-------> | | | 140 | (OPTION_DHCPV4_MSG) |-------Access-Request------->| 141 | | (lw4o6 attr) | 142 | | |<-Configuration-| 143 | | | (Optional) | 144 | | |-----ACK------->| 145 | |<------Access-Accept---------| 146 | | (lw4o6 attr) | 147 |<-------DHCPv4-RESPONSE----- | | | 148 | (OPTION_DHCPV4_MSG) | | | 149 | | | | 151 DHCPv4-over-DHCPv6 RADIUS 153 Figure 1: Lightweight 4over6 configuration process with RADIUS case 1 155 BNGs act as a client of RADIUS and as a Unified server. The lwB4 156 will firstly get the IPv6 address via DHCPv6 process. It then 157 initiates a DHCPv4-QUERY message with OPTION_DHCPV4_MSG Option. 158 Since the lwB4 has known the address of the Unified server in 159 advance, it is recommanded to send the DHCPv4-QUERY message using 160 unicast address. When receving the DHCPv4-QUERY from lwB4, the BNG 161 SHOULD intercept the subscriber's IPv6 address and stored locally. 162 Then, the BNG SHOULD initiate a RADIUS Access-Request message, in 163 which the User-Name attribute (1) SHOULD be filled by the lwB4 MAC 164 address, to the RADIUS server,the User-password attribute (2) SHOULD 165 be filled by the shared lw4over6 password that has been preconfigured 166 on the DHCPv6 server to get lw4over6 attribute. The IPv6 address in 167 lw4o6 attribute should be filled by the subscriber's IPv6 address. 168 The AAA server will then determine the IPv4 address and Port Set for 169 the subscriber. 171 The subscriber's binding state should be syncronized between AAA 172 server and lwAFTR. If the bindings are pre-configured statically in 173 both AAA server and lwAFTR, the AAA server does not need to configure 174 lwAFTR anymore. Otherwise, if the bindings are locally creately in 175 AAA server on-demand, it should inform the lwAFTR with the 176 subscriber's binding state using [I-D.zhou-dime-4over6-provisioning] 177 or COA requests. 179 Figure 2 illustrates how the RADIUS protocol and DHCPv6 cooperate to 180 provide lwB4 and lwAFTR with tunnel configuration information. 182 lwB4 BNG AAA Server lwAFTR 183 | | | | 184 | --DHCPv6 Request--> | | | 185 |(OPTION_S46_CONT_LW) | | | 186 | | --Access-Request--> | | 187 | | (lw4o6 attr) | | 188 | | |--configuration--> | 189 | | | (Optional) | 190 | | | <------ACK------- | 191 | | <--Access-Accept--- | | 192 | | (lw4o6 attr) | | 193 | <--DHCPv6 Reply---- | | | 194 |(OPTION_S46_CONT_LW) | | | 195 DHCPv6 Radius 197 Figure 2: Lightweight 4over6 configuration process with RADIUS case 2 199 BNGs act as a RADIUS client and as a DHCPv6 server. Before the 200 tunnel establishes, lwB4 MAY initiate a DHCPv6 Solicit message that 201 includes an Option Request option[RFC3315] with OPTION_S46_CONT_LW 202 option defined in [I-D.ietf-softwire-map-dhcp]. When BNG receives 203 the SOLICIT, it SHOULD initiates radius Access-Request message, in 204 which the User-Name attribute (1) SHOULD be filled by the lwB4 MAC 205 address, to the RADIUS server,the User-password attribute (2) SHOULD 206 be filled by the shared lw4over6 password that has been preconfigured 207 on the DHCPv6 server to get lw4over6 attribute. 209 If the authentication request is approved by the AAA server, AAA 210 server will determine the IPv6 address, IPv4 address and Port Set for 211 the subscriber. The subscriber's binding state should be syncronized 212 between AAA server and lwAFTR. If the bindings are pre-configured 213 statically in both AAA server and lwAFTR, the AAA server does not 214 need to configure lwAFTR anymore. Otherwise, if the bindings are 215 locally creately in AAA server on-demand, it should inform the lwAFTR 216 as mentioned above. 218 Similarly, BNGs can act as a RADIUS client and as a PCP server in 219 case an lwB4 runs a PCP client (as depicted in Figure 3). 221 lwB4 BNG lwAFTR AAA Server 222 | | | | 223 |---PCP_PORT_SET Request----->| | | 224 | |-------Access-Request------->| 225 | | (lw4o6 attr) | 226 | | |<-Configuration-| 227 | | | (Optional) | 228 | | |-----ACK------->| 229 | |<------Access-Accept---------| 230 | | (lw4o6 attr) | 231 |<---PCP_PORT_SET Request---- | | | 232 | | | | 233 | | | | 235 PCP Port_set RADIUS 237 Figure 3: Lightweight 4over6 configuration process with RADIUS case 3 239 In the above-mentioned scenarios, Message-Authenticator (type 80) 240 [RFC2865] SHOULD be used to protect both Access-Request and Access- 241 Accept messages. 243 After receiving the lw4over6-binding attribute in the initial Access- 244 Accept, the BNG SHOULD store the received lw4over6 configuration 245 parameters locally. When the lw4over6 CE sends a DHCP or PCP Request 246 message to request an extension of the lifetime for the assigned 247 address, the BNG does not have to initiate a new Access-Request 248 towards the AAA server to request the lw4o6 binding state. The BNG 249 could retrieve the previously stored lw4o6 configuration parameters 250 and use them in its reply. The BNG will then inform the AAA server 251 with updated lifetime. 253 If the BNG does not receive the lw4over6-binding attribute in the 254 Access-Accept or if the BNG receives an Access-Reject, the tunnel 255 cannot be established. 257 4. Attributes 259 This section defines the lw4o6_binding attribute that is used in both 260 above-mentioned scenarios. The attribute design follows [RFC6158] 261 and refers to [RFC6929]. 263 4.1. lw4o6_binding Attribute 265 The lw4o6_binding RADIUS attribute contains the subscriber's binding 266 information including IPv6 address, IPv4 address and the port-set. 267 The BNG SHALL use the binding entry returned in the RADIUS 268 lw4o6_binding attribute to populate the requests. 270 If the BNG includes the lw4o6_binding attribute, but the AAA server 271 does not recognize it, this attribute MUST be ignored by the AAA 272 server. 274 If the BNG does not receive the lw4o6_binding attribute in the 275 Access-Accept message and there is the unified server in BNG is not 276 configured to allocate the port-set by itself, the unified SHOULD not 277 response and the tunnel can not be established. 279 When the Access-Request message is triggered by a DHCP Rebind 280 message, if the binding attribute received in the Access-Accept 281 message is different from the currently used one for that session, 282 the BNG MUST force the lwB4 to re-establish the tunnel using the new 283 binding information received in the Access-Accept message. 285 The lw4o6_binding Attribute is structured as follows: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Length | Reserved | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 | IPv6 address | 294 | | 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | IPv4 address | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Port Set Index | Port Set Mask | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Type 304 TBD 306 Length 308 28 309 Port Set Index: 310 Port Set Index identifies a set of ports assigned 311 to a device. The first k bits on the left of the 2-octet 312 field is the Port Set Index value, with the rest of the 313 field right padding zeros. 314 Port Set Mask: 315 Port Set Mask indicates the position of the bits 316 used to build the mask. The first k bits on the left is 317 padding ones while the remained (16-k) bits of the 2-octet 318 field on the right is padding zeros. 319 IPv4 address 320 The translated IPv4 address for a subscriber. 321 IPv6 address 322 The IPv6 address for a subscriber. 324 Figure 4: Lightweight 4over6 Attribute 326 5. Table of attributes 328 The following table provides a guide to which attributes may be found 329 in which kinds of packets, and in what quantity. 331 Request Accept Reject Challenge Accounting # Attribute 332 Request 333 0-1 0-1 0 0 0-1 TBD1 lw4o6-binding 334 0-1 0-1 0 0 0-1 1 User-Name 335 0-1 0 0 0 0 2 User-Password 336 0-1 0-1 0 0 0-1 6 Service-Type 337 0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator 339 The following table defines the meaning of the above table entries. 341 0 This attribute MUST NOT be present in packet. 342 0+ Zero or more instances of this attribute MAY be present in 343 packet. 344 0-1 Zero or one instance of this attribute MAY be present in 345 packet. 346 1 Exactly one instance of this attribute MUST be present in 347 packet. 349 Figure 5: Lightweight 4over6 Attribute Table 351 6. Security Considerations 353 TO BE COMPLETED 355 7. IANA Considerations 357 This document has no IANA actions. 359 8. Acknowledgements 361 The authors would like to thank the following individuals who have 362 participated in the drafting, review, and discussion of this memo: TO 363 BE COMPLETED 365 9. References 367 9.1. Normative References 369 [I-D.ietf-pcp-port-set] 370 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 371 and S. Perreault, "Port Control Protocol (PCP) Extension 372 for Port Set Allocation", draft-ietf-pcp-port-set-00 (work 373 in progress), March 2013. 375 [I-D.ietf-softwire-lw4over6] 376 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 377 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 378 Architecture", draft-ietf-softwire-lw4over6-00 (work in 379 progress), April 2013. 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [RFC3484] Draves, R., "Default Address Selection for Internet 385 Protocol version 6 (IPv6)", RFC 3484, February 2003. 387 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 388 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 389 RFC 6334, August 2011. 391 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 392 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 393 2013. 395 9.2. Informative References 397 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 398 Stack Lite Broadband Deployments Following IPv4 399 Exhaustion", RFC 6333, August 2011. 401 Authors' Addresses 403 Chongfeng Xie 404 China Telecom 405 P.R.China 407 Phone: 86 10 58552116 408 Email: xiechf@ctbri.com.cn 410 Qiong Sun 411 China Telecom 412 P.R.China 414 Phone: 86 10 58552936 415 Email: sunqiong@ctbri.com.cn 416 Qi Sun 417 Tsinghua University 418 Department of Computer Science, Tsinghua University 419 Beijing 100084 420 P.R.China 422 Phone: +86-10-6278-5822 423 Email: sunqibupt@gmail.com 425 Cathy Zhou 426 Huawei Technologies 427 Bantian, Longgang District 428 Shenzhen 518129 429 P.R. China 431 Email: cathy.zhou@huawei.com 433 Tina Tsou 434 Huawei Technologies (USA) 435 2330 Central Expressway 436 Santa Clara, CA 95050 437 USA 439 Phone: +1 408 330 4424 440 Email: Tina.Tsou.Zouting@huawei.com 442 ZiLong Liu 443 Tsinghua University 444 Beijing 100084 445 P.R.China 447 Phone: +86-10-6278-5822 448 Email: liuzilong8266@126.com