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]