IPv6 Prefix Sharing Protocol
Author(s): Roland Schott, Marco Spini
IPv6 prefix sharing in policy for convergence applications makes it impossible to track individual quality of service requirements for each host by the policy server. In order to enable it, we define a protocol which is based on...
Network Working Group M. Spini Internet-Draft Huawei Intended status: Standards Track R. Schott Expires: January 15, 2014 Deutsche Telekom July 14, 2013 IPv6 Prefix Sharing Protocol draft-schott-fmc-prefix-sharing-protocol-00.txt Abstract IPv6 prefix sharing in policy for convergence applications makes it impossible to track individual quality of service requirements for each host by the policy server. In order to enable it, we define a protocol which is based on the residential gateway sending some parameters such as IPv6 addresses of each host (3GPP UE or fixed host) to the edge router. The edge router in its turn establishes IP-CAN sub-session for each host to receive the quality of service parameters. The edge router enforces this quality of service which is specific to the host on its traffic both uplink and downlink. When the host disconnects or leaves the network, IP-CAN sub-session is terminated. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 15, 2014. Copyright Notice Copyright (c) 2013 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 Spini & Schott Expires January 15, 2014 [Page 1] Internet-Draft Prefix Sharing for FMC July 2013 (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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Policy for Convergence Architecture . . . . . . . . . . . . . 3 4. Policy for Convergence Solution Overview . . . . . . . . . . . 5 5. P4C Solution Protocol . . . . . . . . . . . . . . . . . . . . 6 6. Address Registration Request/Response Message Definitions . . 7 6.1. Address Registration Request Message Definition . . . . . 7 6.2. Address Registration Reply Message Definition . . . . . . 8 7. Securing Address Registration Protocol . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Spini & Schott Expires January 15, 2014 [Page 2] Internet-Draft Prefix Sharing for FMC July 2013 1. Introduction As part of Fixed Mobile Convergence (FMC) standardization, convergence or Policy for Convergence (P4C) is being actively pursued. P4C deals with applying 3GPP Policy and Charging Control (PCC) to the hosts in a fixed IP network, including the User Equipment (UE) accessing the fixed IP network from home or from a public WiFi access [TS23.203], [TR23.896]. A number of use cases have been documented that exhibit the issue of uniquely identifying a host among many hosts sharing the same IP address [I-D.boucadair-intarea-host-identifier-scenarios]. However, all these use cases involve IPv4 and Network Address Translation (NAT) [RFC2663]. An IPv6 related use case belongs to Policy for Convergence (P4C) area in Fixed Mobile Convergence (FMC) [I-D.sarikaya-fmc-prefix-sharing-usecase]. The problem occurs when more than one host are assigned IPv6 addresses by local device, e.g. Residential Gateway (RG), sharing the same IPv6 prefix without interaction with the Edge router where the PCC interface is terminated. In such a case, PCC can not apply host specific quality of service for each host. 2. Conventions and Terminology 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 [RFC 2119]. 3. Policy for Convergence Architecture When a host, e.g. Local_Host_1 in Figure 1 attaches to a routed Residential Gateway, RG uses DHCPv6 Prefix Delegation as Requesting Router (RR) to request a prefix, possibly of size /60 for home network. The edge router acts as the Delegating Router (DR). So the edge router assigns the IPv6 prefix to the RG. Note that the host can be both 3GPP UE and Fixed device, e.g. PC, IPTV STB,etc. The edge router next initiates an IP Connectivity Access Network (IP- CAN) session with the policy server, a.k.a. Policy and Charging Rules Function (PCRF) to receive the Quality of Service (QoS) parameters. Edge router provides IPv6 Prefix and User Equipment (UE) ID which in this case is equal to the home network line ID. IP-CAN session establishment completes with the policy server sending IP CAN Session Establishment Ack to RG. Edge Router binds the IP Subscriber Session for RG with the IP-CAN Spini & Schott Expires January 15, 2014 [Page 3] Internet-Draft Prefix Sharing for FMC July 2013 session identified by RG ID, IPv6 Prefix. Edge Router applies admission control and quality of service policy based on the parameters received from the policy server during the IP-CAN session establishment. 3GPP UE has to be authenticated. In this case EAP-AKA authentication method is used. RG is the authenticator and AAA server is in 3GPP network. At the end of a successful authentication, UE receives its host id, i.e. Network Access Identifier (NAI) in User-Name attribute . Host id contains International Mobile Subscriber Identity (IMSI) and is in Root NAI format defined in [TS23.003]. Root NAI takes the form of "0IMSI@nai.epc.mncMNC.mccMCC.3gppnetwork.org" for EAP AKA authentication, i.e. if the IMSI is 234150999999999 ( mobile country code MCC = 234, mobile network code MNC = 15), the root NAI then takes the form as email@example.com for EAP AKA authentication. In case of stateless address auto configuration, the host sends a Router Solicitation message to RG and RG sends a Router Advertisement with an IPv6 prefix, the home network prefix. The host creates an 128-bit IPv6 address using this prefix and adding its interface id. Having completed the address configuration, the host can start communication with the Internet to use the Internet services. Another host, e.g. non-3GPP Visiting Host 1 attaches to RG and also establishes an IPv6 address using the home network prefix. Edge router is not involved with this and all other such address assignments. In this case no authentication is performed. So the host does not receive a host id from 3GPP network. The above operation steps assumed that stateless address auto configuration (SLAAC) is used. DHCPv6 based stateful address assignment can also be used. In case of routed RG, RG can be DHCPv6 relay agent communicating with a DHCPv6 server in the operator's IP network. DHCPv6 server in assigning IPv6 addresses to the hosts uses a method where /64 prefixes are never shared between hosts in different home networks. Spini & Schott Expires January 15, 2014 [Page 4] Internet-Draft Prefix Sharing for FMC July 2013 +-------------+ +-------------+ +---------------+ |Policy Server| | AAA Server | |Visiting Host 1|--+ Mobile Network+-------------+ +-------------+ +---------------+ | ---------------------|--------------------- +----+ | +-------------+ |Rout| +-------------+ | +-------------+ |Local_Host_1 |--| ed |----| Edge Router |-------+ | AAA Server/| +-------------+ | RG | +-------------+ | Proxy | +----+ \ +-------------+ +---------------+ | \ |Visiting Host 2|--+ Fixed IP Network \ ---- +---------------+ \ / \ \ |Internet| ---------| Service| \ / ---- Figure 1: Policy for Convergence Architecture The RG does not signal to the edge router the IP6 address assigned to a host, e.g. visiting host 1 or 2, so the edge router acting as Policy and Charging Enforcement Function (PCEF) is not able to start an 3GPP IP-CAN session for the given host ID, IPv6 Address corresponding to each single host, i.e. the Local_Host_1 and visiting host 1 or 2. Each host in the home network creates an IPv6 address which is global and this address can be used to identify the hosts traffic and would enable PCEF to enforce the proper QoS after establishing an IP-CAN session to download the required parameters. UE id given to the mobile network in Section 3 is the home network line id which is the same for all the hosts in the home network. 4. Policy for Convergence Solution Overview In the first phase of the solution, for a 3GPP UE, RG sends IPv6 address of the host and the host id as received from 3GPP network during authentication in Address Registration Request message to the edge router. The timing of this message could be: After SLAAC is completed, e.g. after sending neighbor solicitation message with Target Address is set to the address being checked, in this case the Target Address is the address that RG sends, After DHCPv6 address configuration is completed, in this case IPv6 address in IA Address option (OPTION_IAADDR) is the address that RG sends Spini & Schott Expires January 15, 2014 [Page 5] Internet-Draft Prefix Sharing for FMC July 2013 After receiving the first unicast packet from the host, in this case the source address of the packet is the address that RG sends. RG receives an Address Registration Reply message and checks the code. If the value is zero then the request has succeeded. After the address registration at the edge router, the edge router goes ahead and communicates with the policy server and gets the quality of service parameters for each host separately. for this purpose the edge router establishes an IP-CAN sub-session as part of the main session RG has established with the policy server separately for each host [TR23.896]. For 3GPP UE, during IP-CAN sub-session establishment, the edge router includes the International mobile subscriber identity (IMSI) as part of the host id. The edge router also sends IPv6 address as the new parameter. In case of non-3GPP hosts, during IP-CAN sub-session establishment, the edge router includes RG-ID or line id and IPv6 address as new parameters. It also includes IPv6 prefix. The policy server obtains the subscriber's profile related to the host. The policy router sends the default QoS of the subscriber and some other information to the edge router. IP-CAN sub-session is established between the edge router and the policy server. Over this session, the policy server gets informed about the quality of service related events. The session remains open until the session is removed as requested by the edge router. The edge router repeats the above procedures for each host that shared the address. 5. P4C Solution Protocol Residential Gateway first uses the address registration message exchange to register the addresses of the hosts sharing the prefix. The edge router establishes an IP-CAN session with the policy router for each such host. Edge router gets QoS parameters for each host. Edge router enforces the QoS for each host in the active traffic. When the hosts disconnect or leave the network, the edge router terminates IP-CAN sub-session for each host. Spini & Schott Expires January 15, 2014 [Page 6] Internet-Draft Prefix Sharing for FMC July 2013 The call flow of the protocol is shown in Figure 2. Residential Gateway Edge Router Policy server Addr. | | | Conf'ed |---Address Reg. Req----->| | |<---Address Reg. Reply---| | | |--Est. IP-CAN Sub-Session->| | | | | |<-IP-CAN sub-session est'ed| | | | Disconnect| | | | |--Ter. IP-CAN Sub-Session->| | | | | |<-IP-CAN sub-session ter'ed| Figure 2: Call flow 6. Address Registration Request/Response Message Definitions These messages are sent with UDP header and contain the parameters defined in this section. All parameters are TLV formatted. Length field in UDP header contains the length of the entire datagram. 6.1. Address Registration Request Message Definition Address registration request message is sent by RG. It contains IPv6 address. It may also contain IPv4 address. The address field can be replicated ton register more than one addresses. RG MUST have a different sequence number into each new address request message it sends to the edge router. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameters | . in TLV format . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Address Registration Request Fields: Type: TBD. Spini & Schott Expires January 15, 2014 [Page 7] Internet-Draft Prefix Sharing for FMC July 2013 Length: The length of the option. The value is 8 or 20. octets. Sequence Number: This field is used by the access router to process the requests from RG in the sending order. Followed by parameters 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 4: Address Parameter Fields: Type: TBD. Length: The length of the option. The value is 6 or 18. octets. Address: IPv4 or IPv6 address. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Host id ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 5: Host Id Parameter Fields: Type: TBD. Length: The length of the option. The value > 3. octets. Host Id: Host id in Root NAI format. 6.2. Address Registration Reply Message Definition Address Registration Reply messages are sent by the edge router. Edge router MUST set the sequence number field to the value in the request message. The code is set according to the success of the address request message. Spini & Schott Expires January 15, 2014 [Page 8] Internet-Draft Prefix Sharing for FMC July 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameters | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Address Registration Reply Fields: Type: TBD. Length: The length of the option. The value is 8 or 12, or 24. octets. Sequence Number: The value in the reply MUST match the value in the corresponding request. Code: A value indicating the result of the Address Request. A value of zero (0) indicates successful operation. Any other value indicates an unsuccessful operation. Parameters: IPv4 or IPv6 address and Host Id. Optional field. 7. Securing Address Registration Protocol When address registration protocol is used between the residential gateway and the edge router, there is no need for additional security mechanisms. This is because RG to edge router communication happens over a secured (IPSEC or other mechanisms) tunnel. When address registration protocol is used between the residential gateway and a generic server such as a web server, the protocol MUST be secured. Datagram Transport Layer Security (DTLS) protocol can be used to secure it. DTLS version 1.2 is defined in [RFC6347]. DTLS is Transport Layer Security (TLS) version 1.2 [RFC5246] over datagram transport. DTLS handshake protocol starts with a stateless cookie exchange in which the client, Residential Gateway sends ClientHello message and the server replies with HelloVerifyRequest message which contains a Spini & Schott Expires January 15, 2014 [Page 9] Internet-Draft Prefix Sharing for FMC July 2013 cookie. The client sends ClientHello this time with the cookie. This phase allows the server to verify that Cookie is valid and that the client can receive packets at the given IP address. Note that this phase has been added to DTLS and does not exists in TLS. DTLS handshake protocol continues with essentially the same TLS exchanges such as ServerHello, Certificate, ServerKeyExchange, CertificateRequest and ServerHelloDone messages by the server and Certificate, ClientKeyExchange, CertificateVerify and (Client) Finished messages. With these messages, the client and server exchanges signed certificates, authenticate each other and select a cipher suite to be used to secure the communication between the two. The server replies with ChangeCipherSpec to notify the client that subsequent records will be protected under the newly negotiated CipherSpec and keys and (Server) finished message which terminates the full handshake. DTLS session-resuming handshake which is executed after the keys expire is much simpler. The client sends Client Hello to which the server replies with ServerHello, ChangeCipherSpec and Finished message. The client sends ChangeCipherSpec and Finished message to complete the handshake. 8. IANA Considerations Two type values are needed to be assigned, one for the address request and another for the reply message. 9. Security Considerations Any security considerations arising from Policy for Convergence are TBD. 10. Acknowledgements TBD. 11. References 11.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Spini & Schott Expires January 15, 2014 [Page 10] Internet-Draft Prefix Sharing for FMC July 2013 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC2663, August 1999. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC3633, December 2003. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC5246, August 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC6347, January 2012. [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC6967, June 2013. [TR177] "Broadband Forum Technical report TR-177, IPv6 in the context of TR-101 Issue 1", November 2010. [TR23.896] "3GPP TR23.896, Technical Report on Support for fixed broadband access network convergence", February 2013. [TS23.003] "3GPP TS23.003, Technical Specification Group Core Network and Terminals; Numbering, addressing and identification", March 2013. [TS23.203] "3GPP TS23.203, Policy and Charging Control Architecture", March 2013. 11.2. Informative References [I-D.boucadair-intarea-host-identifier-scenarios] Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy, T., and B. Williams, "Host Identification: Use Cases", draft-boucadair-intarea-host-identifier-scenarios-03 (work in progress), March 2013. [I-D.sarikaya-fmc-prefix-sharing-usecase] Sarikaya, B., Spini, M., and D. DH, "IPv6 Prefix Sharing Problem Use Case", draft-sarikaya-fmc-prefix-sharing-usecase-01 (work in progress), February 2013. Spini & Schott Expires January 15, 2014 [Page 11] Internet-Draft Prefix Sharing for FMC July 2013 Authors' Addresses Marco Spini Huawei Paris, France Email: M.Spini@huawei.com Roland Schott Deutsche Telekom Heinrich-Hertz-Str. 3-7 Darmstadt, 64295 Germany Phone: Email: Roland.Schott@telekom.de Spini & Schott Expires January 15, 2014 [Page 12]