[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                                  Jie Hu
Internet Draft                                                        Yunqing Chen
Intended status: Informational                            Huiling Zhao
Expires: April 18, 2011                                       Dongfeng Mao
                                                                              China Telecom
                                                                           October 18, 2010


                 PPPv6 Problem statement and requirements
                  draft-hu-pppext-ipv6cp-requirements-00


Abstract

   The IPv6 Control Protocol (IPv6CP) is a NCP that allows for the
   negotiation of parameters for an IPv6 interface over PPP. In IPv6
   networks, PPP (PPPoE) will still be an important mechanism for
   connecting broadband access users. However, IPv6CP only defines the
   Interface-Identifier option, other parameters such as IPv6 Address,
   Primary and alternative DNS server addresses, and delegated prefix
   have to be configured by other methods rather than IPv6CP.

   This document describes problems the ISPs faced and lists
   requirements related when deploying IPv6 in broadband access network
   over PPP.

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), 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 April 18,2011.




Hu                     Expires April 18, 2011                 [Page 1]


Internet-Draft PPPv6 Problem statement and requirements    October 2010
Copyright Notice

   Copyright (c) 2010 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.

Table of Contents


   1. Introduction ................................................................. 2
      1.1. Requirements Language................................... 2
   2. Current Practice in IPv4............................................. 3
   3. Problem Statement ................................................... 3
   4. Requirements ............................................................ 4
   5. Security Considerations............................................ 5
   6. Acknowledgments ..................................................... 5
   7. References ................................................................. 5
      7.1. Normative References........................................ 5
      7.2. Informative References....................................... 5
   Authors' address..............................................................6
1. Introduction

   The Point-to-Point Protocol (PPP) provides a standard method for
   transporting multi-protocol datagrams over point-to-point links. PPP
   defines an extensible Link Control Protocol (LCP) and a family of
   Network Control Protocols (NCPs) for establishing and configuring
   different network-layer protocols.

   In current practice, after the LCP and the authentication (if
   required) phases are completed, the corresponding network-layer
   control protocol, IPCP will be used to negotiate IP layer elements
   between subscriber devices and the BNGs.

    1.1. Requirements Language

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].




Hu                     Expires April 18, 2011                 [Page 2]


Internet-Draft PPPv6 Problem statement and requirements    October 2010
2. Current Practice in IPv4

   In current practice, after the LCP and the authentication (if
   required) phases are completed, the corresponding network-layer
   control protocol, IPCP will be used to negotiate IP layer elements
   between subscriber devices and the BNGs.

   As in IPv4, PPP is adopted to provide Internet service by a great
   many ISPs (both fixed and mobile providers) over a wide area. It is a
   simple protocol with following advantages:

   1. Robust authentication and authorization functions integrated (PAP
      or CHAP), can effectively prevent non-authorized users from
      accessing network.

   2. Each PPP session is regarded as a separate logical link/interface,
      and the process of link establishment is divided into several
      orderly phases which are scalable and feasible to be implemented.

   3. As a part of PPP, IPCP is fairly efficient. Typically, all the
      elements needed for establishing IP connectivity can be configured
      through "Configuration Options" defined in IPCP, with no extra
      control protocols or devices running these protocols introduced.

   4. As a stable method of configuring IP elements, IPCP works well for
      the Dial-on-Demand subscriber whose link may be terminated/re-
      dialed up anytime.

   5. Then, PPP can provide accurate timing and traffic flow statistics
      of network access for each subscriber. Base on that, ISPs can
      apply various kinds of policies according to different marketing
      activities.

   6. Broadband user can initiate multiple PPP sessions simultaneously,
      each PPP session is dedicated for one service, by this way
      services are distinguished and separated by PPP session, in this
      case ISP can provide different QoS profile for different service
      (PPP session).

3. Problem Statement

   While in IPv6, it is not straightforward as in IPv4. Additionally, in
   the scenario where the PPP link is initiated by a Residential Gateway,
   delegated prefix is required on the CPE as the address pool.
   Currently, the configuration of IPv6 link can't be accomplished by
   the NCP (IPv6CP) itself.

   The lack of Configuration Options defined in IPv6CP results in
   following problems:


Hu                     Expires April 18, 2011                 [Page 3]


