IETF T. Savolainen
Internet-Draft Nokia
Intended status: Standards Track J. Korhonen
Expires: August 30, 2010 Nokia Siemens Networks
February 26, 2010
Stateless IPv6 Prefix Delegation for IPv6 enabled networks
draft-savolainen-stateless-pd-01
Abstract
This document describes an automatic and stateless IPv6 prefix
delegation solution for IPv6-only and dual-stack access networks.
The solution builds on automatic delegation mechanism defined by 6RD,
but is suitable for IPv6-only networks, including those that have not
deployed stateful DHCPv6. The described stateless approach
essentially exchanges the complexity of the stateful prefix
delegation to increased consumption of IPv6 address space and less
flexible properties.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Savolainen & Korhonen Expires August 30, 2010 [Page 1]
Internet-Draft Stateless PD February 2010
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Address space consumption considerations . . . . . . . . . . . 4
3. Protocol overall description . . . . . . . . . . . . . . . . . 5
3.1. Unique /64-bit prefixes . . . . . . . . . . . . . . . . . 5
3.2. IPv4 address . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Interface identifier . . . . . . . . . . . . . . . . . . . 7
3.4. Layer 2 identifier . . . . . . . . . . . . . . . . . . . . 8
3.5. Multiple uplink interfaces . . . . . . . . . . . . . . . . 8
3.6. Interaction with IP mobility . . . . . . . . . . . . . . . 8
3.7. Advertised prefix lifetimes . . . . . . . . . . . . . . . 8
4. Provisioning of hosts . . . . . . . . . . . . . . . . . . . . 9
5. Delegated Prefix calculation . . . . . . . . . . . . . . . . . 10
6. Prefix aggregation in 3GPP networks . . . . . . . . . . . . . 11
7. Verification of delegated prefixes . . . . . . . . . . . . . . 11
8. Numbering examples . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 12
8.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Savolainen & Korhonen Expires August 30, 2010 [Page 2]
Internet-Draft Stateless PD February 2010
1. Introduction
This documents describes how an automatic and stateless IPv6 Prefix
Delegation can be realized in some IPv6-only and dual-stack access
networks. The concept of automatic prefix delegation as described
herein builds on what 6RD [I-D.ietf-softwire-ipv6-6rd] has defined
for IPv4-only access networks.
The 6RD approach uses an IPv4 address and service provider's own IPv6
address prefix to calculate delegated IPv6 prefixes. This document
describes how the IPv4 address required for the 6RD's calculation can
be replaced with unique bits from other information sources, such as
from unique /64 prefix allocated to a host or for example from the
GTP Tunnel Endpoint IDentifier [3GPP.29.060] or GRE Key [RFC2890].
This makes it possible to calculate the delegated, shorter than /64,
prefixes from configured service provider's IPv6 prefix and from an
unique data source known by the host and the network gateway. The
described improvement allows automatic prefix delegation without any
dependency to IPv4.
As this solution is for IPv6-enabled networks, no IP-in-IP
encapsulation is required. Due to stateless nature, this approach
enables prefix delegation without mandating deployment of stateful
DHCPv6 servers or AAA involvement. When the mechanism is used in
deployments such 3GPP, IPv6 routing remains static and does not
require dynamic updates (see figure 1).
The described stateless solution is complementary, and in some
scenarios alternative, solution for stateful DHCPv6 Prefix Delegation
(DHCPv6 PD) described in [RFC3633]. The calculated prefixes are used
similarly to how prefixes delegated with DHCPv6 PD would be used,
except that lifetime of these prefixes are bound to the lifetime of
the used source of information (e.g. the /64-bit prefix of host's WAN
interface or in case of GTP TEID to the lifetime of network
connection).
It is worth noting that while possible with stateless prefix
delegation, it may not be feasible to delegate multiple prefixes from
different subnets (e.g. two /56 that do not aggregate into one
shorter /yy prefix), which may be needed if service providers needs
to delegate different prefixes for different kind of services such as
for Internet use and for sensor use.
The stateless delegation is designed to be a solution for the
scenario where large number of hosts, routers, need to delegated a
single and fixed, usually not very short, size of prefix. As of this
writing, it is unclear which size of prefix would be optimal for
large deployments, e.g. to be given for cellular routers (mobile
Savolainen & Korhonen Expires August 30, 2010 [Page 3]
Internet-Draft Stateless PD February 2010
phones acting as moving routers).
In IETF's history there have been other proposals for simpler prefix
delegation, such as IPv6 Router Advertisement Prefix Delegation
Option [I-D.lutchann-ipv6-delegate-option] that proposed new option
for Router Advertisement sent by service provider router towards site
router, and Automatic Prefix Delegation Protocol for Internet
Protocol Version 6 (IPv6) [I-D.haberman-ipngwg-auto-prefix] that
proposed ICMPv6 based request and reply protocol. The DHCPv6 PD, RA-
based, and ICMPV6-based solutions all describe explicit delegation of
prefixes, while 6RD and this document propose algorithmic prefix
delegation.
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. Address space consumption considerations
As the stateless prefix delegation essentially always allocates
shorter than /64 IPv6 prefixes for all nodes on the network segment
using the technology, it by design may waste IPv6 address space.
If the IPv6 address space consumption is an issue for an operator,
there are ways to mitigate it.
By setting up the network in right manner, it is possible to support
stateless prefix delegation only for those nodes known to be in need
of additional prefixes. In 3GPP networks this could be realized by
creating a special access point that supports stateless prefix
delegation. Nodes that require additional prefixes would be
configured to connect to that dedicated access point name (APN).
Nodes that do not require additional prefixes would continue using an
APN not supporting stateless prefix delegation.
In the fixed network, if all nodes under a gateway are known to be
routers requiring similar length of delegated prefix, the address
space is not wasted.
However, waste occurs if routers have significantly different needs,
for example some require /48 while some would settle for /60, but
network nevertheless allocates all routers the shortest common
nominator.
If majority of nodes would require only small number of additional
Savolainen & Korhonen Expires August 30, 2010 [Page 4]
Internet-Draft Stateless PD February 2010
prefixes, the stateless prefix delegation could be tuned to delegate
only very small blocks, such as /62. DHCPv6 Prefix Delegation could
then be provided for nodes with special needs.
3. Protocol overall description
The 6RD technology uses globally or locally unique IPv4 address in
building of 6RD delegated prefixes. This document expands on that
and documents how other sources of unique information, which has to
be known by both a host and a network, can be similarly used to
calculated automatically delegated prefixes.
The sources of suitable uniqueness covered in this memo are:
Unique /64 prefixes: In certain network architectures, such as
3GPP's and WiMAX Forum's, each point-to-point link has an unique
/64 bit prefix, from where unique bits can be fetched for prefix
calculation.
IPv4 address: The 6RD uses IPv4 address as part of the prefix
delegation, but that approach has dependency to IPv4.
Nevertheless, if (locally) unique IPv4 address is available, such
as in dual-stack network accesses, it can be used.
Interface Identifier: The IIDs used by hosts on a given link are
always unique, and in case of PPP can also be unique over set of
links (e.g. unique over PPP links terminated by the same box).
Layer 2 Identifier: In some cases IPv6 is transmitted over a tunnel
or bearer, which has unique identifier. For example in 3GPP
networks each bearer using GPRS Tunneling Protocol (GTP) has an
tunnel identifier (GTP TEID).
The chapter "Provisioning of hosts" describes options that network
can use to instruct the host with the source of unique bits it should
use.
3.1. Unique /64-bit prefixes
In certain point-to-point network architectures host is configured
with an unique /64-bit prefix. Best examples of such networks are
3GPP and WiMAX.
In the case host receives multiple /64 prefixes in its WAN interface,
the host could statelessly configure prefixes from all of the
received prefixes (e.g. if network is renumbering), or choose one
(DISCUSS needed which one).
Savolainen & Korhonen Expires August 30, 2010 [Page 5]
Internet-Draft Stateless PD February 2010
As a host has unique /64-bit prefix, it can use lowest bits of the
prefix in conjunction with service provider configured common prefix.
Essentially, a host can build delegated prefix similarly to 6RD, but
use the unique IPv6 prefix bits instead of an IPv4 address.
The lifetime of delegated prefixes are bound to lifetime of the
unique /64 bit prefix, which usually is bound to lifetime of layer 2
connection between the host and the network. If the host has static
/64 prefix, i.e. host receives same /64 prefix in subsequent layer 2
connection establishments to the same network, then the delegated
prefixes remain valid over reconnections (unless service provider's
common prefix changes).
The host behaviour is as follows. Note that host 1 of figure 1 does
only the step one, while hosts 2 and 3 do also steps 2-4:
1. Host receives unique /64-bit prefix on its WAN interface (e.g.
3GPP) as currently.
2. Host asks for service provider common prefix via DHCPv6
Information Request.
3. Host combines lowest bits of /64 prefix with common prefix, and
learns the prefix it has been delegated (PrefD2, PrefD3).
4. Host becomes a router and starts to advertise /64 subnet
prefix(es) selected from the delegated prefix on local area
network(s), or further delegates them (PrefD2-1, PrefD3-1&2).
The network behaviour is as follows:
1. Allocate service provider common prefix for stateless IPv6 Prefix
Delegation use
2. When a host connects, gateway allocates /64 prefix for the point-
to-point link as currently.
3. After the allocation of /64, network calculates delegated
prefixes for newly connected host, and updates routing tables
accordingly. This happens for all hosts 1-3 of figure 1. The
gateway cannot know which of the hosts are going to use delegated
prefixes, as the delegation is stateless.
4. As the delegated prefixes can be calculated based on the
allocated /64 prefix and service provider common prefix,
accounting and authorization functions can identify to which
subscriber different data flows belong.
Savolainen & Korhonen Expires August 30, 2010 [Page 6]
Internet-Draft Stateless PD February 2010
The following figure 1 illustrates the setup on a network using
point-to-point links (such as PPP):
+-------------+
(PrefD1-1) Pref1::/64 | |
Host1--------------+ Gateway |
| | DHCPv6 server
PrefD2-1 Pref2::/64 | [address | |
--(LAN)---Host2--------------+ allocation] +-------+------- (Internet)
| | Prefix used for
PrefD3-1 Pref3::/64 | [routing] | Pref1/2/3 is
--(LAN)---Host3--------------+ | routed, as well
| | | as service
--(LAN)----+ +-------------| provider prefix)
PrefD3-2
Figure 1: Stateless PD on point-to-point architecture
On the figure 1, from Internet point of view, all packets destined to
/64 prefixes used on hosts' WAN interface, or to the service
provider's common prefix, are routed to the gateway. Therefore no
dynamic IPv6 routing changes are required. It is only the gateway
that has routing table configured to route packets towards correct
hosts.
Firewall functionality is not illustrated, as that should not differ
from ordinary DHCPv6-based prefix delegation architecture.
3.2. IPv4 address
This approach is the same as 6RD, except that encapsulation is not
needed if a host is provided with dual-stack network connectivity.
The IPv4 address can be globally or locally unique. The used link
type may be shared or point-to-point.
3.3. Interface identifier
IPv6 over PPP [RFC5072] defines negotiation method for Interface
Identifier (IID) for PPP connections, and mentions that IID may also
be unique over larger scope than single PPP link. The IPv6CP
provides means for the PPP "server", i.e. the gateway, to dictate and
know what Interface Identifier the host side of PPP link configures
for itself. Similar thing is possible in 3GPP networks as well,
where the network always configures one Interface Identifier for a
host to help optimize Duplicate Address Detection procedures. A
network that controls hosts IID selection can ensure all hosts have
unique IID (on gateway's scope), and thus this IID can be used in
Savolainen & Korhonen Expires August 30, 2010 [Page 7]
Internet-Draft Stateless PD February 2010
building of the statelessly delegated IPv6 prefixes. On multicast
capable links unique IIDs (such as those based on MAC-addresses)
might be used as component for delegated prefix calculation.
When IIDs are used, the setup is very similar to that of figure 1,
except that instead of binding /64 prefix to delegated prefixes,
gateway binds allocated interface identifiers to delegated prefixes.
This enables renumbering for the WAN interface, as long as IID is not
changed in the process.
3.4. Layer 2 identifier
On some deployments gateway can efficiently differentiate hosts based
on layer 2 identifiers, such as GPRS Tunneling Protocol tunnel
endpoint identifiers (GTP TEID) [3GPP.29.060], or GRE keys [RFC2890].
In such cases, it may be desirable to build delegated prefixes based
on layer 2 identifier; the gateway can then forward traffic based on
the layer 2 identifier embedded within IPv6 address rather than by
IPv6 address itself.
3.5. Multiple uplink interfaces
A mobile node may be attached to multiple uplink WAN connections
simultaneously, in which case it may statelessly receive delegated
prefixes from more than one network interface. In such case the host
can choose which, or all, of the delegated prefixes it advertises on
the local area network(s). When new upstream connections are opened
and statelessly delegated prefixes calculated, the host may add new
prefixes to router advertisements it is sending locally. When
upstream connection(s) are lost beyond recovery (e.g. if re-
establishment fails), the host must send router advertisement with
preferred and valid lifetime of zero to local area network for those
prefixes that no longer can be routed.
3.6. Interaction with IP mobility
The /64 prefix, or single IPv6 address, may have been allocated by
the PMIP6 [RFC5213] Local Mobility Anchor (LMA) or (DS)MIP6 Home
Agent [RFC3775][RFC5555]. In such case network or host based
mobility is provided also for the statelessly delegated prefixes,
i.e. essentially providing NEMO-kind of functionality (alternatively
to [I-D.ietf-mext-nemo-pd] DHCPv6 PD based NEMO).
3.7. Advertised prefix lifetimes
The lifetimes for the advertised prefixes depends on the source of
information used on prefix calculation.
Savolainen & Korhonen Expires August 30, 2010 [Page 8]
Internet-Draft Stateless PD February 2010
In the case of IPv6 prefix or IPv4 address, the advertised prefix
lifetime is to be equal or shorter than the lifetime of the source.
In the case of IID or layer 2 identifier, the advertised prefix
lifetime may be bound to those, i.e. be valid as long as the link is
up. To enable network renumbering in case of long lived connections,
the host MUST recheck validity of the service provider prefix daily
or in apparent route failure (e.g. determined based on received
ICMPv6 error messages).
4. Provisioning of hosts
The host provisioning happens similarly to 6RD, both DHCPv6 and and
IPCPv6 can be used.
The network operator must ensure that the indicated source of
uniqueness is indeed unique within the network.
The configuration option looks as below. The validity time of the
delegated prefixes depend both on the source of unique information
and validity of service provider's IPv6 prefix.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_6SPD | len | unique-length |v6prefix-length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|I|4|T| Reserved |
+-+-+-+-+-+-----------------------------------------------------+
| |
| SP IPv6 SPD Prefix |
| (variable, up to 16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option code OPTION_6SPD(TBD)
len Total length of option in octets.
unique-length The number of bits from the unique
value that MUST be used when
generating 6SPD Delegated Prefix. For example,
if the value is 20 and unique-source flag
indicates IPv6 prefix, then bits 45-64 of
Savolainen & Korhonen Expires August 30, 2010 [Page 9]
Internet-Draft Stateless PD February 2010
the /64 prefix are to be used. Minimum length
is 1 bit, and maximum is 32 bits.
v6prefix-length IPv6 Prefix length of the SPD IPv6 prefix in
number of bits.
unique-source flags
These mutually exclusive flags indicate the
source from where a host MUST fetch the
unique bits required for the Delegated Prefix
calculation. One flag MUST be up at a time:
P: The host uses the lowest bits of the
/64 bit prefix allocated on the point-to-point
link.
I: The host uses the lowest bits of the
Interface Identifier negotiated for the link
(the link does not have to be point-to-point).
4: The host uses the IPv4 address
allocated by the network
T: The host uses a tunnel identifier,
the identifier of which depends on the used
access technology (such as GTP TEID or GRE
key)
SP IPv6 SPD prefix Service Provider's IPv6 "Stateless Prefix
Delegation" (SPD) prefix for deployment on this
subnet and possibly for this particular host,
variable length and zero padded to at least a
full octet. Actual length of this field is
determined by the length of the entire DHCPv6
option.
5. Delegated Prefix calculation
The calculation of delegated prefix requires the service provider
prefix and bits from the unique information source. The address
format is as follows:
Savolainen & Korhonen Expires August 30, 2010 [Page 10]
Internet-Draft Stateless PD February 2010
/n + n + n + 64 = 128 bits
+-----------------+----------+-----------+-------------------------+
| SPD-prefix | V6UNIQUE | Subnet ID | Interface ID |
+-----------------+----------+-----------+-------------------------+
|<--- Calculated Prefix --->|<--- Addresses available for host--->|
SPD-prefix The Service Provider's prefix for automatic prefix
delegation
V6UNIQUE The bits from the unique source, e.g. bottom part of
the /64 prefix of host's WAN interface. The maximum
length is limited by SPD-prefix length and number of
subnets each subscriber is to be provided with. The
minimum length is 1 bit.
Subnet ID The size of the delegated address space for the host.
6. Prefix aggregation in 3GPP networks
I-D.krishnan-intarea-pd-epc describes the need to optimize prefix
delegation in 3GPP networks in a way that the /64 configured for a
host's WAN interface would be part of the shorter prefix, such as
/56, assigned to the host. The stateless prefix delegation can solve
the problem as well: when a node calculates the prefix it has been
statelessly delegated, it MUST check if part of the delegated prefix
is already in use on the uplink interface, and if that is the case,
then the node MUST NOT use the same prefix(es) on its downlink
interfaces or as part of further prefix delegation.
For example, if GTP TEID is used as the source of uniqueness, a host
would construct the delegated prefix by appending configured number
of bits from GTP TEID to the service provider prefix. After the
calculation, host would check if a /64 of that space is already in
use in the uplink bearer. Practical example: SPD prefix could be
2001:0db8::/32, GTP TEID for an UE could be 0x12345678 from where
24bits lowest bits would be taken, and this would result in a
delegated prefix of: 2001:0db8:3456:7800::/56. Now if the UE
receives 2001:0db8:3456:7800::/64 on Router Advertisement of the
cellular bearer, it would have to exclude it from the delegated
address space.
7. Verification of delegated prefixes
The stateless prefix delegation is an implicit rather than an
explicit procedure. The stateless delegation may be used in less
managed deployments than DHCPv6-based prefix delegation. To ensure
Savolainen & Korhonen Expires August 30, 2010 [Page 11]
Internet-Draft Stateless PD February 2010
there are no configuration errors and that the delegated prefixes are
successfully handled by all involved entities and possible
middleboxes, a host MUST do a connectivity test by sending few ICMPv6
Echo Requests from randomly selected source addresses of the
delegated IPv6 address space, and based on received replies determine
if the delegation has been successful. This helps to avoid
advertisement of non-functional prefixes to local area networks, and
may also help host to fallback to other network connection sharing
solutions such as DHCPv6 PD or Neighbor Discovery Proxy [RFC4389].
8. Numbering examples
Here are few examples of different numbering schemes.
8.1. Example 1
16.78 million customers and 256 subnets per subscriber.
* The V6UNIQUE length has to be 24 bits
* Subnet ID length has to be 8 bits
Thus SPD-prefix of length /32 is enough.
8.2. Example 2
1 million subscribers and 16 subnets per subscriber.
* V6UNIQUE length has to be 20 bits
* Subnet ID length has to be 4 bits
Thus SPD-prefix of /40 is enough.
8.3. Example 3
536 million subscribers and 8 subnets per subscriber.
* V6UNIQUE length has to be 29 bits
* Subnet ID length has to be 3 bits
Thus SPD-prefix of /32 is enough.
Savolainen & Korhonen Expires August 30, 2010 [Page 12]
Internet-Draft Stateless PD February 2010
8.4. Example 4
16.78 million customers and 4 subnets per subscriber.
* V6UNIQUE length has to be 24 bits
* Subnet ID length has to be 2 bits
Thus SPD-prefix of /38 is enough.
9. Conclusions
Feedback requested.
There are plenty of IPv6 addresses and large number of customers can
be satisfied with reasonably long delegated prefixes. With stateless
delegation explicit signaling for prefix delegation purposes between
large numbers of (unmanaged) customer equipment and operator's DHCPv6
servers can be avoided. Operator remains in control of prefix
delegation by using dedicated APNs (cellular network case), not
providing service provider prefix on request (e.g. determined by
device identifiers), and by enforcing communications with firewalls.
10. Acknowledgements
The author would like to acknowledge authors and originators of 6RD
technology, Remi Despres, Mark Townsley, and Ole Troan. This memo
builds on the concept of automatic prefix delegation introduced in
6RD [I-D.ietf-softwire-ipv6-6rd].
Further acknowledgements (in no particular order) go to Frank
Brockners, Konrad Rosenbaum, Suresh Krishnan, Fredrik Garneij, Kaisu
Iisakkila, Behcet Sarikaya, Hui Deng, and Julien Laganier for all the
discussions, criticism, and improvement ideas.
The used template was derived from an initial version written by
Pekka Savola and contributed by him to the xml2rfc project. The text
file was generated with xml2rfc tool.
11. IANA Considerations
This memo includes request to IANA to allocate numbers for new DHCPv6
and ICMPv6 options.
Savolainen & Korhonen Expires August 30, 2010 [Page 13]
Internet-Draft Stateless PD February 2010
12. Security Considerations
TBD
13. References
13.1. Normative References
[I-D.ietf-softwire-ipv6-6rd]
Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider
Networks "6rd"", draft-ietf-softwire-ipv6-6rd-07 (work in
progress), February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007.
13.2. Informative References
[3GPP.29.060]
3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface",
3GPP TS 29.060 3.19.0, March 2004.
[I-D.haberman-ipngwg-auto-prefix]
Haberman, B. and J. Martin, "Automatic Prefix Delegation
Protocol for Internet Protocol Version 6 (IPv6)",
draft-haberman-ipngwg-auto-prefix-02 (work in progress),
May 2002.
[I-D.ietf-mext-nemo-pd]
Droms, R., Thubert, P., Dupont, F., and W. Haddad, "DHCPv6
Prefix Delegation for NEMO", draft-ietf-mext-nemo-pd-03
(work in progress), October 2009.
[I-D.lutchann-ipv6-delegate-option]
Lutchansky, N., "IPv6 Router Advertisement Prefix
Delegation Option", draft-lutchann-ipv6-delegate-option-00
(work in progress), February 2002.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
Savolainen & Korhonen Expires August 30, 2010 [Page 14]
Internet-Draft Stateless PD February 2010
December 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
Authors' Addresses
Teemu Savolainen
Nokia
Hermiankatu 12 D
TAMPERE, FI-33720
FINLAND
Email: teemu.savolainen@nokia.com
Jouni Korhonen
Nokia Siemens Networks
Linnoitustie 6
FI-02600 Espoo
FINLAND
Email: jouni.nospam@gmail.com
Savolainen & Korhonen Expires August 30, 2010 [Page 15]