Internet DRAFT - draft-sarikaya-fmc-prefix-sharing-usecase
draft-sarikaya-fmc-prefix-sharing-usecase
Network Working Group B. Sarikaya
Internet-Draft M. Spini
Intended status: Informational Huawei
Expires: August 15, 2013 D. von Hugo
Telekom Innovation Laboratories
February 11, 2013
IPv6 Prefix Sharing Problem Use Case
draft-sarikaya-fmc-prefix-sharing-usecase-01.txt
Abstract
The purpose of this document is to present a use case on problems
in addressing end user equipment arising from IPv6 prefix sharing.
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 August 15, 2013.
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
(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.
Sarikaya, et al. Expires August 15, 2013 [Page 1]
Internet-Draft Prefix Sharing for FMC February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
3. Policy for Convergence Operation . . . . . . . . . . . . . . . 3
4. Issue Description . . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Sarikaya, et al. Expires August 15, 2013 [Page 2]
Internet-Draft Prefix Sharing for FMC February 2013
1. Introduction
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]. Moreover
several solutions to provide a unique identification to hosts in
deployment contexts with address sharing have been analysed in
[I-D.ietf-intarea-nat-reveal-analysis]. However, all these use
cases involve IPv4 and Network Address Translation (NAT) [RFC2663].
The use case described in this document belongs to Policy for
Convergence (P4C) area in Fixed Mobile Convergence (FMC). 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 hot spot [TS23.203], [TR23.896].
IPv6 addressing of hosts in a fixed IP network is described in
[TR177]. For routed Residential Gateways (RG) it is the RG that
makes the assignments. Stateful (DHCPv6) or stateless address
assignment (SLAAC) techniques are supported. For the stateless
address assignment, RG uses DHCPv6 Prefix Delegation (PD) [RFC3633].
RG is the Requesting Router (RR) and the edge router, aka Broadband
Network Gateway (BNG) is the Delegating Router. A different prefix
is requested for each access loop, e.g. home, or for each host. For
stateful address assignment, DHCP server assigns a different 64-bit
prefix per access loop or per 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 Operation
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 mobile UE and fixed device.
The edge router next initiates an IP Connectivity Access Network (IP-
CAN) session with the policy server, aka Policy and Charging
Rules Function (PCRF) to receive the Quality of Service (QoS)
Sarikaya, et al. Expires August 15, 2013 [Page 3]
Internet-Draft Prefix Sharing for FMC February 2013
parameters. Edge router via the RG provides IPv6 Prefix and assigns
to User Equipment (UE) an ID which in this case has to be equal to
the RG specific home network line ID.
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. 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.
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.
+-------------+ +-------------+
+---------------+ |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: Use Case Architecture
Sarikaya, et al. Expires August 15, 2013 [Page 4]
Internet-Draft Prefix Sharing for FMC February 2013
4. Issue Description
The RG does not signal to the edge router the IPv6 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 UE ID, IPv6 Address.
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.
In case stateless address auto configuration is used, the issue we
described here can be avoided by executing DHCPv6 PD for each host
separately. RG gets a different /64 prefix for each host from the
edge router and the edge router establishes a different IP-CAN
session for each prefix.
In case stateful address configuration is used, the issue we
described here can be avoided by DHCP server assigning IPv6 addresses
from /64 prefixes distinct for each host. Also DHCPv6 server must be
located at the edge router so that for each prefix DHCPv6 server
assigned, the edge router can establish an IP-CAN session with the
mobile network.
Note that both of the solutions described in the above two paragraphs
are optional and not all networks can be configured to assign
different IPv6 prefixes for each host.
5. IANA Considerations
This document makes no request to IANA.
6. Security Considerations
Any security considerations arising from Policy for Convergence are
TBD.
7. Acknowledgements
TBD.
Sarikaya, et al. Expires August 15, 2013 [Page 5]
Internet-Draft Prefix Sharing for FMC February 2013
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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", November 2012.
[TS23.203]
"3GPP TS23.203, Policy and Charging Control Architecture",
December 2012.
8.2. Informative References
[I-D.boucadair-intarea-host-identifier-scenarios]
Boucadair, M., Binet, D., Durel, S., Reddy, T., and B.
Williams, "Host Identification: Use Cases",
draft-boucadair-intarea-host-identifier-scenarios-02 (work
in progress), December 2012.
[I-D.ietf-intarea-nat-reveal-analysis]
Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Solution Candidates to Reveal a Host
Identifier (HOST_ID) in Shared Address Deployments",
draft-ietf-intarea-nat-reveal-analysis-04 (work in
progress), August 2012.
Authors' Addresses
Behcet Sarikaya
Huawei
5340 Legacy Dr.
Sarikaya, et al. Expires August 15, 2013 [Page 6]
Internet-Draft Prefix Sharing for FMC February 2013
Plano, TX 75074
Email: sarikaya@ieee.org
Marco Spini
Huawei
Paris,
France
Email: M.Spini@huawei.com
Dirk von Hugo
Telekom Innovation Laboratories
Deutsche-Telekom-Allee 7
D-64295 Darmstadt
Germany
Email: Dirk.von-Hugo@telekom.de
Sarikaya, et al. Expires August 15, 2013 [Page 7]
