INTERNET-DRAFT Yasuhiro Shirasaki Expires: August, 2003 Shin Miyakawa Toshiyuki Yamasaki Ayako Takenouchi NTT Communications February 24, 2003 A Model of IPv6/IPv4 Dual Stack Internet Access Service draft-shirasaki-dualstack-service-00.txt Status of this Memo This memo provides information to the Internet community. It does not specify an Internet standard of any kind. This memo is in full conformance with all provisions of Section 10 of RFC2026. 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.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be August 24, 2003. Abstract This memo shows an example of how to provide IPv6 / IPv4 dual stack services to home users. In order to simplify user setup, these service should have mechanism to configure IPv6 specific parameters automatically. We focus on two basic parameters, prefix and addresses of IPv6 DNS servers, and specify the way to deliver them to Customer Premises Equipments (CPE) automatically. This memo is a digest of the user network interface specification of NTT communications' dual stack ADSL access service. Shirasaki, et al. Expires - August 2003 [Page 1] INTERNET-DRAFT Dual stack access February 2003 1. Introduction This memo describes two topics. One is the architecture of IPv6/IPv4 dual stack access service. The other is the automatic configuration function for IPv6 specific parameters. Here are some antecedents of the architecture. The architecture mainly targets at a leased line ADSL service for home users. It assumes that there is a PPP logical link between CPE and Provider Edge (PE). In order to exclude factors which are specific to access lines from this architecture, we only specify PPP and its upper layers. To satisfy [RFC3177], the length of prefix which is delegated to CPE is /48. In this architecture, IPv6/IPv4 dual stack service is specified as follows. o IPv6 and IPv4 connectivity are provided over a single PPP logical link. o IPv6 connectivity is independent of IPv4 connectivity. IPV6CP and IPCP works independently over a single PPP logical link. Figure 1 shows the outline of the service architecture. NTT Communications has been used this architecture since the summer of 2002. | _____________ [HOST]-+ +-----------+ +----------+ / \ | | Customer | ADSL line | Provider | | ISP core and | +-+ Premises +---------------+ Edge |--| The internet | | | Equipment | to subscriber +-----+----+ \_____________/ [HOST]-+ +-----------+ | | | | +-----+------+ | +-+----------+ | AAA server | | | DNS server | +------------+ | +------------+ +-+--------------+ | NTP server etc.| +----------------+ Figure 1: Dual stack access service architecture The automatic configuration function aims at simplication of user setup. Usually, users have to configure at least two IPv6 specific parameters, prefix(es) and IPv6 DNS servers addresses. The function is composed of two sub-functions as below. Shirasaki, et al. Expires - August 2003 [Page 2] INTERNET-DRAFT Dual stack access February 2003 o Delegation of prefix(es) o Notification of IPv6 DNS server addresses Section 3 of this memo details user network interface. Section 4 describes an example of connection sequence. 2. Requirements The keywords 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]. 3. User Network Interface In this section, details of the user network interface specification are described. Only PPPoE and its upper layer are mentioned. The other layers such as ethernet and lowers are out of scope. IPv4 related parameter configuration is also out of scope. 3.1. Sub-IP Layer The service uses PPP connection and CHAP authentication to identify each CPE. Both CPE and PE handles both IPCP [RFC1661] and IPV6CP [RFC2472] identically / simultaneously over a single PPP connection. It means both CPE and PE can open/close any NCP session anytime without any side-effect for each other. It is intended that users can choose three services, IPv4 only, IPv6 only and IPv4/IPv6 dual stack. A CPE connected to an ADSL line discovers a PE with PPPoE mechanism [RFC2516]. CPE MUST reply with LCP Echo-Reply when it is in the LCP Opened state and receives LCP Echo-Request as described in [RFC1661] Note that because CPE and PE can negotiate only their interface identifiers with IPV6CP, PE and CPE can use only link-local scope addresses before prefix delegation mechanism described below. 3.2. IP Layer After IPV6CP negotiation, a CPE initiates prefix delegation request. A PE chooses global-scope prefix for the CPE with information from AAA server or local prefix pools, and delegates the prefix to the CPE. Once the prefix is delegated, the prefix is subnetted and assigned to local interfaces of CPE. CPE begins sending router advertisement of the prefixes on each links. Eventually hosts can acquire global-scope prefixes through conventional IPv6 stateless [RFC2462] or stateful auto-configuration mechanisms [DHCPv6] etc, and Shirasaki, et al. Expires - August 2003 [Page 3] INTERNET-DRAFT Dual stack access February 2003 become to communicate using global-scope addresses. 3.3. Prefix Delegation PE delegates prefixes to CPE by DHCPv6 [DHCPv6] with prefix delegation options [PD]. The model of sequence for prefix delegation is as follows: o A CPE requests prefixes to a PE by sending DHCPv6 Solicit message which has link-local source address negotiated by IPV6CP, mentioned in the previous section, and includes IA_PD option. o The PE chooses prefix(es) which is notified by AAA server or choosen from PE's local pool and returns Advertise message which contains IA_PD and IA_PD Prefix option. The prefix-length in the IA_PD Prefix option is 48. o CPE chooses prefix(es) and sends Request message containing IA_PD option and IA_PD Prefix option for chosen prefix(es) back to PE. o PE confirms the prefix(es) in the Request message and returns Reply message. Once IPV6CP is terminated or restarted by any reason, CPE MUST initiate a Rebind/Reply message exchange as described in [PD]. 3.4. Address Assignment The CPE assigns global-scope prefixes subnetted from the delegated prefix to its downstream interfaces with its length /64. Because link-local address is already assigned to CPE's upstream interface, global-scope address assignment for that interface is OPTIONAL. 3.5. Routing CPE and PE use static routing between them. It reduces traffic of routing protocol between them. When CPE receives packets which are destined for the delegated prefix, CPE MUST NOT forward the packets to a PE. CPE SHOULD return ICMPv6 Destination Unreachable message to a source address or silently discard the packets. CPE configures its PPPoE logical interface or link-local address of PE as IPv6 default gateway automatically after the prefix delegation exchange. Shirasaki, et al. Expires - August 2003 [Page 4] INTERNET-DRAFT Dual stack access February 2003 3.6. Obtaining Addresses of DNS Servers The service provides IPv6 DNS cache servers in the ISP site as same as IPv4 case. PE notifies the global unicast addresses of these servers with Domain Name Server option, which is described in [OPT- DNS], in Advertise/Reply message on the prefix delegation message exchange. 3.7. Miscellaneous Information PE may notify other IPv6 enabled server addresses such as Network Time Protocol servers [OPT-NTP], SIP servers [OPT-SIP], etc in Advertise/Reply message on the prefix delegation message exchange if it is available. 3.8. Connectivity Monitoring ICMPv6 Echo Request will be sent to user network for connectivity monitoring in the service. CPE MUST return single IPv6 Echo Reply packet when it receives ICMPv6 Echo Request packet. The health check packets are destined for subnet-rouer anycast address for the delegated prefix. 4. An Example of Connection Sequence Following figure is an example of normal link-up sequence from start of PPPoE to start of IPv6/IPv4 communications. IPv4 communication becomes available after IPCP negotiation. IPv6 communication with link-local scope addresses becomes possible after IPV6CP negotiation. IPv6 communication with global-scope addresses becomes possible after prefix delegation and conventional IPv6 address configuration mechanism. IPCP is independent of IPV6CP and prefix delegation. Shirasaki, et al. Expires - August 2003 [Page 5] INTERNET-DRAFT Dual stack access February 2003 CPE PE | | |----------PADI-------->| \ |<---------PADO---------| | PPPoE |----------PADR-------->| | Discovery Stage |<---------PADS---------| / | | |---Configure-Request-->| \ |<--Configure-Request---| | PPP Link Establishment Phase |<----Configure-Ack-----| | (LCP) |-----Configure-Ack---->| / | | |<------Challenge-------| \ |-------Response------->| | PPP Authentication Phase (CHAP) |<-------Success--------| / | | |---Configure-Request-->| \ |<--Configure-Request---| | |<----Configure-Nak-----| | PPP Network Layer Protocol Phase |<----Configure-Ack-----| | (IPCP) |---Configure-Request-->| | |<----Configure-Ack-----| / | | |---Configure-Request-->| \ |<--Configure-Request---| | PPP Network Layer Protocol Phase |<----Configure-Ack-----| | (IPV6CP) |-----Configure-Ack---->| / | | |--------Solicit------->| \ |<------Advertise-------| | DHCPv6 |--------Request------->| | |<--------Reply---------| / | | Figure 2: An example of connection sequence 5. Security Considerations Though the threat of DHCP is a kind of man-in-the-middle, the architecture uses point-to-point link as layer 2 and communication between PE and CPE is protected by layer 2 security. The service provides always-on global-scope prefix for users. Each device connected to user network has global-scope addresses. Without any packet filters, devices might be accessible from outside of the user network in that case. CPE and each device involved in the service should have functionality against unauthorized accesses such as stateful inspection packet filter. Relationship between CPE and Shirasaki, et al. Expires - August 2003 [Page 6] INTERNET-DRAFT Dual stack access February 2003 devices connected to user network for this problem should be considered in the future. 6. Acknowledgements Thanks for the input and review by Tatsuya Sato, Hideki Mouri, Koichiro Fujimoto, Hiroki Ishibashi, Ralph Droms, Ole Troan, and IPv6-ops-IAJapan members. Normative References [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994 [RFC2472] D. Haskin and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [RFC2516] L. Mamakos, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [DHCPv6] R. Droms, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002. [PD] O. Troan and R. Droms, "IPv6 Prefix Options for DHCPv6", draft- ietf-dhc-dhcpv6-opt-prefix-delegation-02 (work in progress), February 2003. [OPT-DNS] R. Droms, "DNS Configuration options for DHCPv6", draft-ietf-dhc- dhcpv6-opt-dnsconfig-02 (work in progress), October 2003. Shirasaki, et al. Expires - August 2003 [Page 7] INTERNET-DRAFT Dual stack access February 2003 [OPT-NTP] A.K. Vijayabhaskar, "Time Configuration Options for DHCPv6", draft- ietf-dhc-dhcpv6-opt-timeconfig-01 (work in progress), May 2002. [OPT-SIP] H. Schulzrinne and B. Volz, "DHCPv6 Options for SIP Servers", draft-ietf-sip-dhcpv6-01 (work in progress), November 2002. Informative References [PD-Req] Miyakawa, S., "Requirements for IPv6 prefix delegation", draft- ietf-ipv6-prefix-delegation-requirement-00 (work in progress), November 2002. Appendix Note that current NTT communications' service is running based on following old or expired I-Ds at this time. The service specification will be no sooner updated than these I-Ds become RFC. o draft-ietf-dhc-dhcp6-26.txt o draft-troan-dhcpv6-opt-prefix-delegation-01.txt Author's Address Yasuhiro Shirasaki NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan E-mail: yasuhiro@nttv6.jp Shin Miyakawa, Ph. D NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan E-mail: miyakawa@nttv6.jp Toshiyuki Yamasaki NTT Communications Corporation 1-1-6 Uchisaiwaicho, Chiyoda-ku Tokyo 100-8019, Japan E-mail: t.yamasaki@ntt.com Shirasaki, et al. Expires - August 2003 [Page 8] INTERNET-DRAFT Dual stack access February 2003 Ayako Takenouchi NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan E-mail: ayako.takenouchi@ntt.com Shirasaki, et al. Expires - August 2003 [Page 9]