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


   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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
   ( 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

   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

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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

   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

   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

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)

           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

   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
                       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

   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

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

     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


13.  References

13.1.  Normative References

              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, "General Packet Radio Service (GPRS); GPRS
              Tunnelling Protocol (GTP) across the Gn and Gp interface",
              3GPP TS 29.060 3.19.0, March 2004.

              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.

              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.

              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
   Hermiankatu 12 D
   TAMPERE,   FI-33720


   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   FI-02600 Espoo


Savolainen & Korhonen    Expires August 30, 2010               [Page 15]