[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                        S. Krishnan
Internet-Draft                                                F. Garneij
Intended status: Standards Track                                Ericsson
Expires: August 28, 2010                                     J. Korhonen
                                                  Nokia Siemens Networks
                                                           T. Savolainen
                                                                   Nokia
                                                       February 24, 2010


           Prefix Delegation in Evolved Packet Core networks
                    draft-krishnan-intarea-pd-epc-00

Abstract

   This document describes the operation of IPv6 prefix delegation in
   the 3GPP evolved packet core networks.  It also identifies a
   deficiency in the current prefix delegation mechanism and proposes a
   fix.

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 August 28, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Krishnan, et al.         Expires August 28, 2010                [Page 1]


Internet-Draft          Prefix Delegation in EPC           February 2010


   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 BSD License.


Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Optimizing prefix delegation  . . . . . . . . . . . . . . . . . 3
   4.  PCC impacts . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  DHCPv6 Prefix delegation problem  . . . . . . . . . . . . . . . 6
     5.1.  Problem description and solution proposal . . . . . . . . . 6
     5.2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

























Krishnan, et al.         Expires August 28, 2010                [Page 2]


Internet-Draft          Prefix Delegation in EPC           February 2010


1.  Requirements notation

   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 [RFC2119].


2.  Introduction

   In the current evolved packet core (EPC) networks every User
   Equipment (UE) is allocated a /64 prefix as described in
   [I-D.korhonen-v6ops-3gpp-eps] and similarly for the General Packet
   Radio Services (GPRS) in [RFC3314].  If the UE needs to act as a
   router and support a network behind it, it requires a shorter prefix
   to be delegated to it.  To support this, the EPC network can reserve
   a shorter prefix (e.g. a /56) for the UE even before the UE requests
   delegation of a prefix.


3.  Optimizing prefix delegation

   A carefully planned prefix delegation model can help with minimizing
   the impact on the routing and policy control infrastructures.
   Irrespective of the length of the shorter prefix or the method used
   for delegation, it is preferable that the initial /64 assigned to the
   UE be a part of the shorter prefix intended to be delegated to the
   UE.


4.  PCC impacts

   The Policy & Charging Control Architecture (PCC) provides network
   control regarding the service data flow detection, gating & QoS
   towards the PCEF (Policy Control Enforcement Function) and the BBERF
   (Bearer Binding and Event Reporting Function).  In addition PCC also
   provides network control of flow based charging towards the PCEF.
   The main objective of PCC is to interconnect the signaling plane with
   the data plane to provide policy, QoS control and charging.  To
   achieve this interconnection PCC performs session binding as
   described in [3GPP.23.203] Section 6.1.1.2.  Session binding requires
   a match between the AF session (Rx signalling interface) and IP-CAN
   session [3GPP.32.251] parameters.  For an IPv6 session the IP-CAN
   parameter containing the UE IPv6 prefix is the DIAMETER Framed-IPv6-
   Prefix AVP defined in [RFC4005].  An IP-CAN Session can only contain
   one Framed-IPv6-Prefix AVP.  [RFC3162] defines the following coding
   of the Framed-IPv6-Prefix AVP:





Krishnan, et al.         Expires August 28, 2010                [Page 3]


Internet-Draft          Prefix Delegation in EPC           February 2010


   Framed-IPv6-Prefix

    Description

       This Attribute indicates an IPv6 prefix (and corresponding route)
       to be configured for the user.  It MAY be used in Access-Accept
       packets, and can appear multiple times.  It MAY be used in an
       Access-Request packet as a hint by the NAS to the server that it
       would prefer these prefix(es), but the server is not required to
       honor the hint.  Since it is assumed that the NAS will plumb a
       route corresponding to the prefix, it is not necessary for the
       server to also send a Framed-IPv6-Route attribute for the same
       prefix.

       A summary of the Framed-IPv6-Prefix Attribute format is shown
       below. The fields are transmitted from left to right.

       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     |  Reserved     | Prefix-Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   Prefix
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   Prefix
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   Prefix
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   Prefix                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         97 for Framed-IPv6-Prefix

      Length

         At least 4 and no larger than 20.

      Reserved

         This field, which is reserved and MUST be present, is always
         set to zero.

      Prefix-Length

         The length of the prefix, in bits.  At least 0 and no larger
         than 128.



Krishnan, et al.         Expires August 28, 2010                [Page 4]


Internet-Draft          Prefix Delegation in EPC           February 2010


      Prefix

         The Prefix field is up to 16 octets in length.  Bits outside
         of the Prefix-Length, if included, must be zero.

                            Framed-IPv6-Prefix

   Looking at this definition it can be recognized that if the original
   Prefix-Length value, contained here after a initial UE PDN Connection
   is established, may be changed to a shorter prefix if obtained by the
   UE using prefix delegation mechanism.  If the original IPv6 prefix is
   part of the shorter delegated IPv6 prefix as described below example,
   updating the Prefix-Length field in the Framed-IPv6-Prefix AVP would
   allow for successful session binding for all addresses contained
   within the delegated prefix.

   A 2001:db8:4000:FF00::/56 delegation example:

   o  UE request IPv6 prefix using existing 3GPP defined procedures

   o  As an exception from existing mechanisms there is a reservation
      for a /56 IPv6 prefix for the requesting UE, possibly configured
      per Access Point Name (APN) for the subscriber.  However, this
      step does not change the existing PDN Connection setup signaling

   o  SLAAC returns "the last/highest" or "the first/lowest" /64 IPv6
      prefix of the reserved prefix using existing 3GPP defined
      procedures (e.g. 2001:db8:4000:FFFF::/64)

   o  Extend initial 2001:db8:4000:FFFF::/64 to 2001:db8:4000:FF00:/56
      by using DHCPv6 PD

   o  GW perform IP-CAN session modification

   o  UE uplink subnet is kept as the initial received prefix 2001:db8:
      4000:FFFF::/64

   o  Available /64 interface subnets 2001:db8:4000:FF00-FFFE::/64

   o  First available subnet for UE downlink interfaces 2001:db8:4000:
      FF00::/64

   o  Last available subnet for UE downlink interfaces 2001:db8:4000:
      FFFE::/64

   If the IP-CAN session Framed-IPv6-Prefix AVP Length field is modified
   to represent a shorter prefix (from 64 to 56) a match can be made to
   all /64 that are included in the shorter prefix including the UE



Krishnan, et al.         Expires August 28, 2010                [Page 5]


Internet-Draft          Prefix Delegation in EPC           February 2010


   initial /64 received using existing 3GPP defined procedures.

   Impact on PCC would be minimal if the following applies:

   o  Keep current restrictions on only one IPv4 address and only one
      IPv6 prefix for a single connection (PDP Context/PDN Connection)

   o  Allow a shorter prefix length for a single connection (PDP
      Context/PDN Connection)

   o  Add possibility to adjust prefix length within a connection


5.  DHCPv6 Prefix delegation problem

5.1.  Problem description and solution proposal

   The IPv6 Prefix Options for DHCPv6 document [RFC3633] specifies a
   mechanism for using DHCPv6 for delegating prefixes from a delegating
   router to a requesting router.  This mechanism is very well suited
   for use in EPC networks but it has a restriction that limits its
   usage.  Section 12.1 of [RFC3633] contains the following text "..the
   requesting router MUST NOT assign any delegated prefixes or subnets
   from the delegated prefix(es) to the link through which it received
   the DHCP message from the delegating router." that does not allow the
   UE to use a /64 out of the delegated prefix on the interface where it
   received the delegation.  This restriction means that two different
   prefixes need to be allocated for each UE (one /64 and one shorter)
   and this causes a significant impact on the routing and policy
   infrastructures.  This draft recommends that this restriction be
   removed for UEs in EPC networks.

5.2.  Discussion

   Although the solution for the DHCPv6 prefix delegation problem is
   only scoped to cover 3GPP EPC networks, there are still concerns
   whether the solution is fully backward compatible with all possible
   deployment models.  There are concerns that network identifying UE's
   EPC readiness is not sufficient.  Especially the model where the 3GPP
   capable UE is only acting as a 'bridge-like' modem, for example, for
   a notebook where the host IP stack is running.  The actual prefix
   delegation request originates from the notebook IP stack.  This
   particular deployment model has to be verified whether it can be
   deployed without breaking IP and existing stack implementations that
   also understand prefix delegation.






Krishnan, et al.         Expires August 28, 2010                [Page 6]


Internet-Draft          Prefix Delegation in EPC           February 2010


6.  IANA Considerations

   This document does not require any IANA action.


7.  Security Considerations

   The be defined in later revision of this specification.


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.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

8.2.  Informative References

   [3GPP.23.203]
              3GPP, "Policy and charging control architecture", 3GPP
              TS 23.203 7.12.0, December 2009.

   [3GPP.32.251]
              3GPP, "Telecommunication management; Charging management;
              Packet Switched (PS) domain charging", 3GPP TS 32.251
              6.10.0, June 2007.

   [I-D.korhonen-v6ops-3gpp-eps]
              Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
              Bajko, G., and K. Iisakkila, "IPv6 in 3GPP Evolved Packet
              System", draft-korhonen-v6ops-3gpp-eps-00 (work in
              progress), February 2010.

   [RFC3162]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
              RFC 3162, August 2001.

   [RFC3314]  Wasserman, M., "Recommendations for IPv6 in Third
              Generation Partnership Project (3GPP) Standards",
              RFC 3314, September 2002.

   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              August 2005.



Krishnan, et al.         Expires August 28, 2010                [Page 7]


Internet-Draft          Prefix Delegation in EPC           February 2010


Authors' Addresses

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com


   Fredrik Garneij
   Ericsson

   Email: fredrik.garneij@ericsson.com


   Jouni Korhonen
   Nokia Siemens Networks

   Email: jouni.nospam@gmail.com


   Teemu Savolainen
   Nokia

   Email: teemu.savolainen@nokia.com























Krishnan, et al.         Expires August 28, 2010                [Page 8]