On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios
draft-fleischhauer-ipv4-addr-saving-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Karsten Fleischhauer , Olaf Bonness | ||
| Last updated | 2011-09-07 (Latest revision 2011-03-08) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fleischhauer-ipv4-addr-saving-01
Internet Engineering Task Force K. Fleischhauer, Ed.
Internet-Draft O. Bonness
Intended status: Informational Deutsche Telekom AG
Expires: March 10, 2012 September 07, 2011
draft-fleischhauer-ipv4-addr-saving-01
On demand IPv4 address provisioning in Dual-Stack PPP deployment
scenarios
Abstract
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.
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 March 10, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Fleischhauer & Bonness Expires March 10, 2012 [Page 1]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 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 March 10, 2012 [Page 2]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
Table of Contents
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Problem Statement and Purpose of IPv4 address efficiency . . . 4
2.1. Architecture and Communication in a PPP Dual-Stack
environment . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. The advantage of the dynamic address assigning feature . . 7
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Definition of the participating elements and their
functionalities . . . . . . . . . . . . . . . . . . . . . 9
3.2. Assigning IPv4 address parameter on-demand after
establishing PPP and IPv6 connectivity . . . . . . . . . . 10
3.3. Releasing unused IPv4 address parameters . . . . . . . . . 11
3.4. Timer Considerations . . . . . . . . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Workplan . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Fleischhauer & Bonness Expires March 10, 2012 [Page 3]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 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 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 [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 Tunnelling
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. 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.
2.1. Architecture and 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
Fleischhauer & Bonness Expires March 10, 2012 [Page 4]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
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.
Fleischhauer & Bonness Expires March 10, 2012 [Page 5]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
| +------------+ |
| | external | |
| | Address | |
| | Pool | |
| | Management | |
| +------------+ |
| service | provider |
| AAA | area |
+---------+ +--------------|--------------+
| Private |__ |
| Host |_ \ |
| 1 | \ \IPv4 |
+---------+ \ \ |
\ \ IPv4 |
IPv6\ \_+---------+ over PPP+---------+ IPv4 +---------+
\__| CPE |---------| NAS |--------| Public |
__| (PPP | | (PPP | | Host |
/ _| Peer) |---------| Peer) |--------| n |
IPv6/ / +---------+ IPv6 +---------+ IPv6 +---------+
/ / over PPP
+---------+ / /IPv4
| Private |_/ /
| Host |__/
| n |
+---------+
\_______________________/\__________________________________________/
Private Internet Public Internet
Figure 1: PPP Dual-Stack architecture
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:
1. Private Internet (aka. Customer LAN)
2. Public Internet
3. Service Provider AAA area
The Private Internet as defined in [RFC1918] 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
Fleischhauer & Bonness Expires March 10, 2012 [Page 6]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
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.
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 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
Fleischhauer & Bonness Expires March 10, 2012 [Page 7]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
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:
o 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.
o 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.
o 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.
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 parameters (e.g.
addresses, DNS resolver) as network-layer protocols only the NCPs
Internet Protocol (Version 4) Control Protocol (IPCP) RFC 1332
Fleischhauer & Bonness Expires March 10, 2012 [Page 8]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
[RFC1332] and Internet Protocol (Version 6) Control Protocol (IPV6CP)
RFC 2472 [RFC2472] 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
[RFC6204]).
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.
3.1. Definition of the participating elements and their functionalities
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 [RFC6204].
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)
Fleischhauer & Bonness Expires March 10, 2012 [Page 9]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
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 [RFC2865] or DIAMETER as
specified in [RFC3588] can be used as protocol between NAS/LNS and
the External Address Pool Management System.
3.2. Assigning IPv4 address parameter on-demand after establishing PPP
and IPv6 connectivity
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.
Fleischhauer & Bonness Expires March 10, 2012 [Page 10]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
CPE/End System NAS ext. Address
(PPP Peer) (PPP Peer) Pool management
| | |
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.--|
Figure 2: Message flow for assigning IPv4 address parameter
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.
3.3. Releasing unused IPv4 address parameters
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
Fleischhauer & Bonness Expires March 10, 2012 [Page 11]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
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.
CPE/End System NAS ext. Address
(PPP Peer) (PPP Peer) Pool Management
| | |
1. ->| | |
2. |--IPCP-Termin.-Request-->| |
3. |<----IPCP-Termin.-Ack.---| |
4. | |-Interim-Acc.-Requ.-->|
5. | |<---Accounting-Resp.--|
Figure 3: Message flow for releasing IPv4 address parameter
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).
3.4. Timer Considerations
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.
4. Acknowledgements
The author and contributors also wish to acknowledge the assistance
of the following individuals or groups.
Tina Tsou
Fleischhauer & Bonness Expires March 10, 2012 [Page 12]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
Sven Schmidtke
Dan Wing
Vernon Schryer
Mark Townsley
5. IANA Considerations
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
[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
will be removed during conversion into an RFC by the RFC Editor.
6. Security Considerations
TBD.
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".
[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.
Fleischhauer & Bonness Expires March 10, 2012 [Page 13]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[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.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 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 2011-09-06 adding figures + explanation + Feedback IETF80 &mail
discussion
Fleischhauer & Bonness Expires March 10, 2012 [Page 14]
Internet-Draft draft-fleischhauer-ipv4-addr-saving-01 September 2011
v02 before IETF 82 review + feedback mail discussion
Authors' Addresses
Karsten Fleischhauer (editor)
Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7
64295 Darmstadt
DE
Phone: +49 6151 58 12831
Email: k.fleischhauer@telekom.de
Olaf Bonness
Deutsche Telekom AG
Winterfeldtstr. 21-27
10781 Berlin
DE
Phone: +49 30 835358826
Email: olaf.bonness@telekom.de
Fleischhauer & Bonness Expires March 10, 2012 [Page 15]