idnits 2.17.1 draft-hu-pppext-ipv6cp-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 19 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 18, 2010) is 4938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1661' is defined on line 212, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 218, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 222, but no explicit reference was found in the text == Unused Reference: 'RFC3646' is defined on line 226, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 230, but no explicit reference was found in the text == Unused Reference: 'RFC5072' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'RFC1332' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pppext-ipv6-dns-addr' is defined on line 242, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jie Hu 2 Internet Draft Yunqing Chen 3 Intended status: Informational Huiling Zhao 4 Expires: April 18, 2011 Dongfeng Mao 5 China Telecom 6 October 18, 2010 8 PPPv6 Problem statement and requirements 9 draft-hu-pppext-ipv6cp-requirements-00 11 Abstract 13 The IPv6 Control Protocol (IPv6CP) is a NCP that allows for the 14 negotiation of parameters for an IPv6 interface over PPP. In IPv6 15 networks, PPP (PPPoE) will still be an important mechanism for 16 connecting broadband access users. However, IPv6CP only defines the 17 Interface-Identifier option, other parameters such as IPv6 Address, 18 Primary and alternative DNS server addresses, and delegated prefix 19 have to be configured by other methods rather than IPv6CP. 21 This document describes problems the ISPs faced and lists 22 requirements related when deploying IPv6 in broadband access network 23 over PPP. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on April 18,2011. 47 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents carefully, 56 as they describe your rights and restrictions with respect to this 57 document. Code Components extracted from this document must include 58 Simplified BSD License text as described in Section 4.e of the Trust 59 Legal Provisions and are provided without warranty as described in 60 the Simplified BSD License. 62 Table of Contents 64 1. Introduction ................................................................. 2 65 1.1. Requirements Language................................... 2 66 2. Current Practice in IPv4............................................. 3 67 3. Problem Statement ................................................... 3 68 4. Requirements ............................................................ 4 69 5. Security Considerations............................................ 5 70 6. Acknowledgments ..................................................... 5 71 7. References ................................................................. 5 72 7.1. Normative References........................................ 5 73 7.2. Informative References....................................... 5 74 Authors' address..............................................................6 75 1. Introduction 77 The Point-to-Point Protocol (PPP) provides a standard method for 78 transporting multi-protocol datagrams over point-to-point links. PPP 79 defines an extensible Link Control Protocol (LCP) and a family of 80 Network Control Protocols (NCPs) for establishing and configuring 81 different network-layer protocols. 83 In current practice, after the LCP and the authentication (if 84 required) phases are completed, the corresponding network-layer 85 control protocol, IPCP will be used to negotiate IP layer elements 86 between subscriber devices and the BNGs. 88 1.1. Requirements Language 90 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 91 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 92 document, are to be interpreted as described in [RFC2119]. 94 2. Current Practice in IPv4 96 In current practice, after the LCP and the authentication (if 97 required) phases are completed, the corresponding network-layer 98 control protocol, IPCP will be used to negotiate IP layer elements 99 between subscriber devices and the BNGs. 101 As in IPv4, PPP is adopted to provide Internet service by a great 102 many ISPs (both fixed and mobile providers) over a wide area. It is a 103 simple protocol with following advantages: 105 1. Robust authentication and authorization functions integrated (PAP 106 or CHAP), can effectively prevent non-authorized users from 107 accessing network. 109 2. Each PPP session is regarded as a separate logical link/interface, 110 and the process of link establishment is divided into several 111 orderly phases which are scalable and feasible to be implemented. 113 3. As a part of PPP, IPCP is fairly efficient. Typically, all the 114 elements needed for establishing IP connectivity can be configured 115 through "Configuration Options" defined in IPCP, with no extra 116 control protocols or devices running these protocols introduced. 118 4. As a stable method of configuring IP elements, IPCP works well for 119 the Dial-on-Demand subscriber whose link may be terminated/re- 120 dialed up anytime. 122 5. Then, PPP can provide accurate timing and traffic flow statistics 123 of network access for each subscriber. Base on that, ISPs can 124 apply various kinds of policies according to different marketing 125 activities. 127 6. Broadband user can initiate multiple PPP sessions simultaneously, 128 each PPP session is dedicated for one service, by this way 129 services are distinguished and separated by PPP session, in this 130 case ISP can provide different QoS profile for different service 131 (PPP session). 133 3. Problem Statement 135 While in IPv6, it is not straightforward as in IPv4. Additionally, in 136 the scenario where the PPP link is initiated by a Residential Gateway, 137 delegated prefix is required on the CPE as the address pool. 138 Currently, the configuration of IPv6 link can't be accomplished by 139 the NCP (IPv6CP) itself. 141 The lack of Configuration Options defined in IPv6CP results in 142 following problems: 144 o The process of IP elements configuration is quite complicated. 145 After entering the IPv6CP phase, one or more extra control 146 protocols such as ND, DHCPv6, (and/or DHCPv6-PD) must be 147 introduced, as currently there is only one configuration option 148 define in IPv6CP for interface-ID negotiation. 150 o The co-existence of multiple mechanisms with functionalities 151 partially overlapped will lead to interoperation problems in the 152 implementation. 154 o More transaction steps caused by extra control protocols 155 introduced will result in longer response time and higher risk of 156 exception. 158 o How to determine the moment when the status of IPv6CP negotiation 159 comes to "OPEN", so as to get corresponding AAA activities started? 161 o ISPs have to change current network infrastructure accordingly, 162 such as installing DHCPv6 server somewhere in the network 163 (standalone or embedded) which will not only increase both CAPEX 164 and OPEX, but result in scalability problems when the number of 165 subscribers grows. 167 o Some unnecessary functions will be involved. For example, 168 functions like Address Resolution, On-link Prefix List 169 Advertisement, Default Router Advertisement, etc. defined in ND 170 are actually not needed for a simple PPP link. 172 o Individual active state machine has to be maintained for each 173 protocol, and conflicts may exist (such as multiple lifetime 174 counters) 176 4. Requirements 178 To keep the implementation simple and stable, the problems described 179 above must be solved. During the transition from IPv4 to IPv6, if 180 ISPs choose to run IPv4 and IPv6 over one single PPP link for dual 181 stack subscribers, it is more feasible to unify the way of 182 configuring both IPv4 and IPv6. 184 From the ISP's point of view, it is more reasonable to extend the 185 IPv6CP functions needed for PPP by the same means of IPCP which is 186 mature and widely implemented rather than introducing extra control 187 protocols. To establish basic IPv6 connectivity over PPP, the 188 following Configuration Options need to be defined: 190 1. IPv6 address, DNS server addresses (primary and alternative), and 191 Delegated-Prefix; 193 Also, Configuration Options for other fucntions may be considered in 194 the future: 196 2. DS-Lite AFTR Address, NTP server address, etc. 198 5. Security Considerations 200 There are no security considerations in this document. 202 6. Acknowledgments 204 Part of this text borrows from the previous RFCs and I-Ds. And as 205 such is partially based on previous work done by the PPP working 206 group. Thanks to Jacni Qin, Qian Wang and Qiong Sun for useful 207 feedback. 208 7. References 210 7.1. Normative References 212 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 213 RFC 1661, July 1994. 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC3315] R. Droms, Ed, J. Bound, B. Volz, T. Lemon, C. Perkins, and 219 M. Carney, "Dynamic Host Configuration Protocol for IPv6 220 (DHCPv6)", RFC 3315, July 2003. 222 [RFC3633] O. Troan, R. Droms, "IPv6 Prefix Options for Dynamic Host 223 Configuration Protocol (DHCP) version 6", RFC 3633, 224 December 2003. 226 [RFC3646] R. Droms, Ed, "DNS Configuration options for Dynamic Host 227 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 228 December 2003. 230 [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, " 231 Neighbor Discovery for IP version 6 (IPv6)", RFC4861, 232 September 2007. 234 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 235 PPP", RFC 5072, September 2007. 237 7.2. Informative References 239 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 240 (IPCP)", RFC 1332, May 1992. 242 [I-D.ietf-pppext-ipv6-dns-addr] Hiller, T. and G. Zorn, "PPP IPV6 243 Control Protocol Extensions for DNS Server Addresses", 244 draft-ietf-pppext-ipv6-dns-addr-03 (work in progress), June 245 2003. 247 [draft-qin-pppext-ipv6-addr-pref] Y. Li, J. Qin, and L. Yuan, " PPP 248 IPv6 Control Protocol Extensions for Address and Prefix", 249 draft-qin-pppext-ipv6-addr-pref-00, January 2010. 251 [draft-huang-ipv6cp-options] J. Huang, " IPv6CP Options for PPP Host 252 Configuration", draft-huang-ipv6cp-options-00, February 3, 253 2010. 255 Authors' Addresses 257 Jie Hu 258 China Telecom Beijing Research Institute 259 Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035 260 China 262 Phone: <86 10 58552808> 263 Email: huj@ctbri.com.cn 265 Yunqing Chen 266 China Telecom Beijing Research Institute 267 Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035 268 China 270 Phone: <86 10 58552102> 271 Email: chenyq@ctbri.com.cn 273 Huiling Zhao 274 China Telecom Beijing Research Institute 275 Room 502 No.118, Xizhimenneidajie, xicheng District Beijing 100035 276 China 278 Phone: <86 10 58552002> 279 Email: zhaohl@ctbri.com.cn 281 Dongfeng Mao 282 China Telecom 283 No.31, Jinrong Ave, Xicheng District,100032 285 Phone: <86 10 58501809> 286 Email: maodf@chinatelecom.com.cn