]> Deutsche Telekom AG

Heinrich-Hertz-Strasse 3-7 64295 Darmstadt DE +49 6151 58 12831 k.fleischhauer@telekom.de

Deutsche Telekom AG

Winterfeldtstr. 21-27 10781 Berlin DE +49 30 835358826 olaf.bonness@telekom.de

General Internet Engineering Task Force IPv4, IPv6, IPCP, IPv6CP, PPP, address saving, Dual-Stack, BBF WT-242, BBF TR-187 Today the Dual-Stack approach is the most straightforward and the 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 public IPv4 addresses can significantly be reduced and the unused public IPv4 addresses can under certain circumstances be returned to the public IPv4 address pool of the service provider. New Dual-Stack enabled services can be introduced without increasing the public 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.

The Dual-Stack approach as defined in provides the most straightforward and most common way for introducing IPv6 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 address. Assuming a situation where most of the IP communication (e.g. always-on, VoIP etc.) can be provided via IPv6, the usage of public IPv4 addresses can be reduced significantly and the unused public IPv4 addresses may be returned to the public 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 .

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

The Broadband Forum describes in 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) and Layer 2 Tunnelling Protocol (L2TP) 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. Usually in such a scenario the service provider offers to the customer the usage of public IPv4 and IPv6 address resources during the duration of the PPP session. Because of the potential parallel usage of IPv4 and IPv6 within such a Dual-Stack PPP scenario an Public IPv4 address is always provisioned, also in the case where most of the communication is transported using IPv6. This document extends the sketched Dual-Stack deployment scenario for PPP and L2TPv2 with a 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.

Assuming a Dual-Stack network access via PPP sessions, end devices can in general communicate via IPv4 and/or IPv6 transport, depending on 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, applications, configuration of the preferences etc.), the network itself and also on 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, CPE etc.) is not necessary. Therefore mechanisms are needed to provision and release public IPv4 addresses for Dual-Stack PPP sessions dynamically. The goal of the solution sketched in this document, is to limit and decrease the public 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 parameters only on demand, when the need for establishing IPv4 connectivity has been detected and IPv4 traffic towards the PPP WAN interface (e.g. of a CPE) 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, CPE). 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.

The figure above shows the architecture of a PPP Dual-Stack environment for providing Internet access for residential customers. The abstract topology normally consists of 3 components: Private Internet (aka. Customer LAN) Public Internet Service Provider AAA area The Private Internet as defined in is the local area network on customer site wherein IPv4 and IPv6 communication are provided. The Private Internet is an optional part of the PPP Dual-Stack architecture. Within the Customer LAN exist one or more private hosts which are connected to the local area network interfaces of the Customer Premise Equipment. These hosts can have IPv4-only, IPv6-only or Dual-Stack communication capabilities. For IPv6 communication inside the Customer LAN Unique Local or public IPv6 addresses may be used. For IPv6 communication to the public Internet public IPv6 addresses should be used. For IPv4 communication within the Customer LAN and to the public Internet it is assumed that private IPv4 addresses must be used by the private hosts. In order to ensure IPv4 communication to the public Internet the CPE must hence provide IPv4 Network Address Translation (NAT44) functionality and map the private IPv4 addresses of the private hosts to a public IPv4 address of the WAN interface of the NAT and vice versa. The NAT functionality on the CPE is the border element between the private IPv4 Internet (aka. Customer LAN) and the public IPv4 Internet. In the case of using public IPv6 addresses for the communication the CPE and its interfaces are an integral part of the public Internet. To the public Internet belong the Access Network of the service provider and all other networks outside the customer LAN that are addressed with global IPv4 and / or IPv6 addresses and can be accessed from the private Internet as well as from other systems within the public Internet. The focus of this draft is directed to the access network of the service provider where in our scenario PPP is used between the CPE and the NAS in order to provide customer access to the public Internet. The Service Provider AAA area is a network which consists of several systems to control the Network Access Server (NAS) and to provide AAA functionalities in order to reduce the load on the NAS. Such Service Provider AAA functionalities include also management of the public IPv4 and public IPv6 address pools inside the NAS and can hence also be integrated directly into the NAS.

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 require explicit IPv4 connectivity. A public IPv4 address can therefore provided sequentially to different customers during the runtime of their PPP connections. This enables a smooth migration from IPv4 to IPv6 in comparison to other IPv4-IPv6 migration approaches (e.g. NAT in service provider network). The customer will be provisioned with a public IPv4 address only in the case when global IPv4 connectivity is really needed and will not be provisioned with an IPv4 address per default when the Dual-Stack PPP session is initiated. Furthermore, a provisioned IPv4 address can be released (e.g. after a certain time interval) in the case that the CPE detects that there is no need any more for global IPv4 connectivity. Or in other words, when global IPv4 connectivity is not needed during the whole time of the PPP session then a (continuous) provisioning of a public IPv4 address to the CPE is not necessary and the provisioning of a public IPv4 address can be done on-demand and dynamically. The main goal of this mechanism is to limit and decrease the pool size for public IPv4 addresses at the service provider site. 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: For each additional PPP session additional AAA parameters have to be created and handled which leads to an extension of AAA domains and more complex processes. Each additional PPP session will require additional resources on the PPP endpoints (e.g. for handling additional customer credentials) as well in devices that act as PPP intermediate agents. Accounting and controlling of traffic classes on an access line or customer base will be impeded or at least complicated. Because of these reasons the introduction of IPv6 as additional network layer protocol on a access line with an additional PPP session is not recommended.

