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]