On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios.

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

2. 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 Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting

3. 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. F S T M S T W 100% IPv6 addresses #sessions ~# IP addresses Current IPv4 Address Usage/Traffic for www services IPv6addressPool IPv4 addresspool IPv4 addressusage IPv4 addresssaving potential IPv4 addressreservation • 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). Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting

4. 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 Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting

5. 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 Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting

6. 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 Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting

7. PPP and IPv6CP Session Setup.Initial the customer will be provided with IPv6-only connectivity. *) The mechanism will also work when the management of the address pool is done on the NAS. CPE/End System NAS ext. Address- (PPP Peer) (PPP Peer) poolmanagement* | | | 1. ->| | | 2. |<---PPP-LCP-PAP-CHAP---->| | 3. | |----Access-Request--->| 4. | |<-Access-Accept-IPv6->| 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-| Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting

8. Assigning IPv4 address parameter.As soon IPv4 traffic demand is detected an IPv4 address will be assigned. *) The mechanism will also work when the management of the address pool is done on the NAS. 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.--| Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting

9. Releasing IPv4 address parameter When no IPv4 communication exist the IPv4 address can be released. *) The mechanism will also work when the management of the address pool is done on the NAS. 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.--| Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting

10. 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? . . . Fleischhauer/Bonneß IETF80 INTAREA-WG Meeting

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