As defined in RFC 2661 PPP and L2TP provide the following main functionalities: A method for encapsulating datagrams over serial links. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. (Optional) Authentication Protocol for one or both peers. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. For provisioning of IPv4 or IPv6 communication parameters (e.g. addresses, DNS resolver) as network-layer protocols only the NCPs Internet Protocol (Version 4) Control Protocol (IPCP) RFC 1332 and Internet Protocol (Version 6) Control Protocol (IPV6CP) RFC 2472 are used. Whereas IPCP is responsible for 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 this network-layer protocol can be sent over the PPP link. Both NCP protocol mechanisms are independent from each other (see also requirement WLL-3 in ). 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 PPP session itself and the other NCP connection inside the PPP session will remain existent. Only in the case that both NCP connections are closed, the PPP session will be terminated.

This chapter names the network elements that are involved in the message flows to enable the on-demand IPv4 address provisioning functionality and describes their functionalities related to this mechanism. Customer Edge Router (CER aka. CPE)/End System This is any device implementing a Dual-Stack PPP stack and acting as a PPP client to the PPP server in the service provider network in order to achieve connectivity to the service provider network. The PPP interface of this device is also called WAN interface . In the case of a Customer Edge Router (CER) this is a node (e.g. intended for home or small office usage) which forwards IPv4 and IPv6 packets those are not explicitly addressed to itself . Therefore the demand for IPv4 connectivity of such a Customer Edge Router will be triggered either by own applications or by receiving IPv4 packets on its customer network facing interfaces that are addressed to the public Internet. In the case of an End System, this system is a node that intends to send IPv4 and/or IPv6 packets. On a End System the IPv4 connectivity demand can only be triggered by own applications. However, in both cases the IPv4_idle_timer resides on the WAN interface in order to detect IPv4 packets passing the WAN interface (incoming/ outgoing) and to measure the related IPv4 idle time when no IPv4 packet has been sent or received. Network Access Server (NAS)/Layer 2 Network Server (LNS) The Network Access Server (NAS) is a device providing local Dual- Stack PPP connectivity to the Service Provider network and acting as a PPP server to the PPP client on the Customer Edge Router or customer end system. Within a RFC 2661 architecture the PPP server within the service provider network is the L2TP Network Server (LNS). The address pool management can be provided locally on the NAS/LNS or remotely. In the case of a local address pool management no information exchange to an external address pool management system is needed in order to assign or release IPv4 addresses. In the case of an external address pool management an information exchange between the NAS/LNS and the address pool management system is required. External Address Pool Management External Address Pool Management is used in the case when no local Address Pool Management system is implemented in the NAS/LNS. In this case it is necessary that the NAS/LNS communicates with an External Address Pool Management System for assigning or releasing IPv4 addresses. RADIUS as specified in or DIAMETER as specified in can be used as protocol between NAS/LNS and the External Address Pool Management System.

A PPP client implementation wishing to open a connection MUST transmit a NCP Configure-Request to the PPP server. If every Configuration Option received in a NCP Configure-Request is recognizable and all values are acceptable, then the PPP server implementation MUST transmit a NCP Configure-Ack to the initiator 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) of the PPP session. 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 CPE (PPP client). Therefore the NAS MUST not initiate the negotiation of IPCP.

