1. On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios. Karsten Fleischhauer, Fixed Mobile Engineering Germany Olaf Bonneß, T-Labs

2. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting2 On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios - draft-fleischhauer-ipv4-addr-saving. Content. Motivation Presumptions Message Flow assigning IPv4 address parameter releasing IPv4 address parameter Next steps

3. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting3 100 % Motivation I/II. With IPv6 usage for always-on NGN services (Voice) - IPv4 connectivity is furthermore only required for a limited time of the day. Current IPv4 Address Usage/Traffic for www services M TW T F S S The pure introduction of the Dual-Stack approach does not mitigate the IPv4 address scarcity. Due shifting IP traffic to IPv6 the IPv4 traffic demand will be decreased. IPv4 connectivity is just temporally necessary. A mechanism which provide an IPv4 address on demand is needed. This mechanism is already part of the BBF standardization (WT-242 IPv6 Transition Mechanisms for Broadband Networks). #sessions ~ # IP addresses IPv4 address reservation IPv4 address saving potential IPv6 addresses IPv4 address usage IPv6 address Pool IPv4 address pool

4. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting4 Motivation II/II. Avoiding additional load on AAA and providing an IPv4 exit strategy. Targeted Scenario Dual-stack PPP deployment, Always-on services are already running on top of IPv6, Provisioning / releasing of IPv4 address only on –demand. Why not using 2 PPP Sessions – one for IPv4 and one for IPv6? avoid doubling of AAA efforts for separate PPP sessions avoiding scalability issues on HG and NAS simplify (traffic class based) traffic control no additional HG configuration (multiple user credentials etc.) Why not using LGN etc.? LGN as last resort solution (complexity, costs etc.) may not become necessary when deploying on-demand IPv4 address provisioning estimated costs in aggregation networks equal to IPv6 introduction will impact the customer experience does not provide an IPv4 exit strategy

5. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting5 Presumptions. IPv6 connectivity is needed, always on (as well as other) services must be provided on IPv6. Home Gateway – Customer Devices Dual-Stack capabilities on network and application layer Traffic and/or timer triggered detection of IPv4 communication demand => assigning / releasing of IPv4 parameters via IPCP Network/Services Dual-Stack capabilities on network and application layer Support for assigning and releasing IPv4 addresses during a Dual-Stack PPP session (local on NAS or RADIUS/DIAMETER based) Protocol Based on well known NCP (IPCP and IPv6CP) mechanism part of BBF-standardization (WT-242); interest and support signaled by several telcos and vendors

6. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting6 The message flow contain 4 blocks. Assigning and Releasing of the IPv4 address can occur within the PPP session several times in succession. PPP/LCP/IPv6CP setup IPv6-only connectivity... Assigning IPv4 address parameter (IPCP configuration) Dual-Stack connectivity Releasing IPv4 address parameter (IPCP termination) IPv6-only connectivity... PPPoE/LCP/IPv6CP termination no session t

7. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting7 PPP and IPv6CP Session Setup. Initial the customer will be provided with IPv6-only connectivity. CPE/End System NAS ext. Address- (PPP Peer) (PPP Peer) poolmanagement* | | | 1. ->| | | 2. | | | 3. | |----Access-Request--->| 4. | | | 5. |--IPv6CP-Conf.-Request-->| | 6. |<-IPv6CP-Configure-Ack---| | 7. |<-IPv6CP-Conf.-Request---| | 8. |--IPv6CP-Configure-Ack-->| | 9. |-ICMPv6-Router-Solicit.->| | 10. |<-ICMPv6-Router-Advert.--| | 11. |---DHCPv6-Requ.-(DNS)--->| | 12. |<--DHCPv6-Replay-(DNS)---| | 13. | |-Account.-Requ.-IPv6->| 14. | |<-Account.-Resp.-IPv6-| *) The mechanism will also work when the management of the address pool is done on the NAS.

8. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting8 Assigning IPv4 address parameter. As soon IPv4 traffic demand is detected an IPv4 address will be assigned. CPE/End System NAS ext. Address- (PPP Peer) (PPP Peer) poolmanagement* | | | 1. ->| | | 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.--| *) The mechanism will also work when the management of the address pool is done on the NAS.

9. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting9 Releasing IPv4 address parameter When no IPv4 communication exist the IPv4 address can be released. CPE/End System NAS ext. Address- (PPP Peer) (PPP Peer) poolmanagement* | | | 1. ->| | | 2. |--IPCP-Termin.-Request-->| | 3. |<----IPCP-Termin.-Ack.---| | 4. | |-Interim-Acc.-Requ.-->| 5. | |<---Accounting-Resp.--| *) The mechanism will also work when the management of the address pool is done on the NAS.

10. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting10 Next Steps. Until IETF81: Feedback highly welcome! Introducing Message Flow in I-D 01 under consideration of WG feedback. Is this a working topic for the Intarea WG? If "Yes" => Adopt the I-D as WG topic?...

11. 29.03.2011Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting11 Thanks for your attention! Contact: Karsten Fleischhauer E-mail: K.Fleischhauer@telekom.de Olaf Bonneß E-mail: olaf.bonness@telekom.de