IETF T. Savolainen
Internet-Draft Nokia
Intended status: Standards Track October 19, 2009
Expires: April 22, 2010
Stateless IPv6 Prefix Delegation for IPv6 enabled networks
draft-savolainen-stateless-pd-00
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 April 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes an automatic and stateless IPv6 prefix
delegation solution for IPv6-only networks. The solution builds on
automatic delegation mechanism defined by 6RD, but is suitable for
Savolainen Expires April 22, 2010 [Page 1]
Internet-Draft Stateless PD October 2009
IPv6-only networks, including those that have not deployed stateful
DHCPv6. The described stateless approach essentially exchanges the
complexity of the stateful approach to consumption of IPv6 address
space and more statical properties.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Protocol overall description . . . . . . . . . . . . . . . . . 4
2.1. Unique /64-bit prefixes . . . . . . . . . . . . . . . . . 4
2.2. IPv4 address . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Interface identifier . . . . . . . . . . . . . . . . . . . 6
2.4. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Layer 2 identifier . . . . . . . . . . . . . . . . . . . . 7
2.6. Multiple uplink interfaces . . . . . . . . . . . . . . . . 7
2.7. Interaction with IP mobility . . . . . . . . . . . . . . . 7
2.8. Advertised prefix lifetimes . . . . . . . . . . . . . . . 8
3. Provisioning of hosts . . . . . . . . . . . . . . . . . . . . 8
4. Delegated Prefix calculation . . . . . . . . . . . . . . . . . 9
5. Verification of delegated prefixes . . . . . . . . . . . . . . 10
6. Numbering examples . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Savolainen Expires April 22, 2010 [Page 2]
Internet-Draft Stateless PD October 2009
1. Introduction
This documents describes how an automatic and stateless IPv6 Prefix
Delegation can be realized in some IPv6-only networks. The consept
of automatic prefix delegation as described herein builds on what 6RD
[I-D.ietf-softwire-ipv6-6rd] has defined for IPv4-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. This makes it possible
to calculate the delegated, shorter than /64, prefixes from learned
service provider's IPv6 prefix and from IPv6-specific unique data
source. The described improvement allows automatic 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 an alternative for stateful
DHCPv6 Prefix Delegation (DHCPv6 PD) described in RFC3633 [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).
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].
Savolainen Expires April 22, 2010 [Page 3]
Internet-Draft Stateless PD October 2009
2. 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 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).
DHCPv6: A host may have been allocated IPv6 address statefully. In
that case it is possible to use that IPv6 address as a source of
uniqueness.
The chapter "Provisioning of hosts" describes options that network
can use to instruct the host with the source of unique bits it should
use.
2.1. Unique /64-bit prefixes
In certain point-to-point network architectures host is configured
with unique /64-bit prefix. Best examples of such networks are 3GPP
and WiMAX.
As a host has unique /64-bit prefix, it can use lowest bits of the
prefix in conjuction 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
Savolainen Expires April 22, 2010 [Page 4]
Internet-Draft Stateless PD October 2009
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.
The following figure 1 illustrates the setup on a network using
point-to-point links (such as PPP):
Savolainen Expires April 22, 2010 [Page 5]
Internet-Draft Stateless PD October 2009
+-------------+
(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.
2.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.
2.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
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 (?).
Savolainen Expires April 22, 2010 [Page 6]
Internet-Draft Stateless PD October 2009
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.
2.4. DHCPv6
When the host is allocated IPv6 address statefully with DHCPv6, it is
possible to use that address as source of uniqueness for stateless
delegated prefix calculation in case network administrator for some
reason does not want to use stateful DHCPv6 Prefix Delegation.
[RFC3633]
If a DHCPv6 server, or a DHCPv6 proxy, locates at the first hop
entity from the host point of view, routing table management is
similar to /64 prefix case. The entry is created by combining
service provider prefix and relevant bits from the allocated IPv6
address. (Q:Does tthe same work with DHCPv6 relay?)
2.5. Layer 2 identifier
On some deployments gateway can efficiently differentiate hosts based
on layer 2 identifiers, such as GPRS Tunneling Protocol tunnel
endpoint identifier (GTP TEID). 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.
2.6. 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.
2.7. 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
Savolainen Expires April 22, 2010 [Page 7]
Internet-Draft Stateless PD October 2009
mobility is provided also for the statelessly delegated prefixes.
The service provider's common prefix MUST be configured for each of
host's new prefix/IPv6 address individually. This makes it possible
for administrator to control on which interfaces stateless prefix
delegation is possible.
2.8. Advertised prefix lifetimes
The lifetimes for the advertised prefixes depends on the source of
information used on prefix calculation.
In the case of IPv6 prefix, IPv6 address, 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).
3. Provisioning of hosts
The host provisioning happens similarly to 6RD, both DHCPv6 and and
IPCPv6 can be used.
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|D|2| Reserved |
+-+-+-+-+-+-----------------------------------------------------+
| |
| SP IPv6 SPD Prefix |
| (variable, up to 16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Savolainen Expires April 22, 2010 [Page 8]
Internet-Draft Stateless PD October 2009
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
the /64 prefix are to be used.
v6prefix-length IPv6 Prefix length of the SPD IPv6 prefix in
number of bits.
unique-source flags
These flags indicate the source from where a host
should fetch the unique bits required for
the Delegated Prefix calculation. Only one flag
of the following may be up:
P: The host MUST use the lowest bits of the
/64 bit prefix allocated on the point-to-point
link.
I: The host MUST use the lowest bits of the
Interace Identifier negotiated for the link
(the link does not have to be point-to-point).
4: The host should use the IPv4 address
allocated by the network (this is
exactly 6RD then?).
D: The host should use the lowest bits of the
/128 IPv6 address allocated via DHCPv6.
2: The host should use layer 2 identifier,
the identifier of which depends on the used
access technology.
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.
4. Delegated Prefix calculation
The calculation of delegated prefix requires the service provider
prefix and bits from the unique information source. The address
Savolainen Expires April 22, 2010 [Page 9]
Internet-Draft Stateless PD October 2009
format is as follows:
/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.
Subnet ID The size of the delegated address space for the host.
5. Verification of delegated prefixes
The stateless prefix delegation is an implicit rather than an
explicit procedure. The stateless delegation may also be used in
much more dynamic and less managed deployments than DHCPv6-based
prefix delegation. To ensure there are no configuration errors and
that the delegated prefixes are successfully handled by all involved
entities and possible middleboxes, a host MAY 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].
6. Numbering examples
Here are few examples of different numbering schemes.
6.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
Savolainen Expires April 22, 2010 [Page 10]
Internet-Draft Stateless PD October 2009
Thus SPD-prefix of length /32 is enough.
6.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.
6.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.
6.4. Example 4
16.78 million customers and 4 subnets per subscriber.
* V6UNIQUE length has to be 24 bits
* Subnet ID lenght has to be 2 bits
Thus SPD-prefix of /38 is enough.
7. 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 signaling for prefix delegation purposes between
(unmanaged) customer equipment and operator's DHCPv6 servers can be
avoided. Operator remains in control of prefix delegation by not
providing service provider prefix on request and enforcing
communications with firewalls.
Savolainen Expires April 22, 2010 [Page 11]
Internet-Draft Stateless PD October 2009
8. 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].
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.
9. IANA Considerations
This memo includes request to IANA to allocate numbers for new DHCPv6
and ICMPv6 options.
10. Security Considerations
TBD
11. References
11.1. Normative References
[I-D.ietf-softwire-ipv6-6rd]
Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider
Networks", draft-ietf-softwire-ipv6-6rd-00 (work in
progress), August 2009.
[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.
11.2. Informative References
[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.lutchann-ipv6-delegate-option]
Lutchansky, N., "IPv6 Router Advertisement Prefix
Savolainen Expires April 22, 2010 [Page 12]
Internet-Draft Stateless PD October 2009
Delegation Option", draft-lutchann-ipv6-delegate-option-00
(work in progress), February 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
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.
Author's Address
Teemu Savolainen
Nokia
Hermiankatu 12 D
TAMPERE, FI-33720
FINLAND
Email: teemu.savolainen@nokia.com
Savolainen Expires April 22, 2010 [Page 13]