| | | 2. |-IPCP-Configure-Request->| | 3. | |----Access-Request--->| 4. | |<---Access-Accept-----| 5. |<-IPCP-Configure-Request-| | 6. |---IPCP-Configure-Ack--->| | 7. |<--IPCP-Configure-Nack---| | 8. |-IPCP-Configure-Request->| | 9. |<---IPCP-Configure-Ack---| | 10. | |--Accounting-Request->| 11. | |<---Accounting-Resp.--| ]]>

In the diagram above, the CPE/End System is triggered (1) to set up IPv4 connectivity via an already existing PPP session. The CPE/End System detects that there is no public IPv4 address for its WAN interface available and starts the negotiation of the needed IPv4 address parameter by sending an IPCP Configure-Request to the NAS (2). The NAS will request the corresponding IPv4 connectivity parameters (e.g. IPv4 address, DNS resolver address) from a local (e.g. within the NAS) or remote database representing the Address Pool Management System(e.g. via RADIUS/DIAMETER) (3, 4). After this the PPP peers use the standard IPCP procedures to finalize the IPv4 address parameter negotiation (5, 6, 7, 8, 9). After the successful provisioning of the IPv4 address parameter the CPE/End system has full global IPv4 connectivity and can proceed with the IPv4 communication. In case of an external Address Pool Management, the NAS will send an Accounting-Request message (10) to the external Address Pool Management System in order to signal the successful negotiation of the IPv4 address parameter. The external Address Pool Management System will answer with an Accounting-Response (11) message.

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 NCP Terminate-Request, a Terminate-Ack MUST be transmitted to the sender of the Terminate-Request. In the PPP Dual-Stack session scenario discussed here, the generation of the Terminate-Request message for the IPCP part of the PPP Dual-Stack session MUST be triggered by an IPv4 traffic idle timer within the PPP client (e.g. end system, CPE). As long as there is still an ongoing IPv6 connection within the PPP session, the PPP session MUST be kept open. Equivalently, when no IPv6 connectivity is detected the IPV6CP session can be terminated again by sending an IPv6CP Terminate-Request and accepting this by a Terminate-Ack. Afterwards the link layer connectivity and hence the whole PPP connection can be terminated by exchanging the LCP Terminate-Request and Terminate-Ack messages.

| | | 2. |--IPCP-Termin.-Request-->| | 3. |<----IPCP-Termin.-Ack.---| | 4. | |-Interim-Acc.-Requ.-->| 5. | |<---Accounting-Resp.--|]]>

The termination of an IPCP session is illustrated in figure 3 above. Within this exemplary message flow it is assumed that there is still an IPV6CP connection active inside the Dual-Stack PPP session. After the expiration of the IPv4 traffic idle timer (1) the CPE/End system sends an IPCP terminate request to the peer (2). The request will be answered with an Terminate-Ack message (3). The IPv4 address can be returned to the local address pool (e.g. within the NAS) or to the remote IPv4 address pool by sending Interim-Accounting messages (4, 5) (e.g. via RADIUS/DIAMETER).

IPv4_Idle_Timer The sending of the Terminate-Request message MUST be triggered by an IPv4 traffic idle timer within the PPP client (e.g. end system, CPE). The timer value MUST be configurable to adopt the mechanism due to the needs of the applications which are using IPv4 and with respect to an optimization of the IPv4 address saving potential.

The author and contributors also wish to acknowledge the assistance of the following individuals or groups. Tina Tsou Sven Schmidtke Dan Wing Vernon Schryer Mark Townsley

This memo includes no request to IANA. TBD. All drafts are required to have an IANA considerations section (see Guidelines for Writing an IANA Considerations Section in RFCs 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 will be removed during conversion into an RFC by the RFC Editor.

TBD. All drafts are required to have a security considerations section. See RFC 3552 for a guide.

&rfc2119; &rfc0791; &rfc1918; &rfc4213; &rfc2460; &rfc1332; &rfc2661; &rfc2472; &rfc2865; &rfc3588; &rfc6204; Broadbandforum Broadbandforum &rfc3552; &rfc5226;

v00 2011-03-07 KF/OB initial version v01 2011-09-06 adding figures + explanation + Feedback IETF80 &mail discussion v02 before IETF 82 review + feedback mail discussion