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]