idnits 2.17.1 draft-hu-pppext-ipv6cp-requirements-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4764 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1661' is defined on line 193, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 203, but no explicit reference was found in the text == Unused Reference: 'RFC3646' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 211, but no explicit reference was found in the text == Unused Reference: 'RFC5072' is defined on line 215, but no explicit reference was found in the text == Unused Reference: 'I-D.huang-ipv6cp-options' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pppext-ipv6-dns-addr' is defined on line 225, but no explicit reference was found in the text == Unused Reference: 'I-D.qin-pppext-ipv6-addr-pref' is defined on line 231, but no explicit reference was found in the text == Unused Reference: 'RFC1332' is defined on line 237, 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: 2 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Pppext WG Jie. Hu 3 Internet-Draft Yunqing. Chen 4 Intended status: Standards Track Dongfeng. Mao 5 Expires: September 15, 2011 China Telecom 6 Haoxin. Tang 7 China Unicom 8 March 14, 2011 10 PPPv6 Problem statement and requirements 11 draft-hu-pppext-ipv6cp-requirements-01 13 Abstract 15 As in IPv4 network, PPP (PPPoE) will still be an important mechanism 16 to provide access services to broadband subscribers of IPv6 or dual- 17 stack. This document describes problems the ISPs faced when 18 deploying IPv6 in broadband access network over PPP, particularly, 19 the capabilities lacked in IPv6CP. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 15, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 69 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 79 1. Introduction 81 The Point-to-Point Protocol (PPP) provides a standard method for 82 transporting multi-protocol datagrams over point-to-point links. PPP 83 defines an extensible Link Control Protocol (LCP) and a family of 84 Network Control Protocols (NCPs) for establishing and configuring 85 different network-layer protocols. 87 While based on the current capabilities of the IPv6 Control Protocol 88 ( IPv6CP) which is used for the negotiation of IPv6 parameters over 89 PPP, only Interface-Identifier can be negotiated, other parameters 90 such as IPv6 Address, DNS server addresses and delegated prefix have 91 to be configured by other means rather than IPv6CP. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Problem Statement 101 In current practice, after the LCP and the authentication (if 102 required ) phases are completed, the corresponding network-layer 103 control protocol, IPCP will be used to negotiate all the IP layer 104 elements needed between subscriber devices and the Broadband Network 105 Gateway ( BNG). This is fairly an efficient and robust means which 106 collaborates quite well with other mechanisms like those for AAA, 107 when providing access services in variable environments. 109 While in IPv6 currently the configuration of IPv6 link can't be 110 accomplished by the NCP (IPv6CP) itself. The lack of Configuration 111 Options defined in IPv6CP results in following problems: 113 1. The process of IP elements configuration is quite complicated. 114 After entering the IPv6CP phase, one or more extra control 115 protocols such as ND, DHCPv6, (and/or DHCPv6-PD) must be 116 introduced, as currently there is only one configuration option 117 define in IPv6CP for interface-ID negotiation. Additionally, the 118 status 'OPEN' of IPv6CP negotiation cannot be treated as the sign 119 of access service!_s ready and triggers corresponding AAA 120 activities, for instance' Accounting START'. 122 2. Some unnecessary functions will be involved. For example, 123 functions like Address Resolution, On-link Prefix List 124 Advertisement, Default Router Advertisement, etc. defined in ND 125 are actually not needed for a simple PPP link. 127 3. The co-existence of multiple protocols with functionalities 128 partially overlapped will lead to interoperation problems in the 129 implementation as individual active state machine has to be 130 maintained for each protocol which can result in conflicts (such 131 as multiple lifetime counters). Additionally, more transaction 132 steps caused by extra control protocols introduced will result in 133 longer response time and higher risk of exception. 135 4. ISPs have to change current network infrastructure accordingly, 136 such as installing new DHCPv6 servers somewhere in the network ( 137 standalone or embedded) which will increase both CAPEX and OPEX. 139 5. Some unnecessary functions will be involved. For example, 140 functions like Address Resolution, On-link Prefix List 141 Advertisement, Default Router Advertisement, etc. defined in ND 142 are actually not needed for a simple PPP link. 144 6. At the LNS, if we filter traffic to be from the router IP 145 addresses on all of our DSL lines to avoid spoofing, the FE80:: 146 link local address is not allowed through the source filtering as 147 it is link local and so not allowed on to the network. This 148 filtering has to be modified to allow FE80:: addresses for SLAAC 149 or DHCPv6 but then be blocked at a later stage. 151 3. Requirements 153 To keep the implementation simple and stable, the problems described 154 above must be solved. During the transition from IPv4 to IPv6, if 155 ISPs choose to run IPv4 and IPv6 over one single PPP link for dual- 156 stack subscribers, it is more feasible to unify the way of 157 configuring both IPv4 and IPv6. 159 From the ISP's point of view, it is more reasonable to extend the 160 IPv6CP functions needed for PPP by the same means of IPCP which is 161 mature and widely implemented rather than introducing extra control 162 protocols. To establish basic IPv6 connectivity over PPP, the 163 following Configuration Options need to be defined: 165 1. IPv6 address; 167 2. Delegated IPv6 prefix; 169 3. DNS server addresses (primary and alternative); 171 Also, Configuration Options for other functions may be considered in 172 the future. 174 4. Acknowledgements 176 Part of this text borrows from the previous RFCs and I-Ds. And as 177 such is partially based on previous work done by the PPP working 178 group. Thanks to Jacni Qin, Qian Wang and Qiong Sun for useful 179 feedback. 181 5. IANA Considerations 183 This document includes no request to IANA. 185 6. Security Considerations 187 No new security concerns raised out of this document. 189 7. References 191 7.1. Normative References 193 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 194 RFC 1661, July 1994. 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, March 1997. 199 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 200 and M. Carney, "Dynamic Host Configuration Protocol for 201 IPv6 (DHCPv6)", RFC 3315, July 2003. 203 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 204 Host Configuration Protocol (DHCP) version 6", RFC 3633, 205 December 2003. 207 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 208 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 209 December 2003. 211 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 212 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 213 September 2007. 215 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 216 PPP", RFC 5072, September 2007. 218 7.2. Informative References 220 [I-D.huang-ipv6cp-options] 221 Huang, J., "IPv6CP Options for PPP Host Configuration", 222 draft-huang-ipv6cp-options-00 (work in progress), 223 February 2010. 225 [I-D.ietf-pppext-ipv6-dns-addr] 226 Hiller, T. and G. Zorn, "PPP IPV6 Control Protocol 227 Extensions for DNS Server Addresses", 228 draft-ietf-pppext-ipv6-dns-addr-03 (work in progress), 229 June 2003. 231 [I-D.qin-pppext-ipv6-addr-pref] 232 Li, Y., Qin, J., and L. Yuan, "PPP IPv6 Control Protocol 233 Extensions for Address and Prefix", 234 draft-qin-pppext-ipv6-addr-pref-00 (work in progress), 235 February 2010. 237 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 238 (IPCP)", RFC 1332, May 1992. 240 Authors' Addresses 242 Jie Hu 243 China Telecom 244 Room 708 No.118, Xizhimenneidajie 245 Beijing, 100035 246 China 248 Phone: +86 10 5855 2808 249 Email: huj@ctbri.com.cn 251 Yunqing Chen 252 China Telecom 253 Room 708 No.118, Xizhimenneidajie 254 Beijing, 100035 255 China 257 Phone: +86 10 5855 2102 258 Email: chenyq@ctbri.com.cn 259 Dongfeng Mao 260 China Telecom 261 No.31, Jinrong Ave 262 Beijing, 100032 263 China 265 Phone: +86 10 5850 1809 266 Email: maodf@chinatelecom.com.cn 268 Haoxin Tang 269 China Unicom 270 No.13, Jinrong Ave 271 Beijing, 100035 272 China 274 Phone: +86 1860 110 1695 275 Email: tanghx@chinaunicom.cn