idnits 2.17.1 draft-sun-softwire-lw4over6-dhcpv6-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 14 instances of too long lines in the document, the longest one being 10 characters 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2013) is 3943 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) == Unused Reference: 'I-D.ietf-pcp-port-set' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC6887' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'RFC6333' is defined on line 313, 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 (~~), 8 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: January 9, 2014 Y. Lee 6 Comcast 7 T. Tsou 8 Huawei Technologies (USA) 9 Y. Chen 10 Tsinghua University 11 July 8, 2013 13 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for 14 Lightweight 4over6 15 draft-sun-softwire-lw4over6-dhcpv6-00 17 Abstract 19 Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is an extension to 20 DS-Lite which moves the Network Address Translation function from the 21 DS-Lite AFTR to the B4. It can be deployed in a DS-Lite network to 22 gradually reduce the load of Carrier Grade NAT in the AFTR. However, 23 when DS-Lite and lw4over6 co-exist in the same network, B4 elemtns 24 and lwB4 elements may want to signal the DHCPv6 server the type of 25 AFTR (i.e. AFTR or lwAFTR) they request. In this memo, a new DHCPv6 26 option is proposed for lwB4 element to request the IPv6 address of 27 its corresponding lwAFTR. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 9, 2014. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 3 66 4. The lwAFTR-Name DHCPv6 Option . . . . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Lightweight 4over6 (lw4o6) [I-D.ietf-softwire-lw4over6] defines a 77 model for providing IPv4 access over an IPv6 network in which the 78 Network Address Translation (NAT) function is performed by the 79 Customer-Premises Equipment (CPE) instead of being centralized on a 80 Carrier-Grade NAT (CGN). It removes the requirement for a Carrier 81 Grade NAT function in the AFTR, and reduces the amount of centralized 82 state in the AFTR. 84 The DHCPv4 over DHCPv6 Transport [I.D-ietf-dhc-dhcpv4-over-dhcpv6] 85 and Dynamic Host Configuration Protocol (DHCP) Option for Port Set 86 [I.D-sun-dhc-port-set-option] can be used for lwB4 to be provisoned 87 with the public IPv4 address and port set. To discover the lwAFTR's 88 FQDN, [I-D.ietf-softwire-lw4over6] re-uses the DS-Lite DHCPv6 option 89 defined in [RFC6334]. However, for operators who have deployed DS- 90 Lite and will deploy lw4over6 in the same network using the same 91 DHCPv6 option, the DHCPv6 server will not be able to distinguish 92 between DS-Lite subscriber and lw4over6 subscriber. 94 In this memo, we define a new DHCPv6 option for lwB4 95 [I-D.ietf-softwire-lw4over6] to request the DHCPv6 server its 96 corresponding lwAFTR. This new DHCPv6 option enables the DHCPv6 97 server to distinguish between DS-Lite subscriber and lw4over6 98 subscriber and offer the requested resources to the subscribers. 99 This removes the requirement to pre-provision the subscriber type 100 (i.e., DS-Lite or lw4over6) in the provision system. This option is 101 particularly helpful in a scenario where operators offer both DS-Lite 102 and lw4over6 in the same network. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 Terminology defined in [I-D.ietf-softwire-lw4over6] is used 111 extensively in this document. 113 3. Application Scenario 115 There are several possible deployment scenarios in which DS-Lite and 116 lw4over6 co-exist in the same network. 118 In scenario 1, DS-Lite and lw4over6 are deployed in the same AFTR 119 (depicted in Figure1). 121 +---------------+--------------| 122 + | | 123 +---------+ +------+---+ +--+--+ | 124 | Host | | LW 4over6| | | | 125 | |--| Initiator| ======-| BNG | === +-------------+ +-----------+ 126 +---------+ +----------+ +--|--+ |LW 4over6 | | IPv4 | 127 | lwAFTR | | Internet | 128 +---------+ +------+---+ +--+--+ |DS-Lite AFTR | | | 129 | Host |--| DS-Lite | =======| | ====+-------------+ +-----------+ 130 | | | B4 | | BNG | | 131 +---------+ +----------+ +--|--+ | 132 + | | 133 +---------------+--------------+ 135 Figure 1: DS-Lite Coexistence scenario with Integrated AFTR 137 The AFTR needs to distinguish the traffic from two transition 138 mechanisms. The first option is to distinguish using the client's 139 source IPv4 address. Two transition mechanisms can share the same 140 tunnel endpoint address. However, this requires the network element 141 to examine every packet and may introduce significant overhead to the 142 AFTR element. The second option is to use separate tunnel endpoint 143 addresses for DS-Lite and lw4over6. This can be easily supported in 144 the network element. The second option is more practical and 145 recommended. This option requires the B4 element to discover the 146 AFTR's FQDN and lwB4 element to discover lwAFTR's FQDN. 148 In scenario 2, DS-Lite AFTR and lw4over6 lwAFTR do not co-locate in 149 the same network element (as depicted in Figure2) and are usually 150 configured with different tunnel endpoint address. Similar to 151 scenario 1 option 2, lwB4 also needs to discover a the lwAFTR's FQDN 152 rather than the AFTR's FQDN. 154 +---+---------------+-----------------| 155 + | | 156 +---------+ +------+---+ +------+-----+ | 157 | Host | | LW 4over6| | BNG | | 158 | |--| Initiator| ======-|DS-Lite AFTR| === +------------+ +-----------+ 159 +---------+ +----------+ +------+-----+ |LW 4over6 | | IPv4 | 160 | lwAFTR |---| Internet | 161 +---------+ +------+---+ +------+-----+ | | | | 162 | Host |--| DS-Lite | =======| BNG | ====+------------+ +-----------+ 163 | | | B4 | |DS-Lite AFTR| | 164 +---------+ +----------+ +------+-----+ | 165 + | | 166 +-------------------+-----------------+ 168 Figure 2: DS-Lite Coexistence scenario with Seperated AFTR 170 There are two possible solutions for an lw4over6 lwB4 to discover its 171 the lwAFTR's IPv6 address. 173 1. Subscriber Type Pre-configuration 175 In this approach, the operator must pre-provision the subscriber type 176 (e.g. Alice is lw4over6 subscriber and Bob is DS-Lite subscriber) in 177 the provisioning system, this information will be used to instruct 178 the DHCPv6 server to offer AFTR or lwAFTR to the subscriber in the 179 DHCPv6 reply. 181 +----+-----+ +----+-----+ +------+------+ +------+------+ 182 | B4 | | lwB4 | | BNG | | AAA | 183 | DS-Lite | | lw4over6 | ======-|DHCPv6 Server| | | 184 +----+-----+ +----+-----+ +------+------+ +------+------+ 185 | | dhcpv6 option64 | | 186 | |-------------------->| subscriber type | 187 | | | identification | 188 | | |--------------------->| 189 | | | lw4over6.example.com | 190 | |lw4over6.example.com |<---------------------| 191 | |<--------------------| | 192 | dhcpv6 option64 | | 193 |----------------------------------->| | 194 | | subscriber type | 195 | | identification | 196 | |--------------------->| 197 | | dslite.example.com | 198 | |<---------------------| 199 | dslite.example.com | | 200 |<-----------------------------------| | 202 Figure 3: Workflow of Subscriber Type Pre-configuration 204 This approach requires operators to pre-provision static subscriber 205 information in the provisioning system. This requires modification 206 in the provisioning system to include this new subscriber 207 information. Besides, when a subscriber migrates from DS-Lite to 208 lw4over6, this will require update in the provisioning system. 210 2. lw4over6 DHCPv6 option 212 This approach is to use a new DHCPv6 option for lw4over6 lwB4. 214 The DHCPv6 server can identify a lw4over6 subscriber by the lw4over6 215 DHCPv6 request and offer lwAFTR's FQDN (depicted in the Figure4) to 216 the lwB4 element. 218 +----+-----+ +----+-----+ +------+------+ 219 | B4 | | lwB4 | | BNG | 220 | DS-Lite | | lw4over6 | =========-|DHCPv6 Server| 221 +----+-----+ +----+-----+ +------+------+ 222 | | dhcpv6 option(lw4over6)| 223 | |----------------------->| 224 | | lw4over6.example.com | 225 | |<-----------------------| 226 | | 227 | dhcpv6 option64 | 228 |-------------------------------------->| 229 | dslite.example.com | 230 |<--------------------------------------| 232 Figure 4: Workflow of lw4over6 DHCPv6 option 234 The new DHCPv6 option enables the DHCPv6 server to offer the lwAFTR's 235 FQDN to lwB4, the provisioning system does not need to be upgraded to 236 identify the subscriber's type. At migration, operators simply 237 configure the B4 element to support NAT and this new DHCPv6 option, 238 and this will be done. 240 Therefore, a new lw4over6 DHCPv6 option is recommended. 242 4. The lwAFTR-Name DHCPv6 Option 244 The format of lwAFTR-Name option is the same as DS-Lite AFTR-Name 245 option with a new option-code. It is shown in Figure5. 247 0 1 2 3 248 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 249 +-------------------------------+-------------------------------+ 250 | OPTION_lwAFTR_NAME: X | option-len | 251 +-------------------------------+-------------------------------+ 252 | | 253 | tunnel-endpoint-name (FQDN) | 254 | | 255 +---------------------------------------------------------------+ 257 OPTION_lwAFTR_NAME: TBD 259 option-len: Length of the tunnel-endpoint-name field in 260 octets. 262 tunnel-endpoint-name: A fully qualified domain name of the lwAFTR 263 tunnel endpoint. 265 Figure 5: Format of lwAFTR-Name DHCPv6 Option Format 267 The server behavior and the client behavior is exactly the same with 268 DS-Lite AFTR-Name DHCPv6 Option ([RFC6334] section 4 and section5). 270 5. IANA Considerations 272 IANA is requested to allocate single DHCPv6 option code referencing 273 this document, delineating OPTION_lwAFTR_NAME. 275 6. Acknowledgements 277 The authors would like to thank the following individuals who have 278 participated in the drafting, review, and discussion of this memo: TO 279 BE COMPLETED 281 7. References 283 7.1. Normative References 285 [I-D.ietf-pcp-port-set] 286 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 287 and S. Perreault, "Port Control Protocol (PCP) Extension 288 for Port Set Allocation", draft-ietf-pcp-port-set-00 (work 289 in progress), March 2013. 291 [I-D.ietf-softwire-lw4over6] 292 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 293 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 294 Architecture", draft-ietf-softwire-lw4over6-00 (work in 295 progress), April 2013. 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC3484] Draves, R., "Default Address Selection for Internet 301 Protocol version 6 (IPv6)", RFC 3484, February 2003. 303 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 304 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 305 RFC 6334, August 2011. 307 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 308 Selkirk, "Port Control Protocol (PCP)", RFC 6887, 309 April 2013. 311 7.2. Informative References 313 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 314 Stack Lite Broadband Deployments Following IPv4 315 Exhaustion", RFC 6333, August 2011. 317 Authors' Addresses 319 Chongfeng Xie 320 China Telecom 321 P.R.China 323 Phone: 86 10 58552116 324 Email: xiechf@ctbri.com.cn 326 Qiong Sun 327 China Telecom 328 P.R.China 330 Phone: 86 10 58552936 331 Email: sunqiong@ctbri.com.cn 333 Yiu L. Lee 334 Comcast 335 One Comcast Center 336 Philadelphia, PA 19103 337 USA 339 Email: yiu_lee@cable.comcast.com 341 Tina Tsou 342 Huawei Technologies (USA) 343 2330 Central Expressway 344 Santa Clara, CA 95050 345 USA 347 Phone: +1 408 330 4424 348 Email: Tina.Tsou.Zouting@huawei.com 349 Yuchi Chen 350 Tsinghua University 351 Department of Computer Science, Tsinghua University 352 Beijing 100084 353 P.R.China 355 Phone: +86-10-6278-5822 356 Email: peng-wu@foxmail.com