Internet DRAFT - draft-schott-fmc-prefix-sharing-protocol
draft-schott-fmc-prefix-sharing-protocol
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 [RFC2119].
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
0234150999999999@nai.epc.mnc015.mcc234.3gppnetwork.org 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
[RFC2119] 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",
RFC 2663, August 1999.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, 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",
RFC 6967, 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]
