Internet Engineering Task Force K. Fleischhauer, Ed. Internet-Draft O. Bonness Intended status: Informational Deutsche Telekom AG Expires: September 8, 2011 March 07, 2011 draft-fleischhauer-ipv4-addr-saving-00 On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios Abstract Today the Dual-Stack approach is the most straightforward and most common way for introducing IPv6 into existing systems and networks. However a typical drawback of implementing Dual-Stack is that each node will still require at least one IPv4 address. Hence, solely deploying Dual-Stack does not provide a sufficient solution to the IPv4 address exhaustion problem. Assuming a situation where most of the IP communication (e.g. always-on, VoIP etc.) can be provided via IPv6, the usage of IPv4 addresses can significantly be reduced and the unused IPv4 addresses can under certain circumstances be returned to the IPv4 address pool of the service provider. New Dual-Stack enabled services can be introduced without increasing the IPv4 address demand, when IPv6 will be the preferred network layer protocol. This document describes such a solution in a Dual-Stack PPP session network scenario and explains the protocol mechanisms which are used. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 8, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Fleischhauer & Bonness Expires September 8, 2011 [Page 1] Internet-Draft draft-fleischhauer-ipv4-addr-saving-00 March 2011 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Fleischhauer & Bonness Expires September 8, 2011 [Page 2] Internet-Draft draft-fleischhauer-ipv4-addr-saving-00 March 2011 Table of Contents 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Problem Statement and Purpose of IPv4 address efficiency . . . 4 2.1. Communication in a PPP Dual-Stack environment . . . . . . 4 2.2. The advantage of the dynamic address assigning feature . . 5 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Assigning IPv4 address parameter after established PPP and IPv6 connectivity . . . . . . . . . . . . . . . . . . 7 3.2. Releasing unused IPv4 address parameter . . . . . . . . . 8 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Workplan . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Fleischhauer & Bonness Expires September 8, 2011 [Page 3] Internet-Draft draft-fleischhauer-ipv4-addr-saving-00 March 2011 1. Abstract The Dual-Stack approach as defined in [RFC4213] provides the most straightforward and most common way for introducing IPv6 [RFC2460] into existing systems and networks. However a typical drawback of the Dual-Stack approach is that each network node will still require at least one IPv4 [RFC0791] address. Assuming a situation where most of the IP communication (e.g. always-on, VoIP etc.) can be provided via IPv6, the usage of IPv4 addresses can be reduced significantly and the unused IPv4 addresses may be returned to IPv4 address pool of the provider. This document describes how such a solution can be realised in a Dual-Stack PPP session scenario and details the protocol mechanisms of the solution which are also thought as contribution to [BBF-WT-242]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 2. Problem Statement and Purpose of IPv4 address efficiency The Broadband Forum describes in [BBF-TR-187] a target IPv4/IPv6 Dual-Stack Architecture (assuming native implementation of IPv6). TR-187 builds on the capabilities of existing protocols such as Point-to-Point Protocol (PPP) [RFC1332] and Layer 2 Tunneling Protocol (L2TP) [RFC2661] to provide IPv6 service in addition to today's IPv4 service. These protocols allow the parallel usage of IPv4 and IPv6 within a single PPP respectively L2TP session. Because of the potential parallel usage of IPv4 and IPv6 within such a Dual- Stack PPP scenario an IPv4 address is always provisioned, also in the case where most of the communication is transported over IPv6. This document extends the sketched Dual-Stack deployment scenario for PPP and L2TPv2 with an mechanism that allows a temporary assignment and a release of an unused IPv4 address within such a Dual-Stack capable PPP session scenario. The IPv4 address may also only be provided on- demand later on, after initiating the Dual-Stack PPP session with an IPv6 address only. 2.1. Communication in a PPP Dual-Stack environment Assuming a Dual-Stack network access via PPP sessions, end devices can in general communicate via IPv4 and/or IPv6 transport, depending of their own and their IP communication partners capabilities. The actual usage of IPv4 or IPv6 or both protocols depends on the capabilities of the IP communication endpoints (e.g. protocol stack, Fleischhauer & Bonness Expires September 8, 2011 [Page 4] Internet-Draft draft-fleischhauer-ipv4-addr-saving-00 March 2011 applications, configuration of the preferences etc.), the network itself and also of the used communication services (like e.g. VoIP). The later two are mainly in responsibility of the network and service provider. The approach, sketched in this document, is based on the assumption that the customer starts a Dual-Stack PPP session in "IPv6-only" mode and "adds" IPv4 later on only in the case that applications or services explicitly request IPv4 connectivity. When IPv4 connectivity is not needed during the whole time of PPP network connectivity than a continuous provisioning of a global IPv4 address to the customer device (e.g. end system, Home Gateway etc.) is not necessary. Therefore mechanisms are needed in order to provision and release IPv4 addresses for Dual-Stack PPP sessions dynamically. +-------------------------------------------------------------------+ | This figure will show in draft version 01 the architecture for the| | Dual-Stack PPP scenario. | | | +-------------------------------------------------------------------+ Figure 1: PPP Dual-Stack architecture The goal of the solution sketched in this document, is to limit and decrease the IPv4 address pool size of the PPP network access provider. Assuming that always-on services are reachable via IPv6, a Dual-Stack capable PPP connected device should per default request IPv4 address parameter only on demand, when the need for establishing IPv4 connectivity has been detected and IPv4 traffic towards the PPP WAN interface is intended. As already described above it is sufficient, when initially only IPv6 address parameters are provisioned to the PPP customer endpoint (e.g. end systems, Home Gateway). This means that this customer device does not initially start a complete Dual-Stack PPP session but an "IPv6 only" PPP session. The IPv4 part of the complete Dual-Stack is initiated later on only in the case that IPv4 connectivity is explicitly requested. 2.2. The advantage of the dynamic address assigning feature This approach is based on the assumption that the customer initiates a PPP session based on IPv6 and uses IPv4 only if applications or services request explicit IPv4 connectivity. An IPv4 address can therefore provided sequentially to different customers during the runtime of their PPP connectivity. This enables a smooth migration from IPv4 to IPv6 in comparison to other IPv4-IPv6 migration approaches (e.g. NAT in the service provider network). The customer will get global IPv4 connectivity only in the case when it is really needed and will not get an IPv4 address in each case per default when a Dual-Stack PPP session is initiated. When IPv4 connectivity is not Fleischhauer & Bonness Expires September 8, 2011 [Page 5] Internet-Draft draft-fleischhauer-ipv4-addr-saving-00 March 2011 needed during the whole time of PPP network connectivity than a (continuous) provisioning a global IPv4 address to the HG is not necessary. Therefore a provisioning of global IPv4 address can be done on-demand and dynamically during the PPP session. The goal of this solution approach is to limit and decrease the pool size for global IPv4 addresses at the service provider. A similar effect in limiting and decreasing the IPv4 address demand could also be achieved by using separate PPP sessions for IPv4 and IPv6. But in that case the following problems occur: o For each additional PPP session additional AAA parameter has to be created and used which leads to an extension on AAA domains and processes. o Each additional PPP session will require additional resources on the PPP endpoints as well devices which act as an PPP intermediate agent. o Accounting and controlling of traffic classes on an access line or customer base will be impeded. Because of these reasons the introduction of IPv6 as additional network layer protocol on a access line with a additional PPP session is not recommended. 3. Specification As defined in RFC 2661 [RFC2661] PPP and L2TP provide the following main functionalities: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. (Optional) Authentication Protocol for one or both peers. 4. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. For provisioning of IPv4 or IPv6 communication parameter (e.g. addresses, DNS resolver) as network-layer protocols only the NCPs Internet Protocol (Version 4) Control Protocol (IPCP) RFC 1332 [RFC1332] and Internet Protocol (Version 6) Control Protocol (IPV6CP) RFC 2472 [RFC2472] are used. Whereas IPCP is responsible for Fleischhauer & Bonness Expires September 8, 2011 [Page 6] Internet-Draft draft-fleischhauer-ipv4-addr-saving-00 March 2011 configuring, enabling, and disabling the IPv4 protocol modules on both ends of the point-to-point link, IPV6CP is responsible for configuring, enabling, and disabling the IPv6 protocol modules on both ends of the point-to-point link. Once one of both network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. Both NCP protocol mechanisms are independent from each other (see also requirement WLL-3 in [I-D.ietf-v6ops-ipv6-cpe-router]). An implementation wishing to close a dedicated NCP connection (e.g. IPCP or IPv6CP) SHOULD transmit a Terminate-Request to the peer. Upon reception of a Terminate-Request, a Terminate-Ack MUST be transmitted to the sender of the Terminate-Request. 3.1. Assigning IPv4 address parameter after established PPP and IPv6 connectivity A PPP implementation wishing to open a connection MUST transmit a NCP Configure-Request to the peer. If every Configuration Option received in a Configure-Request is recognizable and all values are acceptable, then the implementation MUST transmit a Configure-Ack to the sender of the NCP Configure-Request. Applied to the above sketched Dual-Stack PPP session use case the configuration and enabling of the IPv6 protocol module can be done immediately after a successful LCP data link configuration (and maybe successful authentication). Separately from that the IPv4 protocol module can be configured and enabled using IPCP. However this SHALL only be done in the case that an IPv4 connectivity demand has been detected on the PPP customer end system or HG. In this case the end system or HG send a IPCP Configure-Request to the BRAS. The BRAS will request the IPv4 connectivity parameter (e.g. IPv4 address, DNS resolver address) from a local (e.g. within the BRAS) or remote (e.g. via RADIUS/ DIAMETER) database and transmit these parameter within a Configure- Ack message to the PPP peer (e.g. end system, HG). +-------------------------------------------------------------------+ | This figure will show in draft version 01 the message flow for | | assign IPv4 address parameter after PPP and IPv6 | | connectivity is established. | +-------------------------------------------------------------------+ Figure 2: Message flow for assigning IPv4 address parameter Fleischhauer & Bonness Expires September 8, 2011 [Page 7] Internet-Draft draft-fleischhauer-ipv4-addr-saving-00 March 2011 3.2. Releasing unused IPv4 address parameter An implementation wishing to close a dedicated NCP connection (e.g. IPCP or IPv6CP) SHOULD transmit a Terminate-Request to the peer. Upon reception of a Terminate-Request, a Terminate-Ack MUST be transmitted to the sender of the Terminate-Request. The sending of the Terminate-Request message MUST be triggered from a IPv4 traffic idle timer within the PPP peer (e.g. end system, HG). After the timeout is reached the IPCP session can be terminated due sending an IPCP terminate request to the peer. The request will be answered with an Terminate-Ack message. The IPv4 address can be returned in a local (e.g. within the BRAS) or remote IPv4 address pool (e.g. via RADIUS/DIAMETER). As long as IPv6 connectivity is needed the PPP session MUST be kept open. When no IPv6 connectivity is detected the PPP session can be terminated again by sending an IPv6CP Terminate-Request and accepting this by a Terminate-Ack. Afterwards the link layer connectivity can be terminated by exchange the LCP Terminate-Request and Terminate-Ack messages. +-------------------------------------------------------------------+ | This figure will show in draft version 01 the message flow for | | releasing IPv4 address parameter. | | | +-------------------------------------------------------------------+ Figure 3: Message flow for releasing IPv4 address parameter 4. Acknowledgements This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. 5. IANA Considerations This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see Guidelines for Writing an IANA Considerations Section in RFCs [RFC5226] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section Fleischhauer & Bonness Expires September 8, 2011 [Page 8] Internet-Draft draft-fleischhauer-ipv4-addr-saving-00 March 2011 will be removed during conversion into an RFC by the RFC Editor. 6. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. 7. References 7.1. Normative Reference [BBF-TR-187] Broadbandforum, "Technical Report TR187 IPv6 over PPP Broadband Access (Issue 1)", May 2010. [BBF-WT-242] Broadbandforum, "Draft WT-242 IPv6 Transition Mechanisms for Broadband Networks". [I-D.ietf-v6ops-ipv6-cpe-router] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in progress), December 2010. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. Fleischhauer & Bonness Expires September 8, 2011 [Page 9] Internet-Draft draft-fleischhauer-ipv4-addr-saving-00 March 2011 7.2. Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Appendix A. Workplan v00 2011-03-07 KF/OB initial version v01 yyyy-mm-dd adding figures + explanation Authors' Addresses Karsten Fleischhauer (editor) Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 64295 Darmstadt DE Phone: +49 6151 628 2831 Email: k.fleischhauer@telekom.de Olaf Bonness Deutsche Telekom AG Goslarer Ufer 35 10589 Berlin DE Phone: +49 30 3497 3124 Email: olaf.bonness@telekom.de Fleischhauer & Bonness Expires September 8, 2011 [Page 10]