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]