idnits 2.17.1 draft-liu-softwire-lw4over6-dynamic-provisioning-02.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 221: '... As stated in [RFC7596], the lwAFTR MUST synchronize the binding...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2016) is 2857 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3315' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC6887' is defined on line 357, 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: 2 errors (**), 0 flaws (~~), 5 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: December 31, 2016 Tsinghua University 6 I. Farrer 7 Deutsche Telekom AG 8 June 29, 2016 10 Dynamic IPv4 Provisioning for Lightweight 4over6 11 draft-liu-softwire-lw4over6-dynamic-provisioning-02 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 December 31, 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. Dynamic Provisioning Model . . . . . . . . . . . . . . . . . 4 60 3.1. Flow 1: lwB4's IPv6 Addressing and DHCPv6 Configuration . 4 61 3.2. Flow 2: DHCP 4o6 Function . . . . . . . . . . . . . . . . 5 62 3.3. Flow 3: lwAFTR Binding Table Maintainence . . . . . . . . 5 63 3.3.1. Flow 3a: Binding Table Maintenance for Co-located 64 lwAFTR/DHCP 4o6 Functions . . . . . . . . . . . 5 65 3.3.2. Flow 3b: Binding Table Maintenance for Distributed 66 lwAFTR/DHCP 4o6 Functions . . . . . . . . . . . 6 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 4.1. Data Retention Requirements . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 6.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Lightweight 4over6 [RFC7596] (lw4o6) provides IPv4 access over an 78 IPv6 network with a hub-and-spoke softwire architecture. In 79 Lightweight 4over6, each Lightweight B4 (lwB4) is assigned a full, or 80 shared (port-restricted) IPv4 address to be used for IPv4 81 communication. Provisioning the lwB4 with its IPv4 address, port set 82 and other parameters necessary for building the softwire is a core 83 function of the lw4o6 control plane. 85 [RFC7596] describes the use of DHCPv6 for deterministic IPv4 86 provisioning. The IPv4 address, port set ID (PSID) and address of 87 the lwAFTR are carried in DHCPv6 options defined in [RFC7598]. 89 However, the deterministic provisioning of the IPv4 parameters 90 imposes restrictions on the deployment: 92 o The IPv4 address' life time is bound to the client's IPv6 tunnel 93 endpoint life time 95 o The tunnel must be initiated from a fixed and predictable /64 96 prefix in the home network topology 98 o The IPv4 address and PSID need to be embedded into the IID of the 99 clients' /128 IPv6 address 101 o IPv4 address resources are permanently reserved for a client 102 whether it is active or not. This results in less efficient 103 public IPv4 address usage 105 This document describes how lw4o6 uses DHCPv4 over DHCPv6 to achieve 106 dynamic IPv4 address provisioning. The main advantages of using a 107 dynamic provisioning model over a deterministic provisioning model 108 are as follows: 110 o No inherent restrictions on the IPv6 source address within the 111 customer internal network that the client uses for sourcing its 112 tunneled traffic 114 o The lifetimes of IPv6 and IPv4 addresses are decoupled, allowing 115 for more flexibility in the service provider's addressing policy 117 o Inactive clients' addresses can be released/reclaimed for 118 allocation to active clients, so more efficient address usage is 119 possible 121 Since DHCPv4 over IPv4 cannot be used natively in a pure IPv6 122 network, DHCPv4 over DHCPv6 (DHCP 4o6) [RFC7341] allows DHCPv4 123 messages to be trasported over a pure IPv6 network by encapsulating 124 DHCPv4 messages into specific DHCPv6 options and messages. 126 Note that the dynamic provisioning decouples the IPv6 and IPv4 127 addresses, the binding info required by lwAFTR turns to be an 128 ayschronous combiantion of (restricted) IPv4 address and IPv6 129 address. [I-D.fsc-softwire-dhcp4o6-saddr-opt] defines a DHCP 4o6 130 based mechanism for the lwB4 to inform the server of its binding 131 between dynamically allocated IPv4 address and Port Set ID and the 132 IPv6 address that it will use for accessing IPv4-over-IPv6 services 134 The architecture which is described in this document can be 135 implemented with or without the sharing of IPv4 addresses between 136 multiple clients. If IPv4 address sharing is required, then 137 [RFC7618] describes the necessary extensions to the DHCPv4 server and 138 client provisioning for the allocation and lease management of shared 139 IPv4 addresses. 141 2. Terminology 143 Terminology defined in [RFC7341] and [RFC7596] is used extensively 144 throughout this document. 146 Determinstic provisioning: Lightweight B4 provisioning with DHCPv6 as 147 described in section 5.1 of [RFC7596]. The IPv4 address, restricted 148 port set and the address of lwAFTR are carried in DHCPv6 options 149 defined in [RFC7598]. 151 Dynamic provisioning: Lightweight B4 provisioning with DHCPv4 over 152 DHCPv6 as described in this document. The IPv4 address and 153 rescricted port set are allocated through DHCP 4o6 transport as 154 defined in [RFC7341]. The allocation of lwAFTR's IPv6 address is 155 descirbed in [I-D.fsc-softwire-dhcp4o6-saddr-opt]. 157 3. Dynamic Provisioning Model 159 As shown in Figure 1, the dynamic provisioning model consists of four 160 functional elements: lwB4, lwAFTR, DHCPv6 Server and DHCP 4o6 Server. 161 Note that these elements are not necessarily separate devices, one or 162 more functional elements could be located on a single device. One 163 existing example of this is the co-location of the DHCP 4o6 Server 164 and lwAFTR as a single gateway device. The differences in the 165 message flow from this co-location are also described below. 167 ________ __________ 168 | | | | 169 | DHCPv6 | | DHCP 4o6 | 170 | Server | | Server | 171 |________| |__________| 172 ^ / \ 173 1 | 2 / \ 3a/b 174 ___v____ / \ ________ 175 | | | | 176 | lwB4 |<---------------->| lwAFTR | 177 |________| Data Plane |________| 179 The numbers corresponding to each of the provisioning flows are 180 described in more detail below. 182 Figure 1: Dynamic lw4o6 Provisioning Model 184 3.1. Flow 1: lwB4's IPv6 Addressing and DHCPv6 Configuration 186 Before attempting the DHCP 4o6 configuration process to obtain IPv4 187 configuration, the lwB4 requires an IPv6 address of a suitable scope 188 to allow communication with the lwAFTR (e.g. a link-local address 189 cannot be used). This IPv6 address can be configured using any 190 applicable method (e.g. SLAAC, DHCPv6, etc.). 192 To enable DHCPv4 over DHCPv6 transport, the lwB4 needs to perform 193 DHCPv6 to retrieve the DHCP 4o6 server's IPv6 address. The option 194 code OPTION_DHCP4_O_DHCP6_SERVER (88) is included in the client's 195 ORO. The DHCPv6 server responds the DHCP 4o6 server's IPv6 address 196 by carrying the addresses in DHCP 4o6 Server Address option as 197 defined in [RFC7341]. 199 3.2. Flow 2: DHCP 4o6 Function 201 Once the lwB4 has acquired the IPv6 address of the DHCP 4o6 server, 202 stateful configuration using DHCP 4o6 is performed to obtain an IPv4 203 address and (optionally) a port set. The lwB4 sends a DHCPv4 204 DISCOVER message in a DHCPv4-query Message to the DHCP 4o6 server(s) 205 to activate the DHCP 4o6 transport. To obtain a shared IPv4 address, 206 the lwB4 also has to include Parameter Request List option with the 207 option code OPTION_V4_PORTPARAMS (159) as described in [RFC7618]. 209 To obtain the IPv6 address of lwAFTR and inform the DHCP4o6 server of 210 the lwB4's IPv6 tunnle source address, the message flow described in 211 section 5 of [I-D.fsc-softwire-dhcp4o6-saddr-opt] is followed by the 212 lwB4. 214 Once successfully completed, the client has been provisioned with the 215 IPv6 address of the lwAFTR, an IPv4 address and (optionally) a range 216 of source ports. The server has the /128 IPv6 address that the 217 client will use its tunnel source associated with the IPv4 lease. 219 3.3. Flow 3: lwAFTR Binding Table Maintainence 221 As stated in [RFC7596], the lwAFTR MUST synchronize the binding 222 information with the port-restricted address provisioning process. 223 In the dynamic provisioning model described in this document, once 224 the lwB4's provisioning process is completed and the DHCP 4o6 server 225 holds the client's /128 IPv6 tunnel endpoint address, this binding 226 information can be syncronized with the lwAFTR. The method for this 227 synchronization is dependent on whether the DHCP 4o6 and lwAFTR 228 functions are co-located on the same physical host. 230 3.3.1. Flow 3a: Binding Table Maintenance for Co-located lwAFTR/DHCP 231 4o6 Functions 233 Here, the lwAFTR maintains its binding table as per section 6.1 of 234 [RFC7596] and is synchronized with DHCP 4o6 process. The following 235 DHCP 4o6 messages trigger binding table modification: 237 DHCPACK: Generated by the DHCP 4o6 server, triggers lwAFTR to add a 238 new entry or modify an existing entry. 240 DHCPRELEASE: Generated by lwB4, triggers lwAFTR to delete an 241 existing entry. 243 When the DHCP 4o6 server generates a DHCPACK message, information 244 about the new lease including the client's IPv6 tunnel endpoint 245 address and IPv4 address/PSID tuple is sent to the lwAFTR process. 246 The lwAFTR performs a check that this new binding does not match an 247 existing binding (both the v6 and v4 information must be checked 248 independently to ensure no conflicts). If no conflicts are found the 249 lwAFTR creates a new binding table entry for the client. 251 If there an existing entry is found, the lwAFTR updates the IPv6 252 address and lifetime fields of the entry. 254 When the DHCP 4o6 server receives a DHCPRELEASE message, the lwAFTR 255 looks up the binding table using the lwB4's IPv6 address, IPv4 256 address and PSID as index. The lwAFTR deletes the entry either by 257 removing it from the binding table or by marking the lifetime field 258 with an invalid value (e.g. 0). 260 3.3.2. Flow 3b: Binding Table Maintenance for Distributed lwAFTR/DHCP 261 4o6 Functions 263 With this architecture, NETCONF [RFC6241] is used for syncronising 264 client DHCP 4o6 provisioning and the lwAFTR binding table. A YANG 265 model for lw4o6 is defined in [I-D.sun-softwire-yang]. In this 266 deployment model, the DHCP 4o6 server and lwAFTR also implements a 267 NETCONF server. When an IPv4 leasing event occurs (DHCPACK/ 268 DHCPRELEASE messages, or an active lease expiring), the DHCP 4o6 269 server informs the operator's centralised configuration database of 270 the change. 272 The operator's configuration database will then use NETCONF to update 273 the lwAFTR of the relevant change by adding or removing the binding 274 table entry which matches he DHCP 4o6 server's IPv4 address lease. 276 4. Security Considerations 278 Security considerations in [RFC7596] and [RFC7341] are also relevant 279 here. 281 The DHCP message triggered binding table maintenance may be used by 282 an attacker to send fake DHCP messages to lwAFTR. The operator 283 network should deploy [RFC2827] to prevent this kind of attack. 285 4.1. Data Retention Requirements 287 In some countries, regulations require a service providers to retain 288 the necessary information to link IP allocatoin information to a 289 specific customer at a specific point in time. 291 With a deterministic provisioning model, any individual client will 292 always receive a pre-determined set of IPv4 provisioning 293 requirements. In this scenario, the logging requirement may be met 294 by retaining information on how the DHCPv6 server has been pre- 295 provisioned, with timestamp information on when changes to the pre- 296 provisioning have come into effect. 298 The dynamic provisioning model that is described in this document 299 brings an additional logging requirement to the service provider: The 300 retention logs holding allocated IPv4 address and ports, the 301 associated IPv6 tunnel endpoint and timestamps marking the start and 302 end of the lease. This is a higher logging overheard than 303 deterministic provisioning, but is in line with the amount of logging 304 that service providers currently have. 306 5. IANA Considerations 308 This document does not include an IANA request. 310 6. References 312 6.1. Normative References 314 [I-D.fsc-softwire-dhcp4o6-saddr-opt] 315 Farrer, I., Sun, Q., and Y. Cui, "DHCPv4 over DHCPv6 316 Source Address Option", draft-fsc-softwire-dhcp4o6-saddr- 317 opt-04 (work in progress), November 2015. 319 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 320 Defeating Denial of Service Attacks which employ IP Source 321 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 322 May 2000, . 324 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 325 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 326 RFC 7341, DOI 10.17487/RFC7341, August 2014, 327 . 329 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 330 Farrer, "Lightweight 4over6: An Extension to the Dual- 331 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 332 July 2015, . 334 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 335 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 336 RFC 7618, DOI 10.17487/RFC7618, August 2015, 337 . 339 6.2. Informative References 341 [I-D.sun-softwire-yang] 342 Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M., and 343 R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire", 344 draft-sun-softwire-yang-04 (work in progress), October 345 2015. 347 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 348 C., and M. Carney, "Dynamic Host Configuration Protocol 349 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 350 2003, . 352 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 353 and A. Bierman, Ed., "Network Configuration Protocol 354 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 355 . 357 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 358 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 359 DOI 10.17487/RFC6887, April 2013, 360 . 362 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 363 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 364 Configuration of Softwire Address and Port-Mapped 365 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 366 . 368 Authors' Addresses 370 Cong Liu 371 Tsinghua University 372 Department of Computer Science, Tsinghua University 373 Beijing 100084 374 P.R.China 376 Phone: +86-10-6278-5822 377 Email: cong-liu13@mails.tsinghua.edu.cn 378 Qi Sun 379 Tsinghua University 380 Department of Computer Science, Tsinghua University 381 Beijing 100084 382 P.R.China 384 Phone: +86-10-6278-5822 385 Email: sunqi@csnet1.cs.tsinghua.edu.cn 387 Jianping Wu 388 Tsinghua University 389 Department of Computer Science, Tsinghua University 390 Beijing 100084 391 P.R.China 393 Phone: +86-10-6278-5983 394 Email: jianping@cernet.edu.cn 396 Ian Farrer 397 Deutsche Telekom AG 398 CTO-ATI,Landgrabenweg 151 399 Bonn, NRW 53227 400 Germany 402 Email: ian.farrer@telekom.de