idnits 2.17.1 draft-shirasaki-dualstack-service-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2003) is 7498 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: 'PD-Req' is defined on line 364, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3177 (Obsoleted by RFC 6177) ** Obsolete normative reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) ** Downref: Normative reference to an Informational RFC: RFC 2516 ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Possible downref: Normative reference to a draft: ref. 'WKSLDNS' == Outdated reference: A later version (-03) exists of draft-ietf-dhc-dhcpv6-opt-timeconfig-02 == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-prefix-delegation-requirement-03 Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Y. Shirasaki 3 Expires: April, 2004 S. Miyakawa 4 T. Yamasaki 5 A. Takenouchi 6 NTT Communications 7 October 15, 2003 9 A Model of IPv6/IPv4 Dual Stack Internet Access Service 10 draft-shirasaki-dualstack-service-02.txt 12 Status of this Memo 14 This memo provides information to the Internet community. It does not 15 specify an Internet standard of any kind. This memo is in full 16 conformance with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 The internet-draft will expire in 6 months. The date of expiration 34 will be April 14, 2004. 36 Abstract 38 This memo shows an example of how to provide IPv6 / IPv4 dual stack 39 services to home users. In order to simplify user setup, these 40 services should have a mechanism to configure IPv6 specific 41 parameters automatically. We focus on two basic parameters, the 42 prefix assigned to the user and the addresses of IPv6 DNS servers, 43 and specify the way to deliver them to Customer Premises Equipments 44 (CPE) automatically. 46 This memo is a digest of the user network interface specification of 47 NTT communications' dual stack ADSL access service. 49 1. Introduction 51 This memo describes two topics. One is the architecture of IPv6/IPv4 52 dual stack access service. The other is the automatic configuration 53 function for IPv6 specific parameters. 55 The architecture is mainly targeted at a leased line ADSL service for 56 home users. It assumes that there is a Point-to-Point Protocol (PPP) 57 logical link between CPE and Provider Edge (PE). In order to exclude 58 factors which are specific to access lines from this architecture, we 59 only specify PPP and its upper layers. To satisfy [RFC3177], the 60 length of prefix which is delegated to CPE is /48, but /64 is also a 61 possible option. 63 In this architecture, IPv6/IPv4 dual stack service is specified as 64 follows. 66 o IPv6 and IPv4 connectivities are provided over a single PPP 67 logical link. 69 o IPv6 connectivity is independent of IPv4 connectivity. IPV6CP 70 and IPCP work independently over a single PPP logical link. 72 Figure 1 shows the outline of the service architecture. NTT 73 Communications is providing a commercial service based on this 74 architecture since the Summer 2002. 76 | _____________ 77 [HOST]-+ +-----------+ +----------+ / \ 78 | | Customer | ADSL line | Provider | | ISP core and | 79 +-+ Premises +---------------+ Edge |--| The internet | 80 | | Equipment | to subscriber +-----+----+ \_____________/ 81 [HOST]-+ +-----------+ | | | 82 | +-----+------+ | +-+----------+ 83 | AAA server | | | DNS server | 84 +------------+ | +------------+ 85 +-+--------------+ 86 | NTP server etc.| 87 +----------------+ 89 Figure 1: Dual stack access service architecture 91 The automatic configuration function aims at simplification of user 92 setup. Usually, users have to configure at least two IPv6 specific 93 parameters, prefix(es) assigned to them and IPv6 DNS servers' 94 addresses. The function is composed of two sub-functions as below. 96 o Delegation of prefix(es) to be used in the user site 98 o Notification of IPv6 DNS server addresses, and/or other server 99 addresses 101 Section 2 of this memo details user network interface. Section 3 102 describes an example of connection sequence. 104 2. User Network Interface 106 In this section, details of the user network interface specification 107 are described. Only PPP over Ethernet (PPPoE) and its upper layers 108 are mentioned. The other layers such as Ethernet and lower layers are 109 out of scope. IPv4 related parameter configuration is also out of 110 scope. 112 2.1. Below the IP Layer 114 The service uses PPP connection and Challenge Handshake 115 Authentication Protocol (CHAP) authentication to identify each CPE. 116 Both CPE and PE handle both IPCP [RFC1661] and IPV6CP [RFC2472] 117 identically / simultaneously over a single PPP connection. It means 118 either CPE or PE can open/close any Network Control Protocol (NCP) 119 session anytime without any side-effect for each other. It is 120 intended that users can choose between three services, IPv4 only, 121 IPv6 only and IPv4/IPv6 dual stack. A CPE connected to an ADSL line 122 discovers a PE with PPPoE mechanism [RFC2516]. 124 Note that because CPE and PE can negotiate only their interface 125 identifiers with IPV6CP, PE and CPE can use only link-local scope 126 addresses before the prefix delegation mechanism, described below, is 127 run. 129 2.2. IP Layer 131 After IPV6CP negotiation, the CPE initiates a prefix delegation 132 request. The PE chooses global-scope prefix for the CPE with 133 information from an Authentication, Authorization, and Accounting 134 (AAA) server or local prefix pools, and delegates the prefix to the 135 CPE. Once the prefix is delegated, the prefix is subnetted and 136 assigned to the local interfaces of the CPE. The CPE begins sending 137 router advertisement of the prefixes on each links. Eventually hosts 138 can acquire global-scope prefixes through conventional IPv6 stateless 139 [RFC2462] or stateful auto-configuration mechanisms [RFC3315] etc, 140 and become to communicate using global-scope addresses. 142 2.3. Prefix Delegation 143 PE delegates prefixes to CPE by DHCPv6 [RFC3315] with prefix 144 delegation options [PD]. The model of sequence for prefix delegation 145 is as follows: 147 o A CPE requests prefix(es) from a PE by sending a DHCPv6 Solicit 148 message which has a link-local source address negotiated by 149 IPV6CP, mentioned in the previous section, and includes an IA_PD 150 option. 152 o An AAA server notifies prefix(es) to the PE, or the PE chooses 153 prefix(es) from its local pool and the PE returns an Advertise 154 message which contains an IA_PD option and IA_PD Prefix options. 155 The prefix-length in the IA_PD Prefix option is 48. 157 o The CPE chooses prefix(es) and sends a Request message containing 158 an IA_PD option and IA_PD Prefix options for chosen prefix(es) 159 back to the PE. 161 o The PE confirms the prefix(es) in the Request message and returns 162 a Reply message. 164 If IPV6CP is terminated or restarted by any reason, CPE must initiate 165 a Rebind/Reply message exchange as described in [PD]. 167 2.4. Address Assignment 169 CPE assigns global-scope /64 prefixes subnetted from the delegated 170 prefix to its downstream interfaces. In the case where the delegated 171 prefix has infinite lifetimes, the preferred and valid lifetimes of 172 assigned /64 prefixes should be their default values in [RFC2461]. 174 Because a link-local address is already assigned to CPE's upstream 175 interface, global-scope address assignment for that interface is 176 optional. 178 2.5. Routing 180 CPE and PE use static routing between them, and no routing protocol 181 traffic is necessary. 183 CPE configures its PPPoE logical interface or the link-local address 184 of PE as IPv6 default gateway automatically after the prefix 185 delegation exchange. 187 When CPE receives packets which are destined for the addresses in the 188 delegated /48 prefix, CPE must not forward the packets to a PE. CPE 189 should return ICMPv6 Destination Unreachable message to a source 190 address or silently discard the packets, when the original packet is 191 destined for the unassigned prefix in the delefated prefix. (e.g. 192 CPE should install a reject route or null interface as next hop for 193 the delegated prefix.) 195 2.6. Obtaining Addresses of DNS Servers 197 The service provides IPv6 recursive DNS servers in the ISP site. PE 198 notifies the global unicast addresses of these servers with Domain 199 Name Server option, which is described in [OPT-DNS], in 200 Advertise/Reply messages on the prefix delegation message exchange. 202 Devices connected to user network use the CPE as recursive DNS server 203 with the mechanism described in [WKSLDNS]. This is easy to implement, 204 because it is an analogy of IPv4 SOHO router (192.168.0.1 is a DNS 205 proxy server and a default router in most sites). 207 Issue: Because site-local unicast addresses, which is used in 208 [WKSLDNS], began to be deprecated, we need new standard mechanism to 209 discovery or communicate recursive DNS servers for devices connected 210 to user network. 212 2.7. Miscellaneous Information 214 PE may notify other IPv6 enabled server addresses such as Network 215 Time Protocol servers [OPT-NTP], SIP servers [RFC3319], etc. in an 216 Advertise/Reply messages on the prefix delegation message exchange if 217 those are available. 219 2.8. Connectivity Monitoring 221 ICMPv6 Echo Request will be sent to user network for connectivity 222 monitoring in the service. CPE must return single IPv6 Echo Reply 223 packet when it receives ICMPv6 Echo Request packet. The health check 224 packets are destined for subnet-router anycast address for the 225 delegated prefix. 227 The old document of APNIC IPv6 address assignment policy required 228 that APNIC could ping the subnet anycast address to check an address 229 usage. 231 To achieve this requirement, for example, once the prefix 232 3ffe:ffff:ffff::/48 is delegated, the CPE must reply to the ICMPv6 233 Echo Request destined for 3ffe:ffff:ffff:: anytime while IPV6CP and 234 DHCPv6-PD for upstream is up. Because some implementations couldn't 235 reply when 3ffe:ffff:ffff::/64 was assigned to its downstream 236 physical interface and the interface is down, such implementation 237 should assign 3ffe:ffff:ffff::/64 for loopback interface, which is 238 always up, and 3ffe:ffff:ffff:1::/64, 3ffe:ffff:ffff:2::/64, etc. for 239 physical interfaces. 241 3. An Example of Connection Sequence 243 Following figure is an example of normal link-up sequence from start 244 of PPPoE to start of IPv6/IPv4 communications. IPv4 communication 245 becomes available after IPCP negotiation. IPv6 communication with 246 link-local scope addresses becomes possible after IPV6CP negotiation. 247 IPv6 communication with global-scope addresses becomes possible after 248 prefix delegation and conventional IPv6 address configuration 249 mechanism. IPCP is independent of IPV6CP and prefix delegation. 251 CPE PE 252 | | 253 |----------PADI-------->| \ 254 |<---------PADO---------| | PPPoE 255 |----------PADR-------->| | Discovery Stage 256 |<---------PADS---------| / 257 | | 258 |---Configure-Request-->| \ 259 |<--Configure-Request---| | PPP Link Establishment Phase 260 |<----Configure-Ack-----| | (LCP) 261 |-----Configure-Ack---->| / 262 | | 263 |<------Challenge-------| \ 264 |-------Response------->| | PPP Authentication Phase (CHAP) 265 |<-------Success--------| / 266 | | 267 |---Configure-Request-->| \ 268 |<--Configure-Request---| | 269 |<----Configure-Nak-----| | PPP Network Layer Protocol Phase 270 |<----Configure-Ack-----| | (IPCP) 271 |---Configure-Request-->| | 272 |<----Configure-Ack-----| / 273 | | 274 |---Configure-Request-->| \ 275 |<--Configure-Request---| | PPP Network Layer Protocol Phase 276 |<----Configure-Ack-----| | (IPV6CP) 277 |-----Configure-Ack---->| / 278 | | 279 |--------Solicit------->| \ 280 |<------Advertise-------| | DHCPv6 281 |--------Request------->| | 282 |<--------Reply---------| / 283 | | 285 Figure 2: An example of connection sequence 287 4. Security Considerations 289 In this architecture, PE and CPE trusts the point-to-point link 290 between them, where one trusts that there is no man-in-the-middle, 291 and trusts PPPoE authentication. Because of this, the DHCP 292 authentication is not considered necessary and is not used. 294 The service provides always-on global-scope prefix for users. Each 295 device connected to user network has global-scope addresses. Without 296 any packet filters, devices might be accessible from outside of the 297 user network in that case. CPE and each device involved in the 298 service should have functionality against unauthorized accesses such 299 as stateful inspection packet filter. Relationship between CPE and 300 devices connected to user network for this problem should be 301 considered in the future. 303 5. Acknowledgements 305 Thanks for the input and review by Tatsuya Sato, Hideki Mouri, 306 Koichiro Fujimoto, Hiroki Ishibashi, Ralph Droms, Ole Troan, Pekka 307 Savola, and IPv6-ops-IAJapan members. 309 Normative References 311 [RFC3177] 312 IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations 313 to Sites", RFC 3177, September 2001. 315 [RFC1661] 316 Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1661, July 317 1994 319 [RFC2472] 320 Haskin, D. and Allen, E., "IP Version 6 over PPP", RFC 2472, 321 December 1998. 323 [RFC2516] 324 Mamakos, L., "A Method for Transmitting PPP Over Ethernet (PPPoE)", 325 RFC 2516, February 1999. 327 [RFC2462] 328 Thomson, S. and Narten, T., "IPv6 Stateless Address 329 Autoconfiguration", RFC 2462, December 1998. 331 [RFC3315] 332 Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 333 RFC 3315, July 2003. 335 [PD] Troan, O. and Droms, R., "IPv6 Prefix Options for DHCPv6", draft- 336 ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in progress), 337 October 2003. 339 [RFC2461] 340 Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for 341 IP Version 6 (IPv6)", RFC 2461, December 1998. 343 [OPT-DNS] 344 Droms, R., "DNS Configuration options for DHCPv6", draft-ietf-dhc- 345 dhcpv6-opt-dnsconfig-04 (work in progress), August 2003. 347 [WKSLDNS] 348 Durand, A., "Well known site local unicast addresses to communicate 349 with recursive DNS servers", draft-ietf-ipv6-dns-discovery-07.txt 350 (expired), October 2002. 352 [OPT-NTP] 353 Vijayabhaskar, A.K., "Time Configuration Options for DHCPv6", 354 draft-ietf-dhc-dhcpv6-opt-timeconfig-02 (work in progress), 355 February 2003. 357 [RFC3319] 358 Schulzrinne, H. and Volz, B., "Dynamic Host Configuration Protocol 359 (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", 360 RFC 3319, July 2003. 362 Informative References 364 [PD-Req] 365 Miyakawa, S., "Requirements for IPv6 prefix delegation", draft- 366 ietf-ipv6-prefix-delegation-requirement-03 (work in progress), 367 August 2003. 369 Appendix 371 Note that current NTT communications' service was launched based on 372 following old or expired I-Ds. The service specification will be 373 updated after both have been published as RFCs. 375 o draft-ietf-dhc-dhcp6-26.txt 377 o draft-troan-dhcpv6-opt-prefix-delegation-01.txt 379 Authors' Addresses 381 Yasuhiro Shirasaki 382 NTT Communications Corporation 383 Tokyo Opera City Tower 21F 384 3-20-2 Nishi-Shinjuku, Shinjuku-ku 385 Tokyo 163-1421, Japan 386 E-mail: yasuhiro@nttv6.jp 388 Shin Miyakawa, Ph. D 389 NTT Communications Corporation 390 Tokyo Opera City Tower 21F 391 3-20-2 Nishi-Shinjuku, Shinjuku-ku 392 Tokyo 163-1421, Japan 393 E-mail: miyakawa@nttv6.jp 395 Toshiyuki Yamasaki 396 NTT Communications Corporation 397 1-1-6 Uchisaiwaicho, Chiyoda-ku 398 Tokyo 100-8019, Japan 399 E-mail: t.yamasaki@ntt.com 401 Ayako Takenouchi 402 NTT Communications Corporation 403 Tokyo Opera City Tower 21F 404 3-20-2 Nishi-Shinjuku, Shinjuku-ku 405 Tokyo 163-1421, Japan 406 E-mail: ayako.takenouchi@ntt.com 408 Intellectual Property Statement 410 The IETF takes no position regarding the validity or scope of any 411 intellectual property or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; neither does it represent that it 415 has made any effort to identify any such rights. Information on the 416 IETF's procedures with respect to rights in standards-track and 417 standards-related documentation can be found in BCP-11. Copies of 418 claims of rights made available for publication and any assurances of 419 licenses to be made available, or the result of an attempt made to 420 obtain a general license or permission for the use of such 421 proprietary rights by implementors or users of this specification can 422 be obtained from the IETF Secretariat. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights which may cover technology that may be required to practice 427 this standard. Please address the information to the IETF Executive 428 Director. 430 Full Copyright Statement 432 Copyright (C) The Internet Society (2003). All Rights Reserved. 434 This document and translations of it may be copied and furnished to 435 others, and derivative works that comment on or otherwise explain it 436 or assist in its implementation may be prepared, copied, published 437 and distributed, in whole or in part, without restriction of any 438 kind, provided that the above copyright notice and this paragraph are 439 included on all such copies and derivative works. However, this 440 document itself may not be modified in any way, such as by removing 441 the copyright notice or references to the Internet Society or other 442 Internet organizations, except as needed for the purpose of 443 developing Internet standards in which case the procedures for 444 copyrights defined in the Internet Standards process must be 445 followed, or as required to translate it into languages other than 446 English. 448 The limited permissions granted above are perpetual and will not be 449 revoked by the Internet Society or its successors or assignees. 451 This document and the information contained herein is provided on an 452 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 453 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 454 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 455 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 456 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 458 Acknowledgment 460 Funding for the RFC Editor function is currently provided by the 461 Internet Society.