idnits 2.17.1 draft-liu-softwire-lw4over6-dynamic-provisioning-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7341], [RFC7596]), 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 date (March 21, 2016) is 2958 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6887' is defined on line 338, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-fsc-softwire-dhcp4o6-saddr-opt-04 == Outdated reference: A later version (-05) exists of draft-sun-softwire-yang-04 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Liu 3 Internet-Draft Q. Sun 4 Intended status: Informational J. Wu 5 Expires: September 22, 2016 Tsinghua University 6 I. Farrer 7 Deutsche Telekom AG 8 March 21, 2016 10 Dynamic IPv4 Provisioning for Lightweight 4over6 11 draft-liu-softwire-lw4over6-dynamic-provisioning-01 13 Abstract 15 Lightweight 4over6 [RFC7596] is an IPv4 over IPv6 hub-and-spoke 16 mechanism that provides overlay IPv4 services in an IPv6-only access 17 network. It uses a deterministic, DHCPv6 based method for the 18 provisioning of IPv4 addresses and port sets to customer CE devices. 19 This document describes how existing specifications can be used for 20 the dynamic IPv4 provisioning of Lightweight 4over6, based on DHCPv4 21 over DHCPv6 [RFC7341]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 22, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 60 4. Lightweight4over6 Dynamic Provisioning Process . . . . . . . 5 61 4.1. Client IPv6 Addressing . . . . . . . . . . . . . . . . . 5 62 4.2. DHCPv6 Configuration . . . . . . . . . . . . . . . . . . 5 63 4.3. DHCPv4 over DHCPv6 Function . . . . . . . . . . . . . . . 5 64 4.4. lwAFTR Binding Table Maintenance . . . . . . . . . . . . 5 65 4.4.1. Co-located lwAFTR/DHCP4o6 Binding Table Maintenance . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 5.1. Data Retention Requirements . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Lightweight 4over6 [RFC7596] provides IPv4 access over an IPv6 77 network in hub-and-spoke softwire architecture. In Lightweight 78 4over6, each Lightweight B4 (lwB4) is assigned a full, or shared 79 (port-restricted) IPv4 address to be used for IPv4 communication. 80 Provisioning the lwB4 with its IPv4 address, port set and other 81 parameters necessary for building the softwire is the core function 82 of the Lightweight 4over6 control plane. 84 [RFC7596] describes the use of DHCPv6 for deterministic IPv4 85 provisioning. The IPv4 address, port set ID (PSID) and address of 86 the lwAFTR are carried in DHCPv6 options defined in [RFC7598]. 88 However, the deterministic provisioning of the IPv4 parameters 89 imposes restrictions on the deployment: 91 o The IPv4 address' life time is bound to the client's IPv6 tunnel 92 endpoint life time 94 o The tunnel must be initiated from a fixed and predictable /64 95 prefix in the home network topology 97 o The IPv4 address and PSID need to be embedded into the IID of the 98 clients' /128 IPv6 address 100 o IPv4 address resources are permanently reserved for a client 101 whether it is active or not. This results in less efficient 102 public IPv4 address usage 104 This document describes the deployment of Lightweight 4over6 using 105 DHCPv4 over DHCPv6 for dynamic IPv4 address provisioning. The main 106 advantages of using a dynamic provisioning model over a deterministic 107 model are as follows: 109 o No inherent restrictions on the IPv6 source address within the 110 customer internal network that the client uses for sourcing its 111 tunneled traffic 113 o The lifetimes of IPv6 and IPv4 addresses are decoupled, allowing 114 for more flexibility in the service provider's addressing policy 116 o Inactive clients' addresses can be released/reclaimed for 117 allocation to active clients, so more efficient address usage is 118 possible 120 Since DHCPv4 over IPv4 cannot be used natively in a single stack IPv6 121 network, DHCPv4 over DHCPv6 (DHCP4o6) [RFC7341] allows DHCPv4 122 functionality to be trasported over a pure in IPv6 network by placing 123 DHCPv4 messages within DHCPv6 messages. 125 [I-D.fsc-softwire-dhcp4o6-saddr-opt] defines a DHCP4o6 based 126 mechanism for the lwB4 to inform the server of its IPv6 tunnel source 127 address. 129 The architecture which is described in this document can be 130 implemented with or without the sharing of IPv4 addresses between 131 multiple clients. If IPv4 address sharing is required, then 132 [RFC7618] describes the changes necessary extensions to the DHCPv4 133 server and client provisioning for the allocation and lease 134 management of shared IPv4 addresses. 136 2. Terminology 138 Terminology defined in [RFC7341] and [RFC7596] is used extensively 139 throughout this document. 141 Unless stated otherwise, the term "lwB4" should be understood to mean 142 a stateful lwB4 using DHCP4o6 for dynamic IPv4 provisioning. 144 3. Architecture Overview 146 There are four functional elements which make up the architecture. 147 Although these are shown as being seperate entities, it is possibile 148 that one or more of the operator side functions might be performed by 149 a single device. 151 ________ __________ 152 | | | | 153 | DHCPv6 | | DHCP4o6 | 154 | Server | | Server | 155 |________| |__________| 156 ^ / \ 157 1 | 2 / \ 3 158 ___v____ / \ ________ 159 | | | | 160 | lwB4 |<---------------->| lwAFTR | 161 |________| Data Plane |________| 163 The numbers in each of the provisioning flows are described in more 164 detail below. 166 Figure 1: Dynamic lw4o6 Provisioning Model 168 The process for provisioning Lightweight 4over6 using DHCP4o6 is as 169 follows: 171 1. The lwB4 uses DHCPv6[RFC3315] to obtain its basic configuration. 172 OPTION_DHCP4_O_DHCP6_SERVER (88) is included in the client's ORO. 173 The IPv6 address of at least one DHCP4o6 server is given in the 174 response. 176 2. The client sends a DHCPv4 DISCOVER message in a DHCP4o6 message 177 to the DHCP4o6 server(s). The rest of the message flow proceeds 178 as per Section 5 of [I-D.fsc-softwire-dhcp4o6-saddr-opt]. The 179 result is that the client is provisioned with the Ipv6 address of 180 the lwAFTR, an IPv4 address and (optionally) a range of source 181 ports. The server has the /128 IPv6 address that the client will 182 use its tunnel source associated with the IPv4 lease. 184 3. lwAFTR binding table maintenance is achieved by using NETCONF 185 [RFC6241]. The YANG model for lw4o6 is defined in 186 [I-D.sun-softwire-yang]. 188 4. Lightweight4over6 Dynamic Provisioning Process 190 This section describes the dynamic provisioning process of 191 Lightweight 4over6 in more detail. 193 4.1. Client IPv6 Addressing 195 Before attempting the DHCP4o6 configuration process to obtain IPv4 196 configuration, the lwB4 needs to have an IPv6 address of a suitable 197 scope to allow communication with the lwAFTR (e.g. a link-local 198 address cannot be used). There are no restrictions on how the 199 client's IPv6 address is provisioned, (e.g. SLAAC, DHCPv6 or some 200 other mechanisms). 202 4.2. DHCPv6 Configuration 204 The initial configuration step is for the lwB4 to perform DHCPv6 to 205 retrieve the DHCP 4o6 server's IPv6 address. The DHCPv6 server 206 provides the DHCP 4o6 server's IPv6 address by 207 OPTION_DHCP4_O_DHCP6_SERVER as defined in [RFC7341]. 209 4.3. DHCPv4 over DHCPv6 Function 211 Once the lwB4 has acquired the IPv6 address of the DHCP4o6 server, 212 stateful configuration using DHCP4o6 is performed to obtain an IPv4 213 address and port set. The PSID is conveyed using DCHPv4 214 OPTION_V4_PORTPARAMS (159) as decribed in [RFC7618]. The lwB4 215 includes one of its active IPv6 addresses as the IPv6 tunnel source 216 address in this message flow with the DHCP 4o6 server, and receives 217 the lwAFTR's tunnel address through DHCP4o6, as described in section 218 4 of [I-D.fsc-softwire-dhcp4o6-saddr-opt]. 220 4.4. lwAFTR Binding Table Maintenance 222 In figure 1 above, the lwAFTR is not co-located with the DHCP 4o6 223 server. With this architecture, NETCONF [RFC6241] is used for 224 syncronising client DHCP4o6 provisioning and the lwAFTR binding 225 table. A YANG model for lw4o6 is defined in [I-D.sun-softwire-yang]. 226 In this deployment model, the DHCP4o6 server and lwAFTR also 227 implements a NETCONF server. When an IPv4 leasing event occurs (e.g. 228 DHCPACK/DHCPRELEASE messages), the DHCP4o6 server informs the 229 operator's centralised configuration database of the change. 231 The operator's configuration database will then use NETCONF to update 232 the lwAFTR of the relevant change by adding or removing the binding 233 table entry which matches the DHCP4o6 server's IPv4 address lease. 235 4.4.1. Co-located lwAFTR/DHCP4o6 Binding Table Maintenance 237 In this deployment scenario, the DHCP4o6 and lwAFTR functions are 238 both active on the same device. Here, the lwAFTR maintains its 239 binding table as per section 6.1 of [RFC7596] and is synchronized 240 with DHCP4o6 process. The following DHCP4o6 messages trigger binding 241 table modification: 243 DHCPACK: Generated by the DHCP4o6 server, triggers lwAFTR to add a 244 new entry or modify an existing entry. 246 DHCPRELEASE: Generated by lwB4, triggers lwAFTR to delete an 247 existing entry. 249 When the DHCP4o6 server generates a DHCPACK message, the lwAFTR looks 250 up the binding table using the lwB4's IPv4 address and PSID as index. 251 If there is an existing entry found, the lwAFTR updates the IPv6 252 address and lifetime fields of the entry; otherwise the lwAFTR 253 creates a new entry accordingly. When the DHCP4o6 server receives a 254 DHCPRELEASE message , the lwAFTR looks up the binding table using the 255 lwB4's IPv6 address, IPv4 address and PSID as index. The lwAFTR 256 deletes the entry either by removing it from the binding table or by 257 marking the lifetime field with an invalid value (e.g. 0). 259 5. Security Considerations 261 Security considerations in [RFC7596] and [RFC7341] are also relevant 262 here. 264 The DHCP message triggered binding table maintenance may be used by 265 an attacker to send fake DHCP messages to lwAFTR. The operator 266 network should deploy [RFC2827] to prevent this kind of attack. 268 5.1. Data Retention Requirements 270 In some countries, regulations require a service providers to retain 271 the necessary information to link IP information to a specific 272 customer. With a deterministic provisioning model, any individual 273 client will always receive a pre-determined set of IPv4 provisioning 274 requirements. In this scenario, the logging requirement may be met 275 by retaining information on how the DHCPv6 server has been pre- 276 provisioned, with timestamp information on when changes to the pre- 277 provisioning have come into effect. 279 The dynamic provisioning model that is described in this document 280 brings an additional logging requirement to the service provider: The 281 retention logs holding allocated IPv4 address and ports, the 282 associated IPv6 tunnel endpoint and timestamps marking the start and 283 end of the lease. This is a higher logging overheard than 284 deterministic provisioning, but is in line with the amount of logging 285 that service providers currently have. 287 6. IANA Considerations 289 This document does not include an IANA request. 291 7. References 293 7.1. Normative References 295 [I-D.fsc-softwire-dhcp4o6-saddr-opt] 296 Farrer, I., Sun, Q., and Y. Cui, "DHCPv4 over DHCPv6 297 Source Address Option", draft-fsc-softwire-dhcp4o6-saddr- 298 opt-04 (work in progress), November 2015. 300 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 301 Defeating Denial of Service Attacks which employ IP Source 302 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 303 May 2000, . 305 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 306 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 307 RFC 7341, DOI 10.17487/RFC7341, August 2014, 308 . 310 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 311 Farrer, "Lightweight 4over6: An Extension to the Dual- 312 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 313 July 2015, . 315 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 316 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 317 RFC 7618, DOI 10.17487/RFC7618, August 2015, 318 . 320 7.2. Informative References 322 [I-D.sun-softwire-yang] 323 Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M., and 324 R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire", 325 draft-sun-softwire-yang-04 (work in progress), October 326 2015. 328 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 329 C., and M. Carney, "Dynamic Host Configuration Protocol 330 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 331 2003, . 333 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 334 and A. Bierman, Ed., "Network Configuration Protocol 335 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 336 . 338 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 339 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 340 DOI 10.17487/RFC6887, April 2013, 341 . 343 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 344 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 345 Configuration of Softwire Address and Port-Mapped 346 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 347 . 349 Authors' Addresses 351 Cong Liu 352 Tsinghua University 353 Department of Computer Science, Tsinghua University 354 Beijing 100084 355 P.R.China 357 Phone: +86-10-6278-5822 358 Email: cong-liu13@mails.tsinghua.edu.cn 360 Qi Sun 361 Tsinghua University 362 Department of Computer Science, Tsinghua University 363 Beijing 100084 364 P.R.China 366 Phone: +86-10-6278-5822 367 Email: sunqi@csnet1.cs.tsinghua.edu.cn 368 Jianping Wu 369 Tsinghua University 370 Department of Computer Science, Tsinghua University 371 Beijing 100084 372 P.R.China 374 Phone: +86-10-6278-5983 375 Email: jianping@cernet.edu.cn 377 Ian Farrer 378 Deutsche Telekom AG 379 CTO-ATI,Landgrabenweg 151 380 Bonn, NRW 53227 381 Germany 383 Email: ian.farrer@telekom.de