Internet-Draft PPPv6 Problem statement and requirements    October 2010
   o The process of IP elements configuration is quite complicated.
      After entering the IPv6CP phase, one or more extra control
      protocols such as ND, DHCPv6, (and/or DHCPv6-PD) must be
      introduced, as currently there is only one configuration option
      define in IPv6CP for interface-ID negotiation.

   o The co-existence of multiple mechanisms with functionalities
      partially overlapped will lead to interoperation problems in the
      implementation.

   o More transaction steps caused by extra control protocols
      introduced will result in longer response time and higher risk of
      exception.

   o How to determine the moment when the status of IPv6CP negotiation
      comes to "OPEN", so as to get corresponding AAA activities started?

   o ISPs have to change current network infrastructure accordingly,
      such as installing DHCPv6 server somewhere in the network
      (standalone or embedded) which will not only increase both CAPEX
      and OPEX, but result in scalability problems when the number of
      subscribers grows.

   o Some unnecessary functions will be involved. For example,
      functions like Address Resolution, On-link Prefix List
      Advertisement, Default Router Advertisement, etc. defined in ND
      are actually not needed for a simple PPP link.

   o Individual active state machine has to be maintained for each
      protocol, and conflicts may exist (such as multiple lifetime
      counters)

4. Requirements

   To keep the implementation simple and stable, the problems described
   above must be solved. During the transition from IPv4 to IPv6, if
   ISPs choose to run IPv4 and IPv6 over one single PPP link for dual
   stack subscribers, it is more feasible to unify the way of
   configuring both IPv4 and IPv6.

   From the ISP's point of view, it is more reasonable to extend the
   IPv6CP functions needed for PPP by the same means of IPCP which is
   mature and widely implemented rather than introducing extra control
   protocols. To establish basic IPv6 connectivity over PPP, the
   following Configuration Options need to be defined:

   1. IPv6 address, DNS server addresses (primary and alternative), and
      Delegated-Prefix;



Hu                     Expires April 18, 2011                 [Page 4]


Internet-Draft PPPv6 Problem statement and requirements    October 2010
   Also, Configuration Options for other fucntions may be considered in
   the future:

   2. DS-Lite AFTR Address, NTP server address, etc.

5. Security Considerations

   There are no security considerations in this document.

6. Acknowledgments

   Part of this text borrows from the previous RFCs and I-Ds. And as
   such is partially based on previous work done by the PPP working
   group. Thanks to Jacni Qin, Qian Wang and Qiong Sun for useful
   feedback.
7. References

    7.1. Normative References

   [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
             RFC 1661, July 1994.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315] R. Droms, Ed, J. Bound, B. Volz, T. Lemon, C. Perkins, and
             M. Carney, "Dynamic Host Configuration Protocol for IPv6
             (DHCPv6)", RFC 3315, July 2003.

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

   [RFC3646] R. Droms, Ed, "DNS Configuration options for Dynamic Host
             Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
             December 2003.

   [RFC4861] T. Narten, E. Nordmark, W. Simpson, and  H. Soliman, "
             Neighbor Discovery for IP version 6 (IPv6)", RFC4861,
             September 2007.

   [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
             PPP", RFC 5072, September 2007.

    7.2. Informative References

   [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
             (IPCP)", RFC 1332, May 1992.



Hu                     Expires April 18, 2011                 [Page 5]


Internet-Draft PPPv6 Problem statement and requirements    October 2010
   [I-D.ietf-pppext-ipv6-dns-addr] Hiller, T. and G. Zorn, "PPP IPV6
             Control Protocol Extensions for DNS Server Addresses",
             draft-ietf-pppext-ipv6-dns-addr-03 (work in progress), June
             2003.

   [draft-qin-pppext-ipv6-addr-pref]  Y. Li, J. Qin, and L. Yuan, " PPP
             IPv6 Control Protocol Extensions for Address and Prefix",
             draft-qin-pppext-ipv6-addr-pref-00, January 2010.

   [draft-huang-ipv6cp-options] J. Huang, " IPv6CP Options for PPP Host
             Configuration", draft-huang-ipv6cp-options-00, February 3,
             2010.

Authors' Addresses

   Jie Hu
   China Telecom Beijing Research Institute
   Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035
   China

   Phone: <86 10 58552808>
   Email: huj@ctbri.com.cn


   Yunqing Chen
   China Telecom Beijing Research Institute
   Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035
   China

   Phone: <86 10 58552102>
   Email: chenyq@ctbri.com.cn

   Huiling Zhao
   China Telecom Beijing Research Institute
   Room 502 No.118, Xizhimenneidajie, xicheng District Beijing 100035
   China

   Phone: <86 10 58552002>
   Email: zhaohl@ctbri.com.cn

   Dongfeng Mao
   China Telecom
   No.31, Jinrong Ave, Xicheng District,100032

   Phone: <86 10 58501809>
   Email: maodf@chinatelecom.com.cn





Hu                     Expires April 18, 2011                 [Page 6